Specify a node type when interpreting JSON as JSON-LD (was: use of "@type" in "@context")

[ioggstream]

Question

It's not clear to me if it's legitimate to use @type in @context instead of in the JSON object, eg.

"@context":
  "@vocab": "https://schema.org/",
  birthplace:
    "@type": "City"
birthplace:
  name: Roma

since the jsonld playground renders this as

_:c14n0 <https://schema.org/birthplace> _:c14n1 .
_:c14n1 <https://schema.org/name> "Roma" .

while I expect

_:c14n0 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://schema.org/City> .
_:c14n0 <https://schema.org/name> "Roma" .
_:c14n1 <https://schema.org/birthplace> _:c14n0 .

Note

changing the payload to

"birthplace": "Roma"

results in

_:c14n0 <https://schema.org/birthplace> "Roma"^^<https://schema.org/City> .

meaning that in some way the "City" type is processed in some way.

[pchampin]

@type is a bit polysemic in JSON-LD, which can be confusing (you are not the first one).

• @type in a node object adds an rdf:type arc to the RDF graph (it also has a few other effects on processing, e.g. by enabling type-scoped contexts)
• @type in a value object specifies the datatype of the produced literal
• @type in the context, more precisely in a term definition, specifies type coercion. It only applies when the value of the term is a string, hence the change of behaviour in your "Note" above.

Type coercion can not be used to automatically add an rdf:type arc to a graph. Its purpose is only to change the kind of node generated from a string. More precisely:

• if @type is @id or @vocab, the string generates an IRI node,
• otherwise, the string generates a literal with a specific datatype.

[ioggstream]

The use case is the following:

I need to provide a framework to create jsonld annotated payloads out of existing json APIs payloads.
Currently I'm able to use @context for that, and the missing core feature is the one of attaching a class to an object.

Is it possible to register and publish an extension keyword to json-ld (eg. a @class keyword) to achieve that goal?

cc: @ccattuto

[gkellogg]

There is no such registration mechanism, although the API spec does have some processing considerations for things that look like keywords.

In the past, when people were trying to use @type in a JSON-LD context to coerce a node object to have an @type, we've pointed them to use JSON-LD Framing, which is specifically intended to allow the transformation of JSON-LD documents, including adding default values for things like @type.

[ioggstream]

we've pointed them to use JSON-LD Framing, which is specifically intended to allow the transformation of JSON-LD documents

I used Framing to transform RDF in plain json objects: I'll check if there's a way to use it for transforming json in RDF

[ioggstream]

@pchampin

Type coercion can not be used to automatically add an rdf:type arc to a graph
Ok.

It seems this is a recurring issue:

• type coercion: coerce node types #31
• 2018 minutes
• Node Types in @context #76
• ...
  and this is not supported because the spec does not want @context to add triples, right? It can be reasonable, but I'm still investigating. I think it's not a matter of security, since altering the context is still critical with or without rdf:type, and if there are integrity concerns, they should be addressed using digital signatures.

Still in my perspective, this makes quite complex adding metadata to existing APIs without
impacting on the currently exchanged payloads (in my perspective, rdf:type is a metadata, but iiuc it can be considered actual data).

"@context":
  "@vocab": "https://schema.org/",
  birthplace:
    "@a": "http://schema.org/City"
birthplace:
  name: Roma

->

_:c14n0 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://schema.org/City> .
_:c14n0 <https://schema.org/name> "Roma" .
_:c14n1 <https://schema.org/birthplace> _:c14n0 .

@gkellogg While I read the threads, it's not clear to me how framing can help, since:

• the information source of Framing spec is a JSON-LD document (eg. a RDF file).
• my goal is to interpret a JSON document to a JSON-LD doc, which is similar to Type Coercion / Node Conversion: @coerce keyword or similar #335 (even if coercion is probably not the right word).

cc: @giorgialodi @msporny @pietercolpaert

