json-ld / json-ld-star Goto Github PK

The current spec says that

An embedded node MUST NOT, itself, use a reverse property.

I am wondering why this behaviour was chosen?

It seems reasonable to me to explicitly allow this behaviour.

For example, the following snippet would produce the following when applying the toRdf algorithm:

{
  "@context": {
    "rel": {"@reverse": "ex:rel"}
  },
  "@id": {
    "@id": "ex:rei",
    "rel": {"@id": "ex:value"}
  },
  "ex:prop": "value2"
}

<<ex:value ex:rel ex:rei>> ex:prop "value2".

As illustration, I have implemented this behaviour into jsonld-streaming-parser.js behind the rdfstarReverseInEmbedded flag.

Some people might be interested to use the features of JSON-LD-star even if their RDF tooling does not support RDF-star...
We could make rdfstar an option rather than a flag, with multiple possible values:

• false would be the default: embedded triples and annotations are not supported
• "native" or true would be the current behaviour when the flag is set (i.e. produce native RDF-star)
• "reification" could instead use the standard reification vocabulary to "encode" embedded triples
• "graph" could instead use named graphs (containing a single triple) to encode embedded triples

ReSpec updates prevent us from doing the old restrictReferences when importing terms, which means that many terms are referenced which are never used in the spec. It would be good to figure this out again, or redo our terms more manually, to remove spec blot.

https://json-ld.github.io/json-ld-star/#example-embedded-node-as-subject:
If I add another key (eg sex) inside @id:

  "@id": {
    "@id": "bob",
    "age": 42,
    "sex": "Male"
  },
  "certainty": 0.8

1. Is that forbidden (where does it say that?)
2. Or does it duplicate annotations like:

<<ex:bob :age 42>> :certainty 0.8.
<<ex:bob :sex "Male">> :certainty 0.8.

As you can attach lots of annotations, such duplication would seem ill-advised.

The rationale is the following (adapted from this message):

{
    "@context": [
      "https://schema.org/",
      {
        "ex": "http://example.com/",
        "ex:captain": { "@type": "@id" }
      }
    ],
    "@type": "Event",
    "ex:realizationOf": { "@id": {
        "@id": "ex:bowls_club",
        "ex:captain": "ex:bob"
    }},
    "startDate": "01-01-2019",
    "endDate": "31-12-2019"
}

Since ex:realizationOf is always expecting a triple, we might want to be able to spare the intermediate "@id".

Of course, declaring ex:realizationOf as "@type": "@id" does not work, because this only affect values of the property that are strings. "@type": "@triple" seems like a natural way to do this, but it has the disadvantage or introducing a new keyword...

Hi,
the spec draft states:

After step 13.4.14 add the following step:

1. If expanded property is @annotation:
   1. Continue with the next key from element if the rdfstar flag is not set.
   2. Set expanded value to the result of using this algorithm recursively passing active context, @annotation for active property, value for element, base URL, and the frameExpansion and ordered flags.

Shouldn't step 1.II require to assure that the result of expansion is an array? If I don't do that then the result is:

"@annotation" : {...}

but tests expect:

"@annotation" : [
   { ... }
]

There has been some discussions about how RDF-star can help with ordered multiple values in RDF. Example:

<#book> dct:creator <#alice> {| ex:order 1 |};
        dct:creator <#bob> {| ex:order 2 |}.

I would like a new kind of container in JSON-LD that would translate to the triples above. The compact form could look like that:

{ "@context": {
    "creator": {
        "@id": "http://purl.org/dc/terms/creator",
        "@type": "@id",
        "@container": [ "@ordered"]
     }
  },
  "@id": "#book", "creator": [ "#alice", "#bob" ]
}

and the expanded form could look like

{
    "#alice": {
        "http://purl.org/dc/terms/creator": {
            "@ordered": [
                { "@id": "#alice" },
                { "@id": "#bob" },
            ]
        }
    }
}

The existing algorithm only uses embedded nodes.

Maybe that should be https://github.com/json-ld/json-ld-star/ ?

Background and motivation

It would be useful to be able to group quoted triples about the same resource within a node object, to eliminate redundancy and make it simple to access, view and manage all data about that resource, whether it is asserted or quoted.

