Container for Metadata License (boilerplate) Injected by Registry and Not Dependent on Publisher

[jeannekitchens]

Regardless of the technical implications for the registry and our partners, the overall solution looks like the below model. The output needs to be proper RDF.

The technical implementation requires a determination of the "container":

• @graph:
  • How does this interact with the other envelope data during distribution?
  • Does the envelope contain a @graph which in turn contains the license and payload?
  • Or does the license object get included in the envelope and the payload is raw?
  • The system will need to force returning a @graph when data is pulled by its CTID
  • Would this be a single object or an object with an @context and a @graph?
• Envelope:
  • The system will need to force returning an envelope when data is pulled by its CTID (no capacity to return raw payloads on their own)
  • Could the envelope's pieces be transformed into a @graph with appropriate context data?

Sample structures:

Graph:

Anonymous Wrapper (Root object)
                @context
                @graph
                                Metadata License
                                Payload JSON-LD

Envelope:

Envelope (Root object)
                Metadata License
                Other envelope data
                Payload JSON-LD

Hybrid:

Envelope (Root object)
                Other envelope data
                Anonymous Wrapper
                                @context
                                @graph
                                                Metadata License
                                                Payload JSON-LD

[stuartasutton]

I am not sure I am adding anything here or perhaps misinterpreting the graphic, but the metadata license boilerplate should, at a minimum, appear in the resource RDF payload so it is present in the wild where no envelop is involved.

[siuc-nate]

There are a few issues/questions/approaches there:

1. When an envelope is involved, the payload's signature is included. Modifying the payload in this case breaks the signature and makes it look like all of the records in the registry were tampered with. So we would need to include the license outside of the payload, in the envelope itself. We'd need a property to attach it to.

2. When there is no @graph to return, we would have to create a property (maybe use the same property as we use inside the envelope?) inside of the JSON object itself (the payload) to add the license information. This is doable, but data consumers will need to be aware of it.

3. When there is a @graph to return, we could add the license to it as the last item in the @graph in order to avoid breaking applications that are "dumbly" only looking at whatever resource is the first object in the @graph and expecting that to be the main payload (although maybe we shouldn't worry about that?). Alternatively, we could, at the risk of violating the JSON-LD spec(?), include the license as the value for a property at the same level as @context and @graph in order to be consistent with the other two approaches where systems will be looking for that property.

[stuartasutton]

@siuc-nate, just to make sure I am understanding @graph, the metadata license should be there when I retrieve a competency framework and it's associated competencies. There is no need to include the metadata license for interactions on a single subgraph...e.g., "give me competency X". The point is to include it at points of "distribution".

We have no similar clean distinction with metadata license with credentials.

[siuc-nate]

The items described in my previous post would apply regardless of the @types involved, unless we did something special for certain cases.