The Google Firestore noSQL database has a document oriented data-model. The structure is an alternating hierarchy of collections and documents. Within a collection, which is specified by a string label, is a set of documents. A document is a map of property-value pairs. The value specified by the document can either be an object, such a string or numerical value, or it can be a label to a further subcollection. Thus the final document (one with no further subcollections under it) is a set of property-object value pairs at the end of a hierarchy. Access to this document is through a alternating set of collection labels and subcollection labels within a document.
Within the JThermodynamicsCloud implementation, the catalog objects, a mapping similar to a JSON object, are found at the end nodes of hierarchy of collection and documents nodes. The nodes of the branch leading to the catalog object are designated by string labels. The string labels are either a collection label or a document property label pointing to a subcollection. Thus each of the documents in the hierarchy leading to this final catalog object only have a single label for the subcollection. In the document form of noSQL databases, the design model is to group all 'documents' into a single collection. In JThermodynamicCloud, all collections of documents are at the end of a branch designated with string labels for each node. The address, meaning the set of labels of the nodes in the branch leading to the catalog object, are specified in the FirestoreID class.
In JThermodynamicsCloud the position of each catalog with a collection-document hierarchy object is specified under the dataset:CollectionDocumentHierarchy. The ontology classes and subclasses under dataset:CollectionDocumentHierarchy specify the classes of collection-document nodes leading to the final catalog objects at the end of the branch. Each class in this hierarchy specifies how the node should be labeled. A given catalog object class has a unique position in the hierarchy defined by the ontology. The label specification can be a constant or can be derived from the current catalog being stored. The end class in this specification ontology hierarchy specifies which class of catalog object is to be stored in the database.
In each of the ontology class specifications, the rdfs:isDefinedBy annotation specifies how the label is to be created. The set of methods to create these labels are defined in the ontology under the dataset:GenerateStringLabel class. Each of the methods in the ontology has a corresponding code within a JAVA Enumeration class (using the ontology class name as reference). If the (final) node is to store a catalog object, then the class of the catalog object is specified by skos:member. Thus when a class object is to be stored, the skos:member fields are searched for the class name. The catalog object address (to be specified in the FirestoreID catalog address) is generated by the branch of classes leading to this node.
For example, suppose we are to store a specific instance of a collection set of the class database:ChemConnectDatasetCollectionIDsSet. Following the ontology class hierarchy under dataset:CollectionDocumentHierarchy, we find there are four classes in the hierarchy leading to the class specifying database:ChemConnectDatasetCollectionIDsSet.as the skos:member. This means that this class is the document specified by four labels. All four classes together specify the labels of the branches leading to the specific instance:
dataset:CatalogHierarchyThermodynamicDatasets: The rdfs:isDefinedBy points to dataset:DerivedFromHierarchyClassAnnotationAltLabel and derives the first collection label from this class's skos:altlabel value, namely hierthermodynamicdataset. This says that all thermodynamic data is under this node.
dataset:CatalogObjectDatasetMaintainer: The rdfs:isDefinedBy points to dataset:LabelDerivedFromMaintainerLabel and derives the document label from the catalog object's class dataset:maintainer value, namely the UID of the person who created the object, like UOqk0KtFtaXma5TGsi8Seh9RMbx1. This means that all thermodynamic data created by this user in under this node.
dataset:CatalogHierarchyDatasetCollectionIDSet: The rdfs:isDefinedBy points to dataset:DerivedFromHierarchyClassAnnotationAltLabel and derives the first collection label from this class's skos:altlabel value, namely, hieridcollectionset. This means that all collection sets created by this user are in this collection.
dataset:CatalogHierarchyDatasetCollectionID: This is the last node of the branch, so this is the catalog document. The rdfs:isDefinedBy points to dataset:LabelDerivedFromCollectionIDSetLabel and derives the label for this document from the
dataset:datasetcollectionslabel property within the collection catalog object itself. For example, StandardData. This is the name that accesses the catalog instance.
Thus the catalog object, i.e. the document, lies down the branch specified by hierthermodynamicdataset, UOqk0KtFtaXma5TGsi8Seh9RMbx1, hieridcollectionset and, finally the document name, StandardData.
The nodes leading to the catalog objects in JThermodynamicsCloud are alternating collection and document string labels. Each node in the ontology hierarchy definition specifies how these string labels are to be derived. The source of the information for the string labels can come from these sources:
Catalog Object: The catalog object found at the end node of the path can be a source of the label.
Catalog Object Ontology Annotations: The annotations found in the type definitiokn of the catalog object can be used as a source of label keys.
Hierarchy Node: The annotations of the current hierarchy node, typically the skos:altlabel, can be used. This essentially means that this node level is a constant.
In the hierarchy node ontology definition the annotation value of rdfs:isDefinedBy specifies the method to be used to generate the label. This method is an implementation operation by type under the dataset:GenerateStringLabel class, which itself is a subclass of dataset:DataObjectManipulation.
The keywords of the nodes of the database structure hierarchy can be constants or derived from several sources. In the ontology definition of the hierarchy each class has a rdfs:isDefinedBy in the annotations. This points to methods of deriving the keyword label of the hierarchy node, including the final catalog object node. In the ontology, the set of methods available are subclasses of dataset:GenerateStringLabel, is a subclass of prov:SofwareAgent -> dataset:DataObjectManipulation and is an example of an Implementation Operations by type. The names give an indication of which parameters are used to make the hierarchy node name:
dataset:DerivedFromCurrentClassAnnotationAltLabel
dataset:DerivedFromHierarchyClassAnnotationAltLabel
dataset:DerivedFromObjectParameter
Those that are derived from parameters within the catalog object being stored (under dataset:DerivedFromObjectParameter) are:
dataset:DerivedFromObjectClassName:
dataset:LabelDerivedFromCatalogObjectKey:
dataset:LabelDerivedFromCatalogOwner:
dataset:LabelDerivedFromCollectionIDSetLabel:
dataset:LabelDerivedFromDatasetCollectionObjectType:
dataset:LabelDerivedFromDatasetLabel:
dataset:LabelDerivedFromDatasetVersion:
dataset:LabelDerivedFromObjectStatus:
dataset:LabelDerivedFromObjectUniqueLabel:
dataset:LabelDerivedFromTransactionEventType:
For example, to store a dataset:ThermodynamicBensonRuleDefinition catalog object, the hierarchy is searched and the corresponding class dataset:CatalogHierarchyThermodynamicBensonRuleDefinition is found with dataset:ThermodynamicBensonRuleDefinition as a skos:member. The hierarchy path leading to this node from the top of the hierarchy (dataset:CollectionDocumentHierarchy) is:
CatalogHierarchyThermodynamicDatasets
CatalogObjectDatasetMaintainer
CatalogHierarchyDatasetName
CatalogHierarchyDatasetCollection
CatalogHierarchyDatasetObjectType
CatalogHierarchyDatasetTypeVersion
CatalogHierarchyObjectStatus
CatalogHierarchyThermodynamicBensonRuleDefinition
Within these classes, the rdfs:isDefinedBy field in the annotations defines how the database label should be derived. In this example, the following methods are used:
DerivedFromHierarchyClassAnnotationAltLabel: The skos:altlabel is used from the CatalogHierarchyThermodynamicDatasets, namely, hierthermodynamicdataset.
LabelDerivedFromMaintainerLabel: Within the catalog object the maintainer field is used. This would give unique ID for the maintainer.. This means that the database objects below this in the hierarchy belong only to this maintainer. Each maintainer, including the system, has their own branches.
LabelDerivedFromDatasetLabel: Wíthin the catalog object, the dataset:DatasetName is used. This is one of the parameters which differentiates different collection sets.
DerivedFromHierarchyClassAnnotationAltLabel: This uses the skos:altlabel of the hierarchy class, namely hierdatasetcollection. Under a given dataset name, there are branches for the preliminary objects from which the database objects and this branch for the catalog object.
DerivedFromObjectClassName: This extracts the class type from the catalog object. This is where the different catalog types in a collection are differentiated.
LabelDerivedFromDatasetVersion: This extracts the version from the catalog object. This allows different versions of the catalog type within the same dataset. For example, if the collection is updated.
LabelDerivedFromObjectStatus: This extracts the status of the collection, usually CatalogObjectStatusCurrent.
LabelDerivedFromCatalogObjectKey: At this level all the catalog objects in this data type are collected together.