Consider adding schema.org's sdPublisher, sdLicense & sdPublished to CTDL and CDL-ASN

[stuartasutton]

For a long while we had an issue on how to differentiate rights assertions in the metadata representation of a competency framework of a credential etc. Within the last year or so, schema.org added three properties that could serve is (even thought they break the one-to-one rule by describing th metadata about the resource and not the resource).

schema:sdDatePublished a rdf:Property ;
    rdfs:label "sdDatePublished" ;
    schema:category "issue-1886" ;
    schema:domainIncludes schema:CreativeWork ;
    schema:isPartOf <http://pending.schema.org> ;
    schema:rangeIncludes schema:Date ;
    schema:source <https://github.com/schemaorg/schemaorg/issues/1886> ;
    rdfs:comment "Indicates the date on which the current structured data was generated / published. Typically used alongside <a class=\"localLink\" href=\"http://schema.org/sdPublisher\">sdPublisher</a>" .

schema:sdLicense a rdf:Property ;
    rdfs:label "sdLicense" ;
    schema:category "issue-1886" ;
    schema:domainIncludes schema:CreativeWork ;
    schema:isPartOf <http://pending.schema.org> ;
    schema:rangeIncludes schema:CreativeWork,
        schema:URL ;
    schema:source <https://github.com/schemaorg/schemaorg/issues/1886> ;
    rdfs:comment "A license document that applies to this structured data, typically indicated by URL." .

schema:sdPublisher a rdf:Property ;
    rdfs:label "sdPublisher" ;
    schema:category "issue-1886" ;
    schema:domainIncludes schema:CreativeWork ;
    schema:isPartOf <http://pending.schema.org> ;
    schema:rangeIncludes schema:Organization,
        schema:Person ;
    schema:source <https://github.com/schemaorg/schemaorg/issues/1886> ;
    rdfs:comment """Indicates the party responsible for generating and publishing the current structured data markup, typically in cases where the structured data is derived automatically from existing published content but published on a different site. For example, student projects and open data initiatives often re-publish existing content with more explicitly structured metadata. The
<a class="localLink" href="http://schema.org/sdPublisher">sdPublisher</a> property helps make such practices more explicit.""" .

[siuc-nate]

Interesting. I would advise encapsulating such meta properties inside of a well-defined class (something that screams "this is metadata") so that it can be more easily applied to whatever other classes may need it, now or in the future as such a meta class evolves. This will also help segregate them from the rest of the data (i.e. meta properties won't be intermingled with "real" properties in the terms pages or the records or anywhere else). It also opens the door to using existing properties in a metadata context, which may have additional benefits and solve some of the problems we're tackling on the registry side.

Example:

{
  "@type": "ceterms:Certificate",
  "ceterms:name": { "en": "Welding certificate" },
  "ceterms:etc": "etc.",
  "ceterms:hasMetadata": {
    "@type": "ceterms:Metadata",
    "ceasn:dateCreated": "2020-1-1",
    "ceasn:dateModified": "2020-11-16",
    "ceasn:rights": "https://example.com/rights/123",
    "ceasn:publisher": "https://credentialengineregistry.org/resources/ce-somectidforathirdpartypublisher",
    "ceterms:owner": "https://credentialengineregistry.org/resources/ce-somectidforadataowner"
  }
}

That said, it does create an awkward situation where there will be metadata in both the envelope and the payload.

Maybe it would be better to make such a property be a URI reference to that envelope? Then again, that envelope uses a bespoke schema, so that's not exactly preferable either.

{
  "@type": "ceterms:Certificate",
  "ceterms:name": { "en": "Welding certificate" },
  "ceterms:etc": "etc.",
  "ceterms:hasMetadata": "https://credentialengineregistry.org/envelopes/ce-ece7cefa-3c0f-42fe-9e51-f24e5489aa0c"
}

Perhaps some parameter can be added to whatever solution comes out of this issue that will enable fetching the envelope data on-demand but translating it to use schema.org/ctdl/etc. properties so it will be valid JSON-LD?

{
  "@type": "ceterms:Certificate",
  "ceterms:name": { "en": "Welding certificate" },
  "ceterms:etc": "etc.",
  "ceterms:hasMetadata": "https://credentialengineregistry.org/envelopes/ce-ece7cefa-3c0f-42fe-9e51-f24e5489aa0c?includeresource=false&jsonld=true"
}

This is a conversation we should probably involve @science and @Lomilar in, as we might be able to mutually benefit from some kind of shared idea about how the architecture should handle this kind of data.

At the very least, I would hope that the envelope signatures wouldn't be a problem since all of the publishing goes through our system and this is something we would be able to inject in that process (correct me if I'm wrong, @mparsons-ce ).

