YAML LD media type and profiles

[VladimirAlexiev]

We need to apply for application/ld+yaml media type. @ioggstream "I'm working on the YAML media type registration https://ietf-wg-httpapi.github.io/mediatypes/draft-ietf-httpapi-yaml-mediatypes.html and we already have an issue related to the registration of https://github.com/ietf-wg-httpapi/mediatypes/issues/8".

In addition, it seems clear to me that we'll need various YAML-LD profiles, eg as per #6 by @pchampin . See https://www.w3.org/TR/dx-prof-conneg/

[ioggstream]

I need some feedback from all of you on the yaml fragment identifier registration https://github.com/ietf-wg-httpapi/mediatypes/pull/47

If the YAML fragid definition works for yaml-ld, then we can just reference the IETF document. Otherwise there will be some work to do to define a specific fragment identifier for yaml-ld.

About the media type registration, I think that if we have something that is highly compatible with ld+json, it's ok to register yaml-ld as ld+yaml. Otherwise we should probably leave ld+yaml for the subset of highly interoperable functionalities and declare a new format (e.g. ldplus+yaml, ... )

[gkellogg]

I think we're going to need to consider different profiles. YAML provides a number of facilities that JSON does not (datatypes and fragment identifiers, for example). A "Base" level profile should restrict itself to strict JSON transcoding capability. We may consider an "extended" profile that allows for more use of these features, but the consequences for transcoding to JSON and maybe CBOR can get intense. I'd say that the group should focus on the "Base" level and consider an extended profile subsequently.

[anatoly-scherbakov]

I will need to read up on those YAML features because, though I've been using YAML for a while both for work and hobby projects, I hadn't really needed them... I would argue that most users will stick to the most naive version of the language.

@ioggstream YAML fragments. Had it been considered to use file.yaml#one instead of file.yaml#foo? In other words, to use paths to nodes instead of their fragments.

Fragments create another naming system, in addition to the one natively defined to the document. Another example: file.yaml#one.some_items[0].child?

I understand the pros of using a global name instead of a lengthy path, but in an arbitrary YAML document where anchors are not set nothing can be referenced, if I understand the idea correctly.

[ioggstream]

@anatoly-scherbakov about YAML fragments, the current PR proposal supports the following patterns

file.yaml#*alias-node
file.yaml#/json/path
file.yaml# 

YAML alias nodes are identified according to YAML spec and YAML media types document aims at not creating inconsistencies or constraints on how YAML works, nor how it can evolve.

in an arbitrary YAML document where anchors are not set nothing can be referenced, if I understand the idea correctly.

This the reason for https://github.com/ietf-wg-httpapi/mediatypes/pull/47 that arose after discussing with CBOR folks.

[anatoly-scherbakov]

Oh I see. Thank you for the clarification! This looks interesting. @ioggstream

[ioggstream]

I think you all can be interested in the associated discussion https://github.com/ietf-wg-httpapi/mediatypes/issues/41 cc: @anatoly-scherbakov @VladimirAlexiev

[VladimirAlexiev]

hi @ioggstream YAML fragment identifiers is an important topic, but is too technical for me to give meaningful feedback without a briefing from you (which you could do in the first telco or shortly thereafter).

Also, it is a different topic from media type and profiles. Please, when you post an important topic, do it as a separate issue, else your concerns get lost in the stream of other concerns.

Some concrete considerations:

• file.yaml#/json/path is compatible with JSON Schema use, right?
• what's the empty fragment file.yaml# and how is it different from file.yaml
• RDF/XML, Turtle and JSON-LD allow to define a base different from the physical file location (JSON-LD context even has two, @base vs @vocab), has a similar feature been designed?

[VladimirAlexiev]

@gkellogg thanks for the PR! I commented in just 1 place.

@ioggstream Given your https://github.com/ietf-wg-httpapi/mediatypes/pull/47, are you happy with closing this issue? It also talks about fragment identifiers, but we better move this to another issue.

[gkellogg]

@VladimirAlexiev the question on namespace deserves its own issue. I'm coming around to having a /ns/yaml-ld namespace for YAML-LD specific profile IRIs as being the least surprise, but we should track that as a CG decision.