Open gkellogg opened 7 months ago
Re. the representation of triple terms, I think I prefer the introduction of the @triple
keyword over the overriding of the @id
keyword. I believe that there are strong expectations that the value of @id
is a string. Note also that ignoring the @triple
keyword and its value would amount to replace triple-terms with blank nodes, which is a good fallback, IMO.
Exposing the rdf:reifies
predicate and its triple-term value in JSON-LD feels against the trend to "hide" them in Turtle, and to encourage well-formed uses of triple terms. So I lean towards having a separate @reifies
keyword, even if the fact that it exposes the word "reifies" (contrarily to the syntactic sugar in Turtle) is not entirely satisfactory, IMO...
+1 to allow @id
in annotations to convey the reifier, that seems natural enough
- Re. the representation of triple terms, I think I prefer the introduction of the
@triple
keyword over the overriding of the@id
keyword. I believe that there are strong expectations that the value of@id
is a string. Note also that ignoring the@triple
keyword and its value would amount to replace triple-terms with blank nodes, which is a good fallback, IMO.
I definitely agree on not overriding @id
(due to those probable strong expectations for it being a string).
- Exposing the
rdf:reifies
predicate and its triple-term value in JSON-LD feels against the trend to "hide" them in Turtle, and to encourage well-formed uses of triple terms. So I lean towards having a separate@reifies
keyword, even if the fact that it exposes the word "reifies" (contrarily to the syntactic sugar in Turtle) is not entirely satisfactory, IMO...
I also agree on avoiding exposing rdf:reifies
(assuming we can stay on track with the well-formed baseline, and have that as the basis for JSON-LD).
I also lean towards a @reifies
keyword (it could be named differently; though I am personally comfortable with "reifies", if we stay with that nomenclature). More on that in a follow-up comment.
- +1 to allow
@id
in annotations to convey the reifier, that seems natural enough
Yes, definitely agree on that too; it comes naturally.
Interestingly, @reifies
might work for all of these:
<< <x> :relation <y> ~ <ref-1> >> :p :o .
<ref-2> rdf:reifies <<( <x> :relation <y> )>> .
<z> :says << <x> :relation <y> ~ <ref-3> >> .
Which in JSON-LD could be this:
[
{
"@id": "ref-1",
"@reifies": {
"@id": "x",
"relation": {"@id": "y"}
},
"p": {"@id": "o"}
},
{
"@id": "ref-2",
"@reifies": {
"@id": "x",
"relation": {"@id": "y"}
}
},
{
"@id": "z",
"says": {
"@id": "ref-3",
"@reifies": {
"@id": "x",
"relation": {"@id": "y"}
}
}
}
]
One upshot is that, IMHO, JSON-LD isn't as "triple-oriented" as Turtle; and the above reifications are more like a "neutral" singleton objects if you will (or even "quoted" data, meant without any opacity connotation).
Note though that this relies on all data being within the well-formed constraints for triple terms, i.e. only <<( ... )>>
as objects of rdf:reifies
. I think that is a good thing for JSON-LD, but it needs to be kept in mind.
I even think it can be beneficial, and simple enough, to allow @reifies
to contain multiple "triples". For example, this:
{
"@id": "ref-4",
"@reifies": {
"@id": "x",
"firstName": "X",
"lastName": "XY"
},
"p": {"@id": "o"}
}
Would be, in Turtle:
<< <x> :firstName "X" ~ <ref-4> >> .
<< <x> :lastName "XY" ~ <ref-4> >> .
<ref-4> :p :o .
The 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:
This could be reduced by also introducing a
@reifies
keyword (at the expense of adding yet another keyword) as follows:The annotation syntax could also allow for an
@id
entry for assigning the reifier identifier: