# Semantic Publication of Agricultural Scientific Literature Using Property Graphs
## 3 Materials and Methods
### Knowledge Graph Population  
This step generates a graph database by loading both the RDF files previously created, which include article metadata, sections and annotations, in addition to the ontologies used for the annotation, which add domain knowledge to the graph. This has been implemented using the Python script available at [[https://github.com/biotea/biotea-graph-population](https://github.com/biotea/biotea-graph-population)]([https://github.com/biotea/biotea-graph-population](https://github.com/biotea/biotea-graph-population)) and the graph database used was Neo4j [28], whose model differs from RDF because it implements a property graph model. RDF [6] is a graph model used for describing resources, where resources are identified by a URI and they represent entities. These resources are described by a set of triples of the form <subject, predicate, object>, where the subject is linked to the object through the predicate. The subject will always be a resource, and the object could be another resource or a literal value. Then, a list of triples can be seen as a graph where resources are nodes and properties are edges. In [29], the property graph model is described as follows:  
1. A property graph is made up of nodes, relationships and properties. 2. Nodes contain properties [...] in the form of arbitrary key-value pairs. The keys are strings and the values are arbitrary data types. 3. A relationship always has a direction, a label, and a start node and an end node. 4. Like nodes, relationships can also have properties. In the Neo4j property graphs, nodes are also labelled with their categories in order to establish their types. Taking these differences into account, we need to apply a model transformation in order to store RDF data into a property graph database. This transformation was carried out by the Neosemantics plugin for Neo4j. This plugin is able to load RDF data into a Neo4j graph according two kind of conversions depending on the desired detail level, namely importRDF and loadOntology. On the one hand, the importRDF function was used for uploading the metadata, sections and annotation RDF files. This function ingests all triples in an RDF dataset and uploads them into the graph database by applying the following rules [30]:  
Figure 4: Model used for describing annotations according to the Annotation Ontology. Core concepts in the model are marked in blue. The ontology terms marked in purple are provided by the annotator. Adapted from [10]. **Rule 1**: Every RDF resource becomes a property graph node. Since the subject in RDF is always a resource, there is at least one property graph node created or merged into an existing node. **Rule 2**: If the object is a literal, the predicate and object become respectively a property name and value. The property is added to the created or existing node corresponding to the resource. **Rule 3**: If the object is a resource, then both the subject and objects are transformed into a node. A relationship between them is created and it holds the predicate's name as a relationship type. **Rule 4**: If the predicate is rdf:type, the subject becomes a node having a label set to the objects name (which is actually the resource type). Figure 5 shows the RDF representation of two resources and the property graph model resulting from applying the rules described before. In this case, res:article1 and res:article2 are the unique subjects of the triples in the RDF model. Thus, according to rule 1, they are mapped onto nodes in the property graph model, labelling them as Resource. Also, the URIs in the RDF model are stored as a property in the property graph node. Then, the RDF properties dct:title are translated to properties inside the nodes in the property graph model, as rule 2 states. Also, the RDF property bibo:cites is converted into a relation according to rule 3. Finally, RDF rdf:type statements are translated to category labels in the property graph model, following rule 4.