resource description framework
RDFS USING NEO4J AND ONTOLOGIES
ChemConnect stores the database information using the Google Firestore framework, but to facilitate queries an Resource Description Framework (RDF) is added. The RDFs are stored using NEO4J, a graph oriented database framework. The information for the RDFs are defined using information from the individual catalog objects. The specific form of the RDFs are defined using the ontology.
Structure and Purpose of the RDF Framework
The RDF framework is subordinate to the Google Firestore noSQL framework in that it provides redundant information stored so that questions can be asked linking the catalog objects and the information.
Definition of the RDF through the ontology
General Structure of Definition
The RDFs are designed to correspond to a specific query of the catalog objects. A catalog object can have several RDFs defined from it.
The basic definition of the RDF is made with the following technique:
- Catalog Link: Within the object, the skos:mappingRelation points to the RDF definition.
RDF: The RDF definition is a subclass of RDFMappingDefinition. The name of this class is the predicate of the RDF definition.
Within the RDF definition (defined as a subclass of RDFMappingDefinition (which itself is a subclass of skos:Concept) the following are used to define the subject and the object of the RDF definition:
prov:entity Within the corresponding RDFMappingDefinition class, the `prov:entity` links to the subject of the RDF.
- skos:member: Within the corresponding RDFMappingDefinition class, the skos:member links to the object of the RDF.
Both the prov:entity and skos:member point to components, which correspond to a string key, or records, which point to a hierarchy of keys. The string keys of the components, whether they are directly linked or in the record are what is matched in the (Neo4J Cypher) queries.
The information specified by the RDF definition, whether it be the object or the subject, can be anywhere in the whole catalog object.
The subjects and objects of the RDF can be either Components, i.e. a simple string object, or Records, compound objects of several records and objects. Since JSON objects are not a primitive type of NEO4J Cypher objects, Records, which is essentually a JSON object, are translated to string objects. This string is stored for the object or subject. In the normal use of Cypher searches, the conditions of the subjects and objects would be through the component strings, basically keywords.
The philosophy of the RDF defined for CHEMCONNECT objects is that the subject, for the most part only one, are strings that can be searched for. This means in the majority of cases, these subjects would be keywords. The objects are meant to be the information related to the subject keyword. In some instances, the Cypher search needed could restrict some object characteristics, thus the object, usually a keyword,
Example: RDFRequiredTransactionInformation
In this example (see picture) the RDFRequiredTransactionInformation RDF defines links to all the prerequisite transactions of the transaction in the current catalog object. The record RequiredTransactionInformation has not only the prerequisite transaction ID (RequiredTransactionID), but also other information that is useful, for example, to help the user identify the particular transaction in a pull down list of the user interface. The usefulness of the RDF is to identify the transaction enough for the user without actually having to upload the actual transaction. The DescriptionTitleRequiredTransaction gives a one line description, RequiredTransactionType, gives the type/class of the transaction, the RequiredTransactionAndType gives the Firestore address of the actual transaction if it is to be read in and RequiredTransactionKey gives a short indicator of the transaction.
The RDF definition is linked in the catalog object through:
‘skos:mappingDefinition exactly 1 RDFRequiredTransactionInformation’.
The subject of the RDF is TransactionID and is denoted with:
subject exactly 1 TransactionID
There are two objects in the RDF, RequiredTransactionID and RequiredTransactionInformationID. They are denoted in the RDF definition by the following:
prov:entity exactly 1 RequiredTransactionID
prov:entity exactly 1 RequiredTransactionInformation
In this example,the catalog object is defined with an array of RequiredTransactionInformation records:
dcat:record some RequiredTransactionInformation
This means that a separate RDF will be created for each of the elements in the array.
The name/type of the RDF is given by the class name: RDFRequiredTransactionInformation.
The information specified by the RDF definition, whether it be the object or the subject, can be anywhere in the whole catalog object. In this case, the TransactionID and RequiredTransactionInformation are found at the same level as the skos:mappingDefinition. However, the the subject RequiredTransactionID is found within the RequiredTransactionInformation which is one level down (in the sense of JSON objects) from the top catalog object.
Note also that in this definition the component RequiredTransactionID is found both as a object and within the object JSON object. However, since JSON objects are stored as strings, the objects inside are not searchable with NEO4J Cypher commands. Thus, for the case that the user will restrict the use of the required transaction ID, duplicate information that can be searched is provided by the RDF.
Node Type
The node name is created by the concatenation of the object type, which in the example is TransactionID and SUBJECT, which indicates it is a subject node. The node itself has no name.
Property Names
Associated with each ontology object is a standard set of annotations. Within the JSON object, the property label has the name of the namespace, which for CHEMCONNECT specific objects is ‘dataset’. However, there are restrictions of the Cypher property names, which includes not have special characters like a colon. For this reason, instead of using dcterms:identifier, the skos:altlabel is used. In this example the skos:altlabel for TransactionID is ‘transactionid’.
Additional Properties: Owner
Every catalog object has an owner, i.e. the user that created and the main manipulator of the object. The nodes also have an owner. The owner is also used as a restriction of who can see and search for the node. When a Cypher search is performed, the current owner, i.e. the person conducting the search is added as a new property. This restricts the search to only those objects ‘owned’ by the user.
Additional Properties: Creation Transaction
A catalog object is created using a transaction. Thus, associated with all catalog objects is the transaction ID of the transaction that created it. Since the RDF node is also created by the same transaction as the associated catalog object, it also has a property, namely ‘transactionrdf’ that stores the transaction id. In this case, the ‘transactionid’ and ‘transactionrdf’ happens to be the same.
Creation of Object node
In the figure below is the text representation of the object node.
The name of the object node is ‘DatasetTransactionEventObjectOBJECT‘, which is a concantenation of the object node type, ‘DatasetTransactionEventObject’, and the string ‘OBJECT’ signifying that it is indeed an object node
In NEO4J the property structure is flat, meaning that each property must be a string. There are
The RDFRequiredTransactionInformation object describes a complete RDF. In this ontology class object the object of the RDF is describe by the prov:entity descriptors. In this example there are two class objects that are RDF objects, the RequiredTransactionID and the RequiredTransactionInformation class objects. These are the two properties of the NEO4J node object. The corresponding property names of these objects are defined by the skos:altLabel annotation objects within these classes, namely ‘requiredtransactionid’ and ‘requiredtransactioninfo’.
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Ut elit tellus, luctus nec ullamcorper mattis, pulvinar dapibus leo.
English