Better separation between "administrative metadata" and properties in n4e:BaseShape
In n4e:BaseShape
we currently represent properties that apply to all shapes, resp. to all classes in our data model. However we need to better distinguish between descriptive properties of the harvested remote object and administrative meta properties which apply to our harvested representation of the remote object in the KH.
I would consider the following descriptive properties (which apply to all classes):
owl:sameAs
And I would consider the following administrative meta properties (which mostly describe the provenance of our harvested representation of the remote object:
n4e:sourceSystem
n4e:sourceSystemID
n4e:recordVersion
prov:generatedAtTime
prov:generatedBy
prov:wasRevision
Taking as an example https://nfdi4earth-knowledgehub.geo.tu-dresden.de/api/#objects/n4ekh/0ae0846a9e0abb60a875 , all meta properties would be in Cordra better represented by moving them to the metadata section of the Digital Object - and not in the content section as currently (see https://nfdi4earth-knowledgehub.geo.tu-dresden.de/api/objects/n4ekh/0ae0846a9e0abb60a875?full ).
However, to avoid a vendor lock-in we should think about how to model this independently of Cordra's specific data model. Since we already mirror every Digital Object in Cordra to one named graph in the triple store (and every named graph has an IRI), I would propose to bind these triples directly on the IRI of the named graph.
Example:
Right now, all the triples of https://nfdi4earth-knowledgehub.geo.tu-dresden.de/api/objects/n4ekh/0ae0846a9e0abb60a875 are stored in Fuseki in a named graph with the IRI http://fuseki-kh:3030/knowledge-graph/data/n4ekh/0ae0846a9e0abb60a875 (see query 1 below) - the naming of the graph IRI should be changed of course. The administrative meta properties would then be changed to use the graph IRI as subject instead of the project IRI as currently. A standard query of the properties of the project (see query 2 below) would then not contain these meta properties anymore, they could only be extract with query 1. I would personally envision that in a default query via the OneStop UI the meta properties are not of interest anyway, and would only be fetched on-demand from the KH when the user is specifically interested in the provenance of the metadata they are looking at.
Supplementary resources:
Query 1:
SELECT ?s ?p ?o
{
GRAPH <http://fuseki-kh:3030/knowledge-graph/data/n4ekh/0ae0846a9e0abb60a875> {
?s ?p ?o
}
}
Query 2:
SELECT ?p ?o
{
<https://nfdi4earth-knowledgehub.geo.tu-dresden.de/api/objects/n4ekh/0ae0846a9e0abb60a875> ?p ?o
}