- From: Richard Cyganiak <richard@cyganiak.de>
- Date: Wed, 25 Sep 2019 13:05:40 +0100
- To: Jerven Bolleman <jerven.bolleman@sib.swiss>
- Cc: public-rdf-star@w3.org
> On 25 Sep 2019, at 09:59, Jerven Bolleman <jerven.bolleman@sib.swiss> wrote:
>
> Considering the presence of incomplete and not-asserted reification triples are very rare in the wild RDF corpera. I think for commercial practicality most vendors will just go for the not supported operation.
(FWIW, TopQuadrant's products use RDF reification to represent change history, to represent “working copies” (basically, drafts), and to represent suggested edits. All of these reification triples are not-asserted in the graph containing them; some are asserted in a different graph.)
> Other case is to introduce for each incomplete reif quad a blank node containing triple.
>
> e.g.
> [] rdf:object uniprotkb:P05067
>
> leads to
> <[] [] uniprotkb:P05067> in the store.
I like that, and it's arguably licensed by what little semantics we have in the existing RDF specs. The triple
_:b0 rdf:object uniprotkb:P05067
implies
_:b0 a rdf:Statement
per RDFS Semantics, and that triple arguably implies
_:b0 rdf:subject _:b1 .
_:b0 rdf:predicate _b2 .
because every RDF statement has a subject and predicate. Taken together, those four triples are a reification quad that represents the nested triple in <<_:b1 _:b2 uniprotkb:P05067>>.
A remaining headache in the relationship between RDF* and RDF Reification is the fact that multiple independent reification quads can exist for the same triple. RDF* cannot represent that without introducing additional modelling vocabulary.
Richard
Received on Wednesday, 25 September 2019 12:06:06 UTC