Re: basing RDF-star on RDF reification

On 13/12/2022 16:45, Peter F. Patel-Schneider wrote:
> As far as the Community Group proposal for RDF-star and SPARQL-star 
> goes, there is no need to ever use the mapping unless you are 
> determining RDF-star entailment.   Even then, the mapping just 
> specifies what the results are so any method of getting to these 
> results is fine.  SPARQL-star uses a different mechanism entirely so 
> the mapping is not needed in SPARQL.
>
> As far as my proposal goes, when determining entailment all that 
> counts is the final result so there is again no need to use the 
> mapping for determining entailment.  Of course, it is possible to use 
> the mapping, as in my proposal embedded triples are purely syntactic 
> sugar.
In other words, you advocate for Turtle-star and (the surface syntax of) 
SPARQL-star, but leaving RDF and the semantics of SPARQL untouched. Right?
>   This allows current software to correctly process embedded triples 
> without any change to the software.

Well, they still need a turtle-star parser. But granted, that's a minor 
change compared to implementing a new abstract syntax and semantics.

You state that "there is no need to use the mapping for determining 
entailment". I have to comment on this, but will do so in a separate 
email -- this one is already very long.

>
> In my proposal there is no need to extend SPARQL to handle embedded 
> triples - all that is needed is to use the mapping to expand embedded 
> triples and then use SPARQL as it currently exists.  (It could be 
> useful to invert the mapping on the results of CONSTRUCT queries.)  Of 
> course there is no need to implement embedded triples in SPARQL this 
> way - any way that comes up with the same results is allowable - so in 
> the end there is no need to use the mapping in my proposal either.
>
>
> The Community Group proposal has a particular form of referential 
> transparency/opacity - blank nodes are transparent and everything else 
> is opaque (even "01"^^xsd:int is different from "1"^^xsd:int).  There 
> is no way change this.

There is no way to change this for quoted triples, but someone wishing 
for full transparency could still use standard reification, as they 
would in your proposal. About which...

>
> In my proposal embedded triples have the same referential 
> transparency/opacity but other stances are possible by constructing 
> the appropriate reification and associated triples.

... I don't understand this claim. If << a b c >> is syntactic sugar for

   _:x1 rdf:subject a .
   _:x1 rdf:stated-subject "a"^^xsd:string .
    _:x1 rdf:predicate b .
   _:x1 rdf:stated-predicate "b"^^xsd:string .
    _:x1 rdf:object c .
    _:x1 rdf:stated-object "c"^^xsd:string .

then it is semantically opaque, and there is no way to change this 
either. If you want a version without the rdf-stated-* predicates, you 
can't use the << ... >> syntactic sugar anymore, you have to spell it 
out explicitly -- just like you could in the CG's proposal.

Or are you suggesting that << ... >> is interpreted differently in 
different contexts ?


On 15/12/2022 18:00, Peter F. Patel-Schneider wrote:
> As far as I can tell, neither RDF standard reification nor RDF-star 
> embedded triples are tied to either types or occurrences and taking 
> about types vs occurrences is not helpful.
>
>
> What you do get in RDF-star is a kind of uniqueness, namely that the 
> basic idea in RDF-star is that there is only one embedded triple with 
> the syntactically same subject, predicate, and object.   But this is 
> not really supported in the RDF-star semantics,
I have to disagree with you here, see below.
> which is based on a mapping to regular RDF.  This mapping does not 
> produce uniqueness or even identity of embedded triples.  A semantics 
> that supports the uniqueness of embedded triples would have to extend 
> the RDF semantics in a significant manner.

Sure, since the RDF 1.1 semantics has no way to force uniqueness, you 
could say that the mapping "does not produce uniqueness". Namely, the 
following RDF 1.1 graph :

   _:x unstar:subject :s, unstar:predicate :p, unstar:object :o, ....
   _:y unstar:subject :s, unstar:predicate :p, unstar:object :o, ...

of course, nothing in the RDF 1.1 semantics forces _:x and _:y to denote 
the same thing.

However, there is absolutely no way for the unstar mapping to produce 
such a graph from any RDF-star graph as defined by the CG report. So I 
argue that the RDF-star semantics /does /support the unicity of quoted 
triples. It does so without extending the RDF 1.1 semantics, because it 
is based on that semantics + the unstar mapping.

Of course, this means that any implementation storing RDF-star graphs in 
the unstared version would have to be careful to not produce invalid 
RDF-star graphs when combining them. This is also explained the the CG 
report [2].

   pa

[1] https://www.w3.org/2021/12/rdf-star.html#rdf-star-semantics

[2] https://www.w3.org/2021/12/rdf-star.html#combining-rdf-star-graphs