[pchampin]

this is not supported because the spec does not want @context to add triples, right?

Exactly. And this choice is not a matter of security, but more of bounding the complexity. JSON-LD does not aim to allow you to express any arbitrary JSON to RDF transformation.

in my perspective, rdf:type is a metadata

That's an interesting way to look at it... but the stance taken by JSON-LD is that it is just another arc.

Another possible way to solve your problem would be to rely on RDFS and some form of (light) inference. What you want to encode in your context looks very much like an rdfs:range in RDFS, more precisely:

schema:birthplace rdfs:range schema:City.

[ioggstream]

@pchampin thanks for your reply.

the stance taken by JSON-LD is that it is just another arc
Ok.

How is it possible to express rdfs:range in @context without modifying the json payload?

As an example, this patched API editor can transform a JSON payload to RDF using the information provided by a @context: it just lacks type information (eventually from rdfs:range) to retrieve information from the sparql server.

[pchampin]

How is it possible to express rdfs:range in @context without modifying the json payload?

rdfs:range should go neither in the @context nor in the payload. It should be part of the definition of the vocabulary your JSON-LD context maps to. (ok, in the example above, this didn't quite work, as you can not add the rdfs:range triple in schema.org...).

To rephrase my proposal: you do not explicitly add the rdf:type arc in your graph, but you declare your vocabulary/ontology in such a way that the rdf:type can be inferred from the users of your data.

Mind you: I perfectly understand that this option may not work in all contexts (some users will not have the ability to perform any kind of inference, not even as light as RDFS). But I think it is worth putting in on the table.

[ioggstream]

@pchampin now it is clear :) Actually we provide something like that in the patched editor above.

In some cases, a given field can have multiple possible classes. Other times, we would like a schema designer to start from a rdf:type and identify properties starting from there.

iiuc this is something that's not going to be supported in json-ld.

Since a preliminary goal is to attach a semantic context for OAS3-described APIs
I'll just limit to the information available via the context.

Next, I'll identify a way to describe in OAS3 documents the remaining information
such as rdf:type.

Thanks again for your time Pierre-Antoine.

@gkellogg if this is a definitive wont-fix, please feel free to close.

cc: @giorgialodi @pietercolpaert @ccattuto

[msporny]

@ioggstream wrote:

iiuc this is something that's not going to be supported in json-ld.

Correct, however, what we recommend that people do to support the sort of use case you're describing is to write a pre-processor or post-processor. The feature you're describing is a fairly simple function written in most languages that just searches the document structure for specific keywords (either before or after JSON-LD processing) and injects new nodes into the graph. So, you could wait around for the JSON-LD WG to decide to implement, standardize, test, and publish a new standard... OR, you could just implement it in 10 lines of code or so. :)

My suggestion is you write some code to do this, point to the code, and perhaps others will find your code useful as a JSON-LD pre/post-processor.

[ioggstream]

write a pre-processor...10 LoC
yep, but...

we're working on a national API catalogue, and we want to add the ability for API providers to attach semantic information to the existing json schema documents. The goal is to define a syntax allowing to describe all relevant information to interpret json as json-ld for existing APIs, so before writing code, the issue for me is how to describe the nodes to be added.

I wrote a little gdoc with the problem statement...

[rob-metalinkage]

Thanks @ioggstream for the doc. I'm also looking into this in the context of a community with a series of JSON schemas (often competing in scope due to different histories) and OpenAPI usage. I have looked at the requirements and logic here Domain model interoperability - a work in progress - this thread had been helpful in confirming my understanding of the scope of json-ld-framing at least - thanks,

I see lots of statements about "you will need a parser" etc - but I havent seen any articulation of the overall architecture being discussed - only bottom-up analyses of options and challenges. The default architecture of the web is client->server with some negotiation -> resources with links to other resources. I was excited when i found this.. https://www.w3.org/standards/webarch/principles ... but it didnt last long :-(