how to make statements about a schema.org document -- rdf/json-ld @id interpretation issues...

[smrgeoinfo]

I'm working on distributed, federated catalog systems for data in which data providers 'publish' metadata for harvest by metadata aggregators who create indexes and search interfaces, for example the US NSF Decoder/GeoCODEs catalog, Ocean Info hub. In this context, it is useful to be able include information about a metadata record-- e.g. last modified date, creator, encoding format/profile, point of contact. 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.

In the CDIF working group (see WorldFAIR (D2.3) Cross-Domain Interoperability Framework (CDIF) we are having a discussion about the approach to serializing this information using json-ld/schema.org.

Given this metadata record (bare bones...):

{   "@context": "https://schema.org",
    "@id": "ex:URIforSomething",
    "@type": "ImageObject",
    "name": "Picture of analytical setup",
    "description": "Description of the resource",
    "identifier":"identifierStringForThing_in_the_world"
... lots of other stuff }

I need another graph node like

{
        "@id": "ex:URIforAnotherSomething",
        "@type": "DigitalDocument",
        "dateModified": "2017-05-23",
        "encoding": {
            "@type": "MediaObject",
    	    "dcterms:conformsTo": {"@id":"ex:cdif-metadataSpec"}
          },
          "creator": {
              "@type": "Person",
              "name": "Some Person",
              "identifier":"https://orcid.org/0000-0001-4021-9302"
            },
            "maintainer": {
              "@type": "Organization",
              "name": "Some Org",
              "identifier": "https://ror.org/02e2tgs60"
            }
        ?"about":"ex:URIforSomething"  OR... ?"identifier":"ex:URIforSomething"
    }

the idea is that dateModified, creator, maintainer, and encoding are about the metadata record

How to interpret some things here:

• I'm interpreting the json object with "@id": "ex:URIforSomething" as a metadata record about some resource (physical or digital) that we're interested in.
• "@id": "ex:URIforSomething" identifies a graph node. -- is that the thing in the world (image in this case), or the information about that thing represented in this json object.
• "@type": "ImageObject" does this mean "@id": "ex:URIforSomething" is a thing in the world that is an image object, or that the data type (i.e. the schema) for this json object conforms to 'ImageObject'
• does the "identifier": string identify something different from "@id": "ex:URIforSomething". Should it be there at all?

in the graph node about the other graph node (metadata about the metadata), is <ex:URIforAnotherSomething> <about> "ex:URIforSomething" or <ex:URIforAnotherSomething> <identifier> "ex:URIforSomething" or something else?

It seems that these are getting used lots of different way; I'm just wondering if there's any logically coherent consensus, or do we just define our CDIF profile the way we think it works best?

[smrgeoinfo]

I tried feeding the question to ChatGPT and Google CoPilot. The interpretation of the identifiers is different in the two responses, supporting the conclusions they both arrive at:

• there is no consensus on this question
• define CDIF profile with clear rules and consistent use of Schema.org terms. As long as the approach is logically coherent and well-documented, it should serve effectively

If you're interested, here's some key points from the LLM responses:

Copilot (preview):

@id: “ex:URIforSomething”`:

• This line represents a unique identifier for the metadata record.
• The value “ex:URIforSomething” ... uniquely identifies the metadata record.
• It doesn’t necessarily represent the actual resource (e.g., an image) but rather the metadata record associated with that resource.

identifier: “identifierStringForThing_in_the_world”`:

• The identifier property provides an additional identifier for the metadata record.
• It helps uniquely identify the metadata record within a specific context.

Consensus and Best Practices:

• While there isn’t always a strict consensus, the key is to ensure that your use of JSON-LD aligns with your specific requirements.
• Schema.org provides flexibility, and you can define your CDIF profile based on what works best for your use case.
• As long as your approach is logically coherent and well-documented, it should serve your purpose effectively.

Remember that JSON-LD allows you to express rich semantics and relationships, and you can adapt it to suit your specific needs.

chatGPT4.0

@id Interpretation:

-- The @id attribute in JSON-LD is used to uniquely identify a node in the RDF graph. This can represent either the actual resource (e.g., an image) or the metadata record about the resource, depending on the context.

identifier vs. @id:

• The identifier property typically provides an identifier for the resource described by the metadata, which can be different from the @id used within the JSON-LD graph.
• The @id is used to identify the node within the graph, while identifier can be a string or URL that uniquely identifies the actual resource.

Logical Coherence and Consensus

There is a degree of flexibility in how these properties are used, which can lead to variations. However, to ensure logical coherence, you should:

• Define clear guidelines in your CDIF profile to avoid ambiguity.
• Align with best practices and standards from Schema.org and other relevant bodies (like W3C) to maximize interoperability.
• Use properties consistently across different metadata records to ensure clarity and ease of interpretation.

In summary, while there might not be a universal consensus, defining your CDIF profile with clear rules and consistent use of Schema.org terms will help maintain logical coherence and improve interoperability.

[MatthiasWiesmann]

What about having a MetaData object, which is the child of CreativeWork, and whose about field contains the actual Data object and a reverse metadata property on CreativeWork?

[github-actions[bot]]

This issue is being nudged due to inactivity.