Support for controlled probing of unlinked objects

[niklasl]

Currently, JSON-LD allows for undefined or null-bound terms, to make it possible to mix in plain old JSON in documents. This is to support e.g. legacy, annotation or application-specific purposes. We have looked into the possibility to "probe" values for such terms for more JSON-LD, but concluded that it would be to uncontrollable, given that data in such values may have entirely local meaning. Trying to parse that could result in unintentional gleaning of unexpected or strange data.

However, there is an opportunity here to let contexts declare that certain null-bound terms must be probed. Specifically, we could use @container for this purpose. Consider a term declaration like:

"isReferencedBy": {"@id": null, "@container": "@set"}

This would instruct a parser both to not intrepret isReferencedBy as a property (and thus not link from the current resource to the value), and to parse the value as if it was JSON-LD.

The specific value for @container must be decided of course. Here I use @set, which is under discussion and not currently part of JSON-LD. We could imagine @object here as well (or perhaps just true), to state that the value should be one specific object (and even @list to create a disconnected rdf:List).

A real use case where this might be applied is to allow for application-specific encoding of reverse relations (i.e. "things which links to this resource"). Here is an example of that:

{
  "@context": {
    "@language": "en",
    "title": "http://purl.org/dc/terms/title",
    "references": "http://purl.org/dc/terms/references",
    "isReferencedBy": {"@id": null, "@container": "@set", "_inverseOf": "references"},
  },
  "@id": "http://example.org/doc/core",
  "title": "Core",
  "isReferencedBy": [
    {
      "@id": "http://example.org/doc/primer",
      "title": "Primer",
      "references": {"@id": "http://example.org/doc/core"}
    }
  ]
}

Notice that if isReferencedBy is probed, the related object would be parsed, along with its link to the top-level resource. In other words, this makes for very usable JSON as well as a formal representation of the relevant underlying graph. (The _inverseOf is an example of how a non-standard, application-specific serializer extension which triggers this special representation form may look. That's really orthogonal to this issue though.)

[lanthaler]

This looks very interesting. A couple of questions:

• how would you see compaction/expansion/normalization see to process something like this?
• would using @graph be an alternative (aliasing it)?
• why aren't you using a real term in this example?
• do you see any other use cases?

[niklasl]

Thanks!

• I don't really know how this should be treated by the different algorithms. As this is an application-specific data extension at this time, I add it after (or actually, during) my own compaction. But I suppose data-carrying null-terms could/should be kept during compaction, with their inner data being subjected to compaction as well.
• Aliasing isReferencedBy here to @graph wouldn't work, since I'm not quoting a literal graph, but just a set of things. (The same reasoning as we did regardning @graph vs. @set in general applies here.)
• Real inverse terms: a good question with a multifaceted answer. It is often the case that properties don't have defined owl:inverseOf properties. And more crucially, I want to represent the graph as it is stated, with no inferred properties at this point. This has many reasons, from the traceability of how source data looks to things like even editing. (This question in extension takes us into debates about inverses in RDF in general, which are considered useful, and specifics such as @rev in HTML+RDFa, which have been contentious, and so on.)
• For keeping null-term data, I kinda wondered if you had more ready use cases at hand. :) I do see some potential in "compacting" long property paths for instance, to include data about important resources which are some distance away in the graph, arc-wise.

[lanthaler]

Just to make sure we are on the same page. The Turtle output of the document above would be

@prefix dc: <http://purl.org/dc/terms/> .

<http://example.org/doc/core> dc:title "Core" .

<http://example.org/doc/primer> dc:title "Primer" .
<http://example.org/doc/primer> dc:references <http://example.org/doc/core> .

Right? So the second part is basically just a disjoint graph.. I'm not sure I understand your argument against @graph. You are not quoting anything there IMO since the term isReferencedBy is not declared. So @graph, in this instance, could just mean start a new graph/restart graph parsing.

[dlongley]

It also seems to me that this could be achieved with a @graph alias.

[niklasl]

It would almost work, but doesn't really because using @graph like that makes the top-level resource a named graph. And AFAIK for that reason we don't allow @id and @graph in the same object (for now, to avoid making a final decision on the matter).

