Re: New PR: yet another refactoring of the semantics

On 29/04/2021 15:53, Peter Patel-Schneider wrote:
> Well there is a decided difference in philosophy.  My proposal was
> designed with the idea of having RDF* embedded triples being just a
> shorthand for RDF reification, both syntactically and semantically.

Sorry, I should have been more precise. I was referring to the 2nd part 
of youer email the "Longer and more careful version" (which, as I see 
it, departs slightly from standard reification)

> This drives the only significant differences in the proposals.
> 1/ Using the unstar: vocabulary.
> 2/ Meddling with any use of the unstar: vocabulary in the RDF* graph.
> (By the way, it would be useful to provide the rationale for this
> meddling.)

The meddling is similar to the N mapping proposed in your email. 
Therefore I'll copy your own argument:

   This is just used to ensure that the encoding of IRIs, strings, and
   blank nodes do not clash with RDF terms in the graphs.

(although in that case, only IRIs in the unstar: namespace risk clashing).

> The philosophy in the PR then needs to show the semantic properties of
> the proposal and how SPARQL works on the proposal whereas in my
> proposal there is no need to show any semantic correspondences.

Absolutely, ultimately we need to prove that formally.

However, the situation with PR 162 is not worse than the current 
solution, were we *know for sure* that the SPARQL-star semantics is not 
aligned with the MT semantics.


> The proposal uses all-new local vocabulary for encoding embedded
> triples.  I don't see any reason to not use unstar:subject, etc.

do you mean rdf:subject, etc?

No particular reason really, except that defining the "meddling" is 
easier when all IRIs are in the same namespace.

>  I
> also don't see any reason to use abbreviations, e.g., sString instead
> of subjectLexical

No particular reason either. We can definitely rename them to something 
more explicit.

> There might be a bug in the proposal.  It appears that the IRI x and
> the string <x> are both mapped by L to "<x>"^^xsd:string.  I believe
> that this has consequences.

Not exactly. The string "<x>" is actually mapped to
   "\"<x>\""^^xsd:string

best

   pa

> 
> peter
> 
> 
> 
> 
> 
> On Wed, 2021-04-28 at 22:44 +0200, Pierre-Antoine Champin wrote:
>> Dear all,
>>
>> recently I was increasingly bothered with some aspects of the RDF-
>> star
>> semantics:
>>
>> * the use of hidden IRIs is clearly not ideal, all the more that
>> "they
>> can not hide from SPARQL"
>> (https://github.com/w3c/rdf-star/issues/101)
>>
>> * the SPARQL-star execution semantics was not aligned with the MT
>> semantics
>>
>> This PR is an attempt to solve these two problems:
>>
>>       https://github.com/w3c/rdf-star/pull/162
>>
>> which I propose we discuss during our next call.
>>
>> The main change with the previous version, apart from not using
>> hidden
>> IRIs, is that unstar(G) is no longer equivalent to G (but they are
>> equisatisfiable).
>>
>> Working on this PR, I realize that I was actually coming back (or
>> very
>> close) to a solution proposed by Peter Patel-Schneider quite some
>> time ago
>>
>> https://lists.w3.org/Archives/Public/public-rdf-star/2020Nov/0044.html
>>
>> Peter, I guess I owe you an apology for not seeing the value in this
>> proposal earlier!...
>>
>>     best
>>
>>
>>
> 
> 
>