Use cases that would benefit from this include:

• Managing suggested triples for a resource (such as automatic classification of bibliographic resources).
• A combined "blame" view of the history of statements about a resource, where each statement is related to versions of source documents.

Example

A simplified example combining the use cases would be:

• There are two versions of a record describing the resource <7d5d0d651caa>, with version 2 being the current.
• The resource was typed as just a :Work in version 1, then in version 2 more precisely as a :Text.
• In version 2 there is also a suggestion by <classifyer> that the resource has the subject <semantics>.

Here are the two versions expressed as named graphs using TriG-star:

prefix : <http://example.org/ns#>
base <http://example.com/>

graph <data?version=1> {
  <7d5d0d651caa> a :Work .
}

graph <data?version=2> {
  <7d5d0d651caa> a :Text .
  << <7d5d0d651caa> :subject <semantics> >> :suggestedBy <classifyer> .
}

Here is the "blame" view of that, combining asserted and quoted facts (utilizing annotation to avoid repeating asserted arcs with additional attached facts):

prefix : <http://example.org/ns#>
base <http://example.com/>

<7d5d0d651caa> a :Text {| :statedIn <data?version=2> |} .
<< <7d5d0d651caa> a :Work >> :statedIn <data?version=1> ; :retractedIn <data?version=2> .
<< <7d5d0d651caa> :subject <semantics> >> :suggestedBy <classifyer> {| :statedIn <data?version=2> |} .

Here is that same "blame" view expressed using JSON-LD-star:

[
  {
    "@id": "7d5d0d651caa",
    "@type": "Text"
  },
  {
    "@id": {"@id": "7d5d0d651caa", "@type": "Text"},
    "statedIn": {"@id": "data?version=2"}
  },
  {
    "@id": {"@id": "7d5d0d651caa", "@type": "Work"},
    "statedIn": {"@id": "data?version=1"},
    "retractedIn": {"@id": "data?version=2"}
  },
  {
    "@id": {"@id": "7d5d0d651caa", "subject": {"@id": "semantics"}},
    "suggestedBy": {"@id": "classifyer", "@annotation": {"statedIn": {"@id": "data?version=2"}}}
  }
]

(Note that while the TriG-star annotation form helps to eliminate one assertion/quotation repetition (<7d5d0d651caa> a :Text . << <7d5d0d651caa> a :Text >> :statedIn <data?version=2> .), that is not possible to succinctly express in JSON-LD-star. So in order to keep predictable compact types, the quotation of an assigned type here repeats the triple, outside of the subject node.)

While repetitive, the above is still more concise (and intended to become semantically different in RDF 1.2) than using plain old reification (here in Turtle):

prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
prefix : <http://example.org/ns#>
base <http://example.com/>

<7d5d0d651caa> a :Text .
[] rdf:subject <7d5d0d651caa> ;
  rdf:predicate rdf:type ;
  rdf:object :Text ;
  :statedIn <data?version=2> .

[] rdf:subject <7d5d0d651caa> ;
  rdf:predicate rdf:type ;
  rdf:object :Work ;
  :statedIn <data?version=1> ;
  :retractedIn <data?version=2> .

_:stmt3 rdf:subject <7d5d0d651caa> ;
  rdf:predicate :subject ;
  rdf:object <semantics> ;
  :suggestedBy <classifyer> .

_:stmt4 rdf:subject _:stmt3 ;
  rdf:predicate :suggestedBy ;
  rdf:object <classifyer> .

_:stmt4 :statedIn <data?version=2> .

However, all examples above, from named graphs via quoted triples to old reification, requires a lot of repetition of the same subject throughout. For NQuads that is to be expected, but the purpose of TriG-star or at least JSON-LD is to provide ergonomic representations, reducing redundancy as much as possible. (Without turning things obscure of course; albeit both of these qualities are subjective and require a wide range of experience and agreement.)

Interestingly, by using JSON-LD with a custom context, the old reification form can actually result in a fairy compact view:

{
  "@context": {
    "rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#",
    "stmt": {"@reverse": "rdf:subject", "@container": "@index", "@index": "p"},
    "s": {"@id": "rdf:subject", "@type": "@id"},
    "p": {"@id": "rdf:predicate", "@type": "@vocab"},
    "t": {"@id": "rdf:object", "@type": "@vocab"},
    "o": {"@id": "rdf:object"},
    "@vocab": "http://example.org/ns#",
    "@base": "http://example.com/"
  },
  "@graph": [
    {
      "@id": "7d5d0d651caa",
      "@type": "Text",
      "stmt": {
        "rdf:type": [
          {"t": "Text", "statedIn": {"@id": "data?version=2"}},
          {"t": "Work", "statedIn": {"@id": "data?version=1"}, "retractedIn": {"@id": "data?version=2"} }
        ],
        "subject": {
          "o": {"@id": "semantics"},
          "suggestedBy": {"@id": "classifyer"},
          "stmt": {
            "suggestedBy": {"o": {"@id": "classifyer"}, "statedIn": {"@id": "data?version=2"}}
          }
        }
      }
    }
  ]
}

(Note: While most JSON-LD processors support this form, there is an errata on the algorithm for this feature: w3c/json-ld-api#565.)

It is still a bit unwieldy (with the odd predicate and object keys), and does not utilize any of the semantics RDF-star will hopefully define (e.g. regarding uniqueness of triples and their relation to named graphs).

Grouping with @included

Note that grouping is already possible in JSON-LD, albeit with the remaining problem of repeating the same @id value:

{
  "@context": {
    "@vocab": "http://example.org/ns#",
    "@base": "http://example.com/"
  },
  "@graph": [

    {
      "@id": "7d5d0d651caa",
      "@type": "Text",
      "@included": [
        {
          "@id": {"@id": "7d5d0d651caa", "@type": "Text"},
          "statedIn": {"@id": "data?version=2"}
        },
        {
          "@id": {"@id": "7d5d0d651caa", "@type": "Work"},
          "statedIn": {"@id": "data?version=1"},
          "retractedIn": {"@id": "data?version=2"}
        },
        {
          "@id": {"@id": "7d5d0d651caa", "subject": {"@id": "semantics"}},
          "suggestedBy": {"@id": "classifyer", "@annotation": {"statedIn": {"@id": "data?version=2"}}}
        }
      ]
    }

  ]
}

While this appears somewhat better than the first blame view, it still requires something or someone to ensure that the subject is kept the same within this group, and would still require processing (e.g. indexing or restructuring) to be concisely managed.

Also, this is a simplified example which doesn't scale well. In many real world examples, there can be lots of quoted triples sharing the same subject (e.g. in aggregated bibliographic records from the library domain, or in Wikidata descriptions where there are sometimes disputed statements which could be beneficial to be kept as unasserted quotes).

Proposal: a @quoted keyword

In this proposal the objects of arcs are quoted using a new @quoted keyword. This means that the entire arc is quoted. Data within the quoted object become assertions about that quoted triple:

{
  "@context": {
    "@vocab": "http://example.org/ns#",
    "@base": "http://example.com/"
  },
  "@graph": [

    {
      "@id": "7d5d0d651caa",
      "@type": [
        "Text",
        {
          "@quoted": "Text",
          "statedIn": {"@id": "data?version=2"}
        },
        {
          "@quoted": "Work",
          "statedIn": {"@id": "data?version=1"},
          "retractedIn": {"@id": "data?version=2"}
        }
      ],
      "subject": {
        "@quoted": {"@id": "semantics"},
        "suggestedBy": {"@id": "classifyer", "@annotation": {"statedIn": {"@id": "data?version=2"}}}
      }
    }

  ]
}

This becomes a kind of complement to @annotation, and behaves very much like it, in that both affect the subject-predicate-object arc.

Of course, like @annotation, it could be considered a drawback in that values for keys that normally expect strings may become quoted objects. Again, see the @annotation on a @type issue for details. (We may want to similarly support @container: @quoted just like suggested in that issue to support partitioning predicates.)

The upshot of @quoted is that, reasonably, values of @quoted would behave as the value for the key itself, avoiding the @id vs. @vocab lexical space part of the problem in the aforementioned issue. It even seems possible to use @uoted instead of @annotation on type, as illustrated above, as long as you accept repeating the type value as quoted. (There is no way around that for simple string values in JSON, so this appears to be an acceptable trade-off for keeping predictable code paths, with the caveat of quoted objects being mixed in unless a partitioning container can be used.)

(Note: I did try to allow @quoted to also be used instead of @id-with-object-value as a way to represent quoted triples as objects (of statements). But due to the way subjects may be objects in JSON-LD, that would become ambiguous in conjunction with the above. It may be possible to support that by requiring the above to combine @quoted with @annotation, and only then let @quoted trigger the "quote the entire arc" meaning.)

(Also, this keyword may still be possible to use in the suggestion for allowing terms with quotes as values, instead of the there suggested @triple keyword though.)

A list object, which is the direct value of a node object, should be able to contain an @annotation. For example:

{
  "@id": "ex:subject",
  "ex:values": {
    "@list": [1, 2, 3],
    "@annotation": {
      "ex:asOf": {"ex:asOf": "yesterday"}
   }
}

would be the same as the following Turtle*:

@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .

<ex:subject> <ex:values> _:li .
_:li rdf:first 1; rdf_rest (2 3); <ex:asOf> "yesterday" .

The rationale is the following (adapted from this message):

{
    "@context": [
        "https://schema.org/",
        { "ex": "http://example.com/" }
    ],
    "@id": "ex:bob",
    "ex:captain": {
        "@id": "ex:bowls_club",
        "@annotation": {
            "ex:realization": {
                "@type": "Event",
                "startDate": "01-01-2021",
                "endDate": "31-12-2021"
            }
        }
    }
}

Since "ex:realization" is expected to be used exclusively as an annotation, one might want to write:

{
    "@context": [
        "https://schema.org/",
        { "ex": "http://example.com/",
          "realization": { "@annotation": "ex:realization" } }
    ],
    "@id": "ex:bob",
    "ex:captain": {
        "@id": "ex:bowls_club",
        "realization": {
            "@type": "Event",
            "startDate": "01-01-2021",
            "endDate": "31-12-2021"
        }
    }
}

This would be homogeneous to how @rev works in terms definition.

edited: the initial proposal (and title) was a mistake (and there was a bug in the 2nd example)

I cannot find a convenient way to express this:

@base: <http://example.org/abox/> .
@prefix : <http://example.org/tbox#> .

  :bob a :Person {| :accordingTo :alice |} .

as compact JSON-LD-star using the @annotation design along with @type. Am I missing something or is this a limitation of the current design?

If it is, and without resorting to context trickery, I could imagine a new special form like this might do the trick:

{
  "@context": {
    "@base": "http://example.org/abox/",
    "@vocab": "http://example.org/tbox#"
  },
  "@id": "bob",
  "@type": {
    "@type": "Person",
    "@annotation": {
      "accordingTo": {"@id": "alice"}
    }
  }
}

But with that, "@type": {"@type": "Person"} would have to be supported in general, which isn't so nice. I guess a variant could be "@type": {"@value": "Person"}. Alas, both forms might come off a bit like hacks for this purpose. Defining a new keyword, say @symbol, as a companion to @id but resolving against the context, might do it, but with all the drawbacks of yet another new keyword.

(It's possible to work around this limitation and get a "fairly compact" form, e.g. by not using @type and resorting to a plain rdf:type link using a regular non-@vocab-resolved @id value. (Or define a key in the context with a nested context where @base is set to the value of @vocab, albeit that'd resolve differently for e.g. hash-IRI:s as in the example.) But I'm looking for a way to leverage @type as is, resolving to @vocab, to keep the compact form as close to "regular" compact JSON-LD as possible.)

The group does not expect this document to become a W3C Recommendation.

Could these developments be merged into JSON-LD 1.2 or 2.0?

The term "embedded node" refers to "embedded triple", which is legacy terminology. It has been replaced in the CG report with "quoted triple".
I would rather rename it to "triple node", or maybe "quoted triple node", which is more explicit but a bit long.

NB: I don't think that "quoted node" would be very clear.