[siuc-nate]

Alternatively, such a property might deliberately not be part of the schema proper, e.g.:

{
  "@type": "ceterms:Certificate",
  "ceterms:name": { "en": "Welding certificate" },
  "ceterms:etc": "etc.",
  "@metadata": {
    "@type": "ceterms:Metadata",
    "ceasn:dateCreated": "2020-1-1",
    "ceasn:dateModified": "2020-11-16",
    "ceasn:rights": "https://example.com/rights/123",
    "ceasn:publisher": "https://credentialengineregistry.org/resources/ce-somectidforathirdpartypublisher",
    "ceterms:owner": "https://credentialengineregistry.org/resources/ce-somectidforadataowner"
  }
}

which should be valid (but ill-advised) JSON-LD, or:

{
  "@type": "ceterms:Certificate",
  "ceterms:name": { "en": "Welding certificate" },
  "ceterms:etc": "etc.",
  "_metadata": {
    "@type": "ceterms:Metadata",
    "ceasn:dateCreated": "2020-1-1",
    "ceasn:dateModified": "2020-11-16",
    "ceasn:rights": "https://example.com/rights/123",
    "ceasn:publisher": "https://credentialengineregistry.org/resources/ce-somectidforathirdpartypublisher",
    "ceterms:owner": "https://credentialengineregistry.org/resources/ce-somectidforadataowner"
  }
}

which stands out and could still be defined in the JSON-LD context in order to be valid (unless I'm missing something), or:

{
  "@type": "ceterms:Certificate",
  "ceterms:name": { "en": "Welding certificate" },
  "ceterms:etc": "etc.",
  "meta:hasMetadata": {
    "@type": "ceterms:Metadata",
    "ceasn:dateCreated": "2020-1-1",
    "ceasn:dateModified": "2020-11-16",
    "ceasn:rights": "https://example.com/rights/123",
    "ceasn:publisher": "https://credentialengineregistry.org/resources/ce-somectidforathirdpartypublisher",
    "ceterms:owner": "https://credentialengineregistry.org/resources/ce-somectidforadataowner"
  }
}

which puts the term into the meta schema we somewhat hesitantly use in other places.

[stuartasutton]

@siuc-nate, that's exactly what ASN did. Within an @graph, they have their StandardDocument entity and the array of Statements entity and a separate description block (unclassed) for their equivalent of these schema.org terms that uses foaf:primaryTopic to poins to the StandardDocument.

[stuartasutton]

Don't use "meta"...pleasew.

[siuc-nate]

Would this be something reliant on/required of the publisher of the data or would it be injected by the registry? How would this work for entities like concepts and competencies? What about collections?

[siuc-nate]

Archiving this, as it hasn't seen demand in a few years.

Suggestion if it ever gets reopened - look at the @included feature of JSON-LD.

[philbarker]

Suggestion if it ever gets reopened - look at the @included feature of JSON-LD.

no, that's not what @included is for, @included is just some syntactic sugar for importing data into a JSON-LD block, it's not semantic and the meaning is no different to just making the statements directly. Named Graphs are the closest to an RDF solution to this, see #805.