Sean, That's a fine basis for discussion, thanks.
- At the model level an Element id is always a full atomic IRI. That consensus was documented by William at the first ID meeting. - Shortening the IRI is done exclusively for serialization. The model includes information to facilitate serialization because without it you cannot round-trip across serializations other than by always serializing the full IRI string. - I strongly support a default namespace, which is represented by a namespace without a prefix in the prefixMap. The scope of the default prefix is identical to the scope of the explicit prefixes in the map. As we discuss serialized IRI shortening, we can rely on the fact that IRI syntax is defined by RFC 3986, but we should not define anything additional in SPDX that reduces generality. If there is some use of RFC 3986 generic or sub delimiter characters that does not cause problems with any form of IRI (including those with URN schemes) or any processing libraries/applications, then SPDX could document that syntax as a convention for creating examples. But syntax-based splitting cannot be required; Element creators must always be able to use option 1 (namespace map) to override any option 2 syntax-based conventions. The model should also define a hint separator to designate information added to the Element ID when serializing and removed when deserializing. Dave On Tue, Sep 14, 2021 at 2:18 PM Sean Barnum <[email protected]> wrote: > > The json-ld serialized example I showed on the call today can be found > here: https://gist.github.com/sbarnum/8b0ea8d173af8a4932c7301e49cdc3cf > > > > This example demonstrates: > > - Element identifiers with appropriate structure of namespace+localid > (does not presume any particular reserved separating character) > > - A mix of new elements defined within a document-centric namespace, > elements within other producer-controlled namespace, elements defined > external to the document by other producer, etc > > - Expression of prefixMap property of Document > > - How a given serialization (json-ld in this case) can leverage the > prefixMap to define id namespace prefixes > > - How those prefixes are applied to Element ids throughout the example > > - An external map characterizing all Elements within the Document that > were not defined locally within the document > > - Context metadata (createdBy, created, specVersion, etc) defined on the > document with the serialization-dependent specific implication that this > context metadata also applies to the Elements within the Document unless > directly overridden with properties on the individual Elements > > > > So, basically it demonstrates option2 from the call plus option1 all > within the context of real world potential complexities. > > > > Hopefully, it can be useful for visualizing many of the things we have > been discussing in a concrete fashion. > > > > sean > > > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#4181): https://lists.spdx.org/g/Spdx-tech/message/4181 Mute This Topic: https://lists.spdx.org/mt/85609325/21656 Group Owner: [email protected] Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