Also, the graph is not disjoint – the two resources described are linked together using references. But the use case here is to represent core, and so I have to attach the description of primer with some key "representing" an inverse somehow. By doing it with a null-key and also include the references link in that object, I get both the shape of JSON I need and preserve the data to represent the connection between the resources.

[niklasl]

It would also be good to know if others see value in the notion of an inverse (for e.g. framing purposes). We might be able to work more on that if so (there have been at least two of us who want something like @rev). But in any case, making this probing work should be good enough for me, and I can imagine it useful for other "artificial" relations other than inverses, such as informally collapsing long property paths.

[lanthaler]

Niklas, I think currently you could solve this in two ways. Either

{
  "@context": {
    "@language": "en",
    "title": "http://purl.org/dc/terms/title",
    "references": "http://purl.org/dc/terms/references",
  },
  "@id": "http://example.org/doc/core",
  "title": "Core",
  "isReferencedBy": {
    "@graph": [
        {
          "@id": "http://example.org/doc/primer",
          "title": "Primer",
          "references": {"@id": "http://example.org/doc/core"}
        }
      ]
  }
}

or

{
  "@context": {
    "@language": "en",
    "title": "http://purl.org/dc/terms/title",
    "references": "http://purl.org/dc/terms/references",
  },
  "@graph": [
    {
      "@id": "http://example.org/doc/core",
      "title": "Core",
    },
    {
      "@id": "http://example.org/doc/primer",
      "title": "Primer",
      "references": {"@id": "http://example.org/doc/core"}
    }
  ]
}

But I agree, both look quite ugly. But on the other hand you also have no way of expressing something like that in plain JSON without minting a dedicated rev-relation.

[dlongley]

Niklas, I don't think that the use of @graph is strictly for disjoint graphs. It just provides a way to describe disjoint graphs that share a context that wouldn't otherwise be possible. You could use @graph to list subjects that are all interconnected instead of embedding them; this is just a more flattened form of JSON-LD.

[niklasl]

Absolutely, that's how @graph works in general. I only pointed out that this graph is not disjoint for clarification. (And as explained, it can't be used as suggested, since we'd turn the root resource into a named graph.)

The point of this is to make a useful shape of the data, with the root being one single resource (the one which this JSON represents or describes), where things linking to it are also present via "reverse" links. Hence the flattened form won't do. The idea here is that by allowing for probing of null-terms where explicitly allowed, all of the data is also interpretable as RDF; nothing is pruned.

[lanthaler]

Niklas, do you have a specific idea how that should work in detail? Should it be possible to re-activate parsing at any level or do you see it more as "don't disable parsing for this term (and it child nodes) but don't interpret it as a property since there's no IRI available"?

[niklasl]

I think the latter is best, i.e. "parse the value for this term, but don't interpret it as a property since there's no IRI available". It makes things fully controllable and avoids any "active-null-term" from triggering parsing within opaque non-linked JSON. And I think it'd make the algorithm for this fairly simple.

Note that I'm not wedded to using @container. In fact, had not a @graph alias made the resource into a @graph (and collide with @id since we don't allow them together), it would be a good candidate.

My ideal would actually be to introduce @rev as a complement to @id. Meaning (as indicated above) a reverse relation for a property IRI. I've just gotten the impression (perhaps wrongly) that general probing of null-terms, building on existing mechanics, would be more acceptable for others. If that's not the case, I'd certainly prefer a @rev mechanism.

[lanthaler]

I would be fine with that behavior. It would be a trivial algorithm change IMO. So maybe let me try to formulate a

PROPOSAL: If a JSON-LD processor encounters a property for which there exists a term definition but no IRI-mapping. The processing (expansion/compaction/to RDF) algorithms won't change the property but restart the processing at the property's value.

Quite a clunky sentence - maybe you can come up with a better wording.

While I do see a value of rev, I don't think we should introduce it in this version of JSON-LD. There are different options to express such data and I think we should first get a feeling at how people will use JSON-LD before adding more features to it.

[lanthaler]

RESOLVED: Do not support controlled probing of unlinked objects for this version of JSON-LD.