Re: From the Semantics TF: rdf:states

> On 5. Aug 2024, at 19:24, Franconi Enrico <franconi@inf.unibz.it> wrote:
> 
> Hi,
> on Friday we discussed about the possible extension of the baseline with a rdf:states property, which basically is like rdf:reifies but it assumes that the triple term holds in the graph as well.
> The exact syntax and semantics of the extension is defined in:
> https://github.com/w3c/rdf-star-wg/wiki/Extending-the-baseline-with-"asserted"-stuff

[Sorry for not mentioning this page in my updated proposal]

> together with some observations, which I paste below:
> 
> ° It has been suggested that this extension could be more suitable to extend RDFS and not RDF, since reasoning similar to rdfs:subClassOf is needed to complete the graph and to support the entailment regime.
> 
> ° It has been suggested that rdf:states rdfs:subPropertyOf rdf:reifies. should hold in RDFS.
> 
> ° It has been suggested that the mapping between RDF-star and LPGs should use rdf:states instead rdf:reifies; but this introduces the possibly incomprehensible behaviour that distinct edges with the same label (type) between the same node identifiers will correspond to a unique triple in the edge, e.g.,
> :e111 rdf:states <<( :john :worksFor :A )>>.
> :e222 rdf:states <<( :john :worksFor :A )>>.
> :e111 :sal 100K.
> :e222 :sal 200K.
> 
> will induce the unique triple in the graph:
> :john :worksFor :A.

I still don’t know what you mean by "induce". And by extension I don’t understand what you see as problematic in this example.

You said it doesn’t means that it entails, but then you provided an explanation using reification vocabulary. That didn’t help me understand either what you mean by "induce", because reification was the thing that I had asked you to explain first, and you explained it by introducing the term "induce". So we are going in circles here.


> ° It has been suggested that the annotation syntax in Turtle could be mapped into rdf:states instead of rdf:reifies.
> Advantages and disadvantages have been discussed, and it is not clear whether we really want this extension or not.
> —e.

.t

Received on Tuesday, 6 August 2024 08:10:08 UTC