Principle: Unique identifiers

Many aspects of InfoGrid depend on the existence of unique identifiers. Here is a partial list:

Java package names:

Like any Java application or library, InfoGrid follows the Java  package naming convention based on the organization's reverse domain name. Example: org.infogrid.util.context.Context.

Module Identifiers:

Module identifiers use the same convention as Java package names. However, as there is no danger in mistaking Module identifiers and Java package or type names, they can be considered taken from a different name space. Example: org.infogrid.util.

MeshTypeIdentifiers:

• The MeshTypeIdentifier for any SubjectArea must be the same as the identifier for the ModelModule defining the SubjectArea. Example: org.infogrid.model.Tagging
• The MeshTypeIdentifier for any EntityType is a concatenation of the MeshTypeIdentifier of the SubjectArea in which it is defined, the forward slash /, and a local identifier. The local identifier should be the same as the computable name of the EntityType. Example: org.infogrid.model.Tagging/Tag.
• The MeshTypeIdentifier for any RelationshipType is a concatenation of the MeshTypeIdentifier of the SubjectArea in which it is defined, the forward slash /, and a local identifier. The local identifier should be the same as the computable name of the RelationshipType, which is typically the computable name of the source EntityType, the computable short name of the RelationshipType, and the computable name of the destination EntityType, separated by underscores _. Example: org.infogrid.model.Tagging/TagLibrary_Collects_Tag.
• The MeshTypeIdentifier for a PropertyType is a concatenation of the MeshTypeIdentifier of the EntityType in which it is defined, the underscore _, and computable name of the PropertyType. Example: org.infogrid.model.Tagging/TagLibrary_Name.

MeshObjectIdentifiers (that are not NetMeshObjectIdentifiers):

When using a standalone GraphDatabase (i.e. a MeshBase that is not a NetMeshBase), any String may be used as MeshObjectIdentifier. It may be advantageous to refrain from characters in the MeshObjectIdentifier that make mapping the MeshObjectIdentifier to and from a REST-ful URL difficult. If there is any chance that the application may ever use several NetMeshBases in a grid, or that it may use Probes, it is recommended to follow the stricter rules for NetMeshObjectIdentifiers.

NetMeshObjectIdentifiers:

In InfoGrid, NetMeshObjectIdentifiers are essentially equivalent to public URLs on the internet. The same care needs to be taken in designing the namespace of NetMeshObjectIdentifiers as for defining the namespace of a website in which all pages are supposed to be bookmarkable. While InfoGrid does not prevent the application developer from creating a NetMeshObject with a NetMeshObjectIdentifier that refers to a site other than the site of the current application, in many (but not all) cases this should be avoided.

NetMeshObjectIdentifiers in Probes:

See separate discussion in Probe implementation guidelines.

MeshBaseIdentifiers (that are not NetMeshBaseIdentifiers):

When using a standalone GraphDatabase (i.e. a MeshBase that is not a NetMeshBase), it is rare to use more than one MeshBase in the same InfoGrid application. As a result, no special care needs to be taken when assigning a MeshBaseIdentifier.

NetMeshBaseIdentifiers for regular NetMeshBases (not ShadowMeshBases):

The NetMeshBaseIdentifier of a regular NetMeshBase should be the same as the canonical URL of the InfoGrid application. For example, if the InfoGrid application runs at URL https://internal.example.com/foo, that should be the NetMeshBaseIdentifier of the main NetMeshBase. If the application is accessible at more than one URL, the canonical URL should be used.

NetMeshBaseIdentifiers for ShadowMeshBases:

The NetMeshBaseIdentifier of a ShadowMeshBase must be the same as the URL of the data source. For example, if a Probe accesses data source ftp://pub.example.com/public/file1.xml, that will be the NetMeshBaseIdentifier of the ShadowMeshBase accessing it.