how to specify identifier for the metadata record #245
Comments
|
JSON-LD is a serialization of RDF, so is describing a graph. I'm not sure there's a definitive "root object" in these examples. Instead there's a graph of related nodes, any of which could be considered a root to start traversal (except perhaps the |
|
I believe this is the type of issue that is addressed by JSON-LD Framing 1. So instead of suggesting a preferred pattern of serialization (generally cumbersome when serializing from an RDF source), it may be more appropriate to suggest a frame document to apply when inspecting from a perspective. If the desired form is option 1 above, then use a frame like: This places the Footnotes |
|
Makes sense to address the alternate serializations; it only matters if you're parsing the metadata as JSON. That there needs to be an identifier for the metadata digitalObject distinct from the thing it describes is what I should have emphasized. |
|
Reading through the examples above, it strikes me that neither option 1 or 2 above provide an identifier for the described resources. So although this issue seems to be about preferred serialization pattern for nested documents, it may be helpful to make the example a little more complete by adding So rewriting option 1: {
"@context": "https://schema.org",
"@id": "ex:URIforImageObjectNode",
"@type": "ImageObject",
"title": "Picture of analytical setup",
"description": "Description of the resource",
"identifier": "ex:URIforDescribedResource",
"subjectOf": {
"@id": "ex:URIforDigitalDocumentNode",
"@type": "DigitalDocument",
"dateModified": "2017-05-23",
"identifier": "ex:URIforTheMetadata",
"encoding": {
"@type": "MediaObject",
"dcterms:conformsTo": "https://example.org/cdif-metadataSpec"
}
"about":{"@id":"ex:URIforImageObjectNode"}
}
}makes it clear that |
|
Note that conceptually, the graph |
|
I don't get the distinction between the 'graph' and the 'document' In my understanding the digitalDocument (in my example) is the metadata describing the resource (image object in the example). This metadata is represented using rdf -- a logical graph. The document and graph are the same thing. The resource (image object) is described by rdf triples-- statement in which the image is the subject, some property is the predicate, and a value is the object. I expect the uri for the described resource to be the subject of this statements. Converting the JSON-LD in @datadavev example: What does ex:URIforImageObjectNode actually identify. Do the statements about ImageObjectNode make sense? The digitalDocumentNode is the metadata record-- a digital document. |
|
here are the triples for my example 2 (syntax buggered up to make the lines shorter) this seems a lot clearer to me, the graph nodes have the same identifier as the thing they represent. |
|
Sure, you could do that, but I think it is incorrect to always infer that |
|
@smrgeoinfo In your example, what is returned when resolving |
|
I'd argue that what you get when you resolve a URI depends on what it identifies, and the conventions of the identifier scheme. Things are much more interesting if the metadata is about a non-digital object that might have multiple digital representations. Then the distribution section is critical. |
|
So I managed to get myself confused about a subject of the graph (i.e. Perhaps one approach is to consider is that we are making statements about the graph This results in quad statements like: This provides that statements about I don't think there are defined semantics for the intent of a named graph other than providing a context for statements to be made about the container of the graphs. Using the Does this approach provide any benefit over the arguably simpler alternative construct?: |
|
The latter approach is for the most part what we do in https://geoconnex.us, which is based on SELFIE |
|
After discussion at monthly group meeting, I'll edit guide text and create PR, based on the option 2 approach (same as second approach in @datadavev comment above). I think it should go in GETTING-STARTED.md because it applies to any SOSO metadata. |
building on #210, Here's a discussion thats come up in a CODATA WG. SOSO should weigh in on this issue in the guidelines.
A metadata record has two parts; one part is about the metadata record itself, the other part is the content about the resource that the metadata documents. The part about the record specifies the identifier for the metadata record, agents with responsibility for the record, when it was last updated, what specification or profiles the metadata serialization conforms to, and other optional properties that are deemed useful. The metadata about the resource has properties about the resource like title, description, responsible parties, spatial or temporal extent (as outlined in the Metadata Content Requirements section).
Schema.org includes several properties that can be used to embed information about the metadata record in the resource metadata: sdDatePublished, sdLicense, sdPublisher, but lacks a way to provide an identifier for the metadata record distinct from the resource it describes, to specify other agents responsible for the metadata except the publisher, or to assert specification or profile conformance for the metadata record itself.
There are two patterns that could be used to structure the two parts of the metadata record:
Option 1. The root object is the described resource:
Option 2: root object is the metadata record
The rdf triples generated by these two approaches are identical, so if the metadata are always harvested to a triple store it makes no difference. However, allowing either approach would create interoperability problems for harvesters that are parsing the metadata as JSON-- the paths to the same metadata elements are different in the two approaches. It is our judgment that option one above (root object is the described resource) is the more widely used serialization, commonly without specifying the metadata record specific properties, or using the schema.org ‘sd...’ properties to provide some of the metadata ‘metadata’.
what should be the recommended serialization?
The text was updated successfully, but these errors were encountered: