Defining various interoperability profiles

[ioggstream]

As an Editor
I want a set of different interoperability profiles
So that I can select the YAML features that are supported by a YAML-LD implementation

Note

For example I could define

• a BASE profile that is just JSON with YAML syntax: no anchors / alias nodes, only string keywords, only JSON datatype values, comments
• an EXTENDED profile: with anchors / alias nodes but only with a rooted directed acyclic graph

Elements to be discussed in profiling

• data types https://github.com/json-ld/yaml-ld/pull/34/files#r912093915
• usage of anchors / alias nodes
• multiple documents separated by ---
• non-string keywords
• TODO

[ioggstream]

From @gkellogg https://github.com/json-ld/yaml-ld/pull/34/files#r912093915

We should probably discuss how YAML dates and dateTime (equivalents) are treated. Presumably, as part of the extended
profile, they can be expanded into their equivalent JSON-LD/XSD form, although considering the affect of context definitions
for properties of which they are the value may complicate this somewhat.

we need to get in touch with YAML folks for that. dates are discouraged

Also, are YAML-LD processors required to parse all input regardless of the stated profile (expanded or basic), or only if the
appropriate profile is set?
I think the rule of profile parameters is that they don't change the semantics, so they either MUST process all forms, or error if
the form is incorrect. (should be an issue).

A YAML parser will always create a representation graph (e.g. with anchors/aliases). You'll know whether a profile matches only after processing. Profiles will probably help in managing the representation graph (e.g. ensure that's a tree, ...) and serializing it.

[rob-metalinkage]

Hi - if we use the PROF (https://www.w3.org/TR/dx-prof/) vocabulary to describe profiles, then we can formalise these and use content-negotiation to deliver contexts, SHEX and SHACL validators. As editor of PROF I'd be more than happy to add a YAML-LD implementation to the PROF resources. As an OGC resource publicatuin infrastructure manager happy to support YAML-LD versions of resources.

[gkellogg]

@rob-metalinkage Is this use consistent with JSON-LD's profile parameters? Did we miss something there? The intention is that clients be able to specify profiles and servers respond accordingly.

[rob-metalinkage]

There are at least two orthogonal (I think) things here - the serialisation profile as described in the spec

"JSON-LD's media type defines a profile parameter which can be used to signal or request flattened document form. The profile URI identifying flattened document form is http://www.w3.org/ns/json-ld#flattened. It can be combined with the profile URI identifying expanded document form or compacted document form."

and the information model profile - what view of an object, i.e. its shape or frame - or selection of possible attributes in the wider OWA possibilities that are available.

The PROF vocabulary is agnostic about what aspects are profiled - you can describe any aspect of resources - such as licence conditions etc - just like Java interface classes.

So the question here boils down to what aspects of interoperability are intended by the requested profiles. AFAIC if there is information content available in YAML-LD not JSON-LD, then a profile of YAML-LD comaptible with JSON-LD is an information model profiling requirement, not a serialisation one as supported by the media type profiling mechanism.

[gkellogg]

This issue was discussed on the Aug 03 meeting.

[gkellogg]

See #17 (comment) for a related discussion.