YAML-LD IRI tags

[gkellogg]

The so-called "extended" profile of YAML-LD makes use of YAML's tag mechanism to cause values to be interpreted as RDF literals with a datatype coming from the expanded tag (or language, through restricted use of the i18n namespace). This is particularly useful for environments where fetching a remote context remains an issue. What this doesn't provide for is a way to natively represent IRIs and Blank Nodes. Currently, this requires using a new node object:

"@id": https://json-ld.github.io/yaml-ld/spec # This is interpreted as an IRI by JSON-LD algs
homepage:
  "@id": https://example.org/foo

If "homepage" were defined with "@type": "@id" in a term definition, the indirection through a node object isn't required.

As IRIs don't have their own datatypes, the use of the YAML node tag mechanism, where the tag is a URI becomes semantically problematic, but YAML allow the use of local tags, and we could consider defining such a tag to be interpreted by YAML-LD processors (operating in extended mode). For example:

"@id": https://json-ld.github.io/yaml-ld/spec # This is interpreted as an IRI by JSON-LD algs
homepage: !id  https://example.org/foo # Can be treated as an IRI (or blank node) by a YAML-LD processor.

This would cause a YAML-LD processor to interpret values tagged with the !id local tag to be interpreted as either an IRI or blank node, similar to how values of the @id key in JSON-LD are interpreted, but avoids the indirection through a node object by extending the internal representation to be able to represent IRIs and Blank Nodes as scalar values, in addition to RDF literals, strings, numbers, boolean and null.

[VladimirAlexiev]

I fully support the proposal to have a tag for IRIs.
@gkellogg:

• What is the relation between "@id" and !id? IMHO the former doesn't declare the latter in any way.
• AFAIK, we need to "declare" this !id tag on a page, as we see in the examples here: https://yaml.org/type/
• The spec https://yaml.org/spec/1.2.2/#chapter-10-recommended-schemas lists only 4 tag schemas (of which the "Core" schema is most extensive), but https://yaml.org/spec/1.2.2/#104-other-schemas seems to provide more options
• Should we also declare a regex eg <[^ ]+>? use regular expressions to resolve literals; URIs, CURIEs #83

[gkellogg]

I fully support the proposal to have a tag for IRIs. @gkellogg:

• What is the relation between "@id" and !id? IMHO the former doesn't declare the latter in any way.

We would need to define it. IIUC, !id is defined as a [local tag](https://yaml.org/spec/1.2.2/#tags), which is application specific.

• AFAIK, we need to "declare" this !id tag on a page, as we see in the examples here: https://yaml.org/type/

IIRC, that page defines "Language-Independent Types" using the !! syntax, not local tags. I'm not aware of a mechanism for defining local/application specific tags.

• The spec https://yaml.org/spec/1.2.2/#chapter-10-recommended-schemas lists only 4 tag schemas (of which the "Core" schema is most extensive), but https://yaml.org/spec/1.2.2/#104-other-schemas seems to provide more options

Section 5.5 on Converting a YAML scalar indicates using the Core Schema. Again, no discussion – as yet – of local tags.

• Should we also declare a regex eg <[^ ]+>? use regular expressions to resolve literals; URIs, CURIEs #83

YAML tags already use an expression for URIs, although possibly not completely compatible, and with implementation issues for things like '#'.

For dealing with values with the proposed node-tag !id, we would need to rely on a description certainly for distinguishing blank nodes, and allow for relative IRIs and compact IRIs. Probably just defer to the paragraph on Node Objects from JSON-LD to have the same value space and semantics as @id:

If the node object contains the @id key, its value MUST be an IRI reference, or a compact IRI (including blank node identifiers). See § 3.3 Node Identifiers, § 4.1.5 Compact IRIs, and § 4.5.1 Identifying Blank Nodes for further discussion on @id values.

[VladimirAlexiev]

@gkellogg I think the problem is not "local vs global" tags.
At https://onlineyamltools.com/convert-yaml-to-json, I can use the default global tags !!str, !!float, !!timestamp without declaring them.
But I can also use the standard tags as local tags:

%TAG ! tag:yaml.org,2002:
---
name:  !str Gregg Kellogg
float: !float 1.235609853907835079889067406870964870956870967908
date:  !timestamp 2022-08-08

I think the problem is that parsers don't know about our desired/intended tags, such as !id, !integer, !dateTime.
Eg https://onlineyamltools.com/convert-yaml-to-json doesn't accept custom tags, no matter local or global.
@anatoly-scherbakov is also concerned about this.

[gkellogg]

@gkellogg I think the problem is not "local vs global" tags. At https://onlineyamltools.com/convert-yaml-to-json, I can use the default global tags !!str, !!float, !!timestamp without declaring them. But I can also use the standard tags as local tags:

%TAG ! tag:yaml.org,2002:
---
name:  !str Gregg Kellogg
float: !float 1.235609853907835079889067406870964870956870967908
date:  !timestamp 2022-08-08

Yes, but the purpose of this tool does seem to be converting YAML to JSON, which, of course, is limited to JSON datatypes. The Extended Internal Representation, which might contain IRIs, but also RDF literals with datatypes, is outside of the JSON data model, thus the need to either map it to something that extends that data model, or encodes the values using something like JSON-LD value objects.

Leveraging a tool such as https://onlineyamltools.com/convert-yaml-to-json might not be directly useful for doing this, but lower-level tools, such as https://github.com/yaml/libyaml can use non-default tags.

I think the problem is that parsers don't know about our desired/intended tags, such as !id, !integer, !dateTime. Eg https://onlineyamltools.com/convert-yaml-to-json doesn't accept custom tags, no matter local or global. @anatoly-scherbakov is also concerned about this.

There are parsers (many flawed) that can represent arbitrary scalars with node tags outside of the default set, otherwise, what would be the value in YAML allowing the use of %TAG directives and node tags to be able to specify them. Granted, this is beyond the case of the typical use of transforming YAML straight to JSON.

We have the YAML-LD-JSON profile specifically for dealing with these standard types, the purpose of the extended profile is to allow for more use of YAML features, and likely limits the use of off-the-shelf tools – specifically those intended for transforming straight to JSON.

Otherwise, do you have thoughts on what an extend profile might do beyond the straight JSON transliteration case?

[gkellogg]

Discussed at TPAC F2F

[VladimirAlexiev]

@gkellogg I completely agree with you: we shouldn't be straight-jacketed into a particular parser. Our extended profile should demand a more powerful parser that allows custom tags.

This YAML

'@context': {id: '@id', knows: '@id'}
id: gkellogg
knows: vladimir
alsoKnows: !id anatoly
birthDate: !xsd!date 1960-01-01

should be converted to this JSON

"@context": {"id": "@id", "knows": "@id"},
"id": "gkellogg",
"knows": "vladimir",
"alsoKnows": {"@type": "@id", "@value": "anatoly"},
"birthDate": {"@type": "xsd:date", "@value": "1960-01-01"}