json-ld / json-ld-star Goto Github PK
View Code? Open in Web Editor NEWCG Note on JSON-LD*
Home Page: https://json-ld.github.io/json-ld-star
License: Other
CG Note on JSON-LD*
Home Page: https://json-ld.github.io/json-ld-star
License: Other
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)
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.
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 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.
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.
Maybe that should be https://github.com/json-ld/json-ld-star/ ?
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:
A simplified example combining the use cases would be:
<7d5d0d651caa>
, with version 2 being the current.:Work
in version 1, then in version 2 more precisely as a :Text
.<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).
@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).
@quoted
keywordIn 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.)
The existing algorithm only uses embedded nodes.
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.)
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
<<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.
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/",
"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:
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" : [
{ ... }
]
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?
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 triplesThe direction for RDF 1.2 now abandons quoted triples for triple terms which are intended to be used indirectly through a reifier that relates an identifier to the triple term through rdf:reifies
. This likely affects how we might represent this in JSON-LD. Rather than using a recursive value on @id
, we may instead do something using additional keywords:
The bob example might look more like the following:
{
"@context": {
"@base": "http://example.org/",
"@vocab": "http://example.org/",
"rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#",
},
"rdf:reifies": {
"@triple": {
"@id": "bob",
"age": 42
}
},
"certainty": 0.8
}
This could be reduced by also introducing a @reifies
keyword (at the expense of adding yet another keyword) as follows:
{
"@context": {
"@base": "http://example.org/",
"@vocab": "http://example.org/",
"rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#",
},
"@reifies": {
"@id": "bob",
"age": 42
},
"certainty": 0.8
}
The annotation syntax could also allow for an @id
entry for assigning the reifier identifier:
{
"@context": {
"@base": "http://example.org/",
"@vocab": "http://example.org/"
},
"@id": "bob",
"age": {
"@value": 42,
"@annotation": {
"@id": "_:anno",
"certainty": 0.8
}
}
}
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.