search

json-ld / yaml-ld

CG specification for YAML-LD and UCR
https://json-ld.github.io/yaml-ld/spec
Other
22 stars 8 forks source link

Defining various interoperability profiles #35

Open ioggstream opened 2 years ago

ioggstream commented 2 years ago

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

Elements to be discussed in profiling

ioggstream commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

@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 commented 2 years ago

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 commented 2 years ago

This issue was discussed on the Aug 03 meeting.

gkellogg commented 2 years ago

See https://github.com/json-ld/yaml-ld/issues/17#issuecomment-1207278736 for a related discussion.