Re: RDF* to RDF mapping (Re: First version of a test suite for RDF*)

On 24/11/2020 12:40, Peter F. Patel-Schneider wrote:
> Consider this as a counter-example to your claim in [1] that
>
> 3. Otherwise, IMO, we need to somehow extend RDF semantics.
Yes, I understood this was your intent :)
> But, yes, the two approaches do share the idea of encoding subjects,
> predicates, and objects to achieve referential opacity for IRIs and
> literals.   My approach handles blank nodes in embedded triples, which is
> where the bulk of the difficulty lies.

Indeed.

Now, as I mentioned before, the reason why I came to the conclusion that 
a semantic extension was required is that I wanted to enforce /in the 
semantic/ the consistency between the properties pointing to 
referentially opaque terms, and the corresponding properties pointing to 
their denotation.

I think that your approach can do without this semantic extension 
because you prevent anyone (but your -* mapping) from using the rdf*: 
namespace. So those constraints are enforce structurally by the -* 
mapping, rather than by the semantics. Would you agree?

> To make the approach work for all RDF* graphs care has to be taken that the
> encoding terms do not occur in the RDF* graph and cause problems.  As I encode
> literals as string literals and permit extended graphs where literals can be
> subjects (and predicates) I had to map strings away from my encoding strings.
> The encoding could be changed to use a new datatype as you do and that would
> obviate the need to map string literals away.  But there would still need to
> be a mapping of IRIs.

I understand why you want to map IRIs. I think however that this is not 
required for literals: what harm could happen if I wrote a triple 
involving "Xhttp://example.com/"? Since I can't use the rdf*: predicate, 
I don't think this would cause any problem... But that's a detail.

As I understand, this mapping would have to be applied to all triples 
entering the system, regardless of the format. Not only would Turtle* 
files need to be transformed, /but also all vanilla RDF files/ (Turtle, 
RDF/XML, N-Triples...), just in case they would use the rdf*: namespace, 
to prevent them from breaking the internal structure of embedded triples.

It feels like like a big price to pay to keep the same semantics. And I 
feel that implementers would rather add a special treatment for RDF* 
embedded triples, than transform any triple that enters their system, 
just to be able to represent embedded triples internally as plain RDF. 
And if I am right, I would rather extend the semantics accordingly.

   pa

> There is a bug in my proposal having to do with malformed literals.  To fix
> it, add the encoding of malformed literals as the subject, predicate, or
> object of the reified embedded triple, as needed.
>
>
> peter
>
>
>
>
> On 11/24/20 3:40 AM, Pierre-Antoine Champin wrote:
>> Peter,
>>
>> thanks for this proposal; this is in fact quite similar to what I had in
>> mind in my proposal in issue 37 [1].
>>
>> Two remarks:
>>
>> 1) Is it really necessary that N transforms literals? I find this quite
>> intrusive that a simple graph such as:
>>
>>      :xavier :name "Xavier".
>>
>> would be encoded as another graph... (of course, you can use a less probable
>> marker than "X", but still...).
>>
>> Since the only rdf*:subject*/rdf*:predicate/rdf*:object triples in the
>> encoded graph are those generated by the mapping, I don't think values need
>> to be "protected" by N.
>>
>> 2) In my idea, RDF semantics was extended to enforce some dependency between
>> subject and subject*, between predicate and predicate*, and between object
>> and object*, and to ensure that subject, predicate and object were
>> functional (a statement describes only one "fact"). In other words, the
>> following things would have been *inconsistent* (under RDF* entailment
>> recognizing xsd:integer):
>>
>> # G1
>>
>> _:stmt rdf*:object* M("a"^^xsd:integer); rdf*:object 42.
>>
>> # G2
>>
>> _:stmt rdf*:object* M("42"^^xsd:integer); rdf*:object 43.
>>
>> Disclaimer: those semantic constraints make the malformed-literal-bnode test
>> [2] problematic, I don't have a solution for that, and I am not even sure
>> that this test should be kept (but I put it here for discussion). The
>> dedicated semantics in my pull-request [3], however, passes this test, and
>> the others (I think).
>>
>>
>> [1] https://github.com/w3c/rdf-star/issues/37#issue-746823745
>> [2]
>> https://w3c.github.io/rdf-star/tests/semantics/manifest.html#malformed-literal-bnode
>> [3] https://github.com/w3c/rdf-star/pull/19
>>
>>
>> On 24/11/2020 00:59, Peter F. Patel-Schneider wrote:
>>> Here is a mapping from generalized RDF* to generalized RDF that I believe
>>> satisfies all the test cases:
>>>
>>>
>>> Short and a bit sloppy version:
>>>
>>> Define M on RDF terms as follows:
>>>     M(I) is the string of I for I an IRI
>>>     M(L) is the long lexical form of L for L an RDF literal
>>>
>>> Let L be an injective mapping from RDF triples to "fresh" blank nodes.
>>>
>>> Define the mapping -* from a generalized RDF* graph G* to a generalized RDF
>>> graph G as follows:
>>>     Pick some embedded triple < s p o > such that none of s, p, and o are
>>> embedded triples, replace all occurrences of it by L(< s p o >), and add the
>>> triples
>>>       < L(< s p o >) rdf:type rdf:Statement >
>>>       < L(< s p o >) rdf:subject s > if s is not a malformed literal
>>>       < L(< s p o >) rdf:subject* M(s) > if s is not a blank node
>>>       < L(< s p o >) rdf:predicate p > if p is not a malformed literal
>>>       < L(< s p o >) rdf:predicate* M(p) > if p is not a blank node
>>>       < L(< s p o >) rdf:object o > if o is not a malformed literal
>>>       < L(< s p o >) rdf:object* M(o) >  if o is not a blank node
>>>     Finish when there are no embedded triples left.
>>>
>>>
>>>
>>>
>>>
>>> Longer and more careful version:
>>>
>>> Let rdf* be an IRI namespace.
>>>
>>> Let M be an injective mapping from IRIs and RDF literals to strings starting
>>> with "X"
>>>
>>> Let L be an injective mapping from RDF triples to blank nodes whose range
>>> excludes an infinite number of blank nodes.
>>>
>>> Let N be an injective mapping from IRIs to IRIs, strings to strings, and blank
>>> nodes to blank nodes that does not include any IRIs in the rdf* namespace or
>>> strings that start with "X" or blank nodes in the range of L in its range.
>>> (This is just used to ensure that the encoding of IRIs, strings, and blank
>>> nodes do not clash with RDF terms in the graphs.)
>>>
>>> Define the mapping -* from a generalized RDF* graph G* to a generalized RDF
>>> graph G as follows:
>>>     First replace each RDF term by its mapping under N.
>>>     Pick some embedded triple < s p o > such that none of s, p, and o are
>>> embedded triples, replace all occurrences of it by L(< s p o >), and add the
>>> triples
>>>       < L(< s p o >) rdf*:type rdf*:Statement >
>>>       < L(< s p o >) rdf*:subject s > if s is not a malformed literal
>>>       < L(< s p o >) rdf*:subject* M(s) > if s is not a blank node
>>>       < L(< s p o >) rdf*:predicate p > if p is not a malformed literal
>>>       < L(< s p o >) rdf*:predicate* M(p) > if p is not a blank node
>>>       < L(< s p o >) rdf*:object o > if o is not a malformed literal
>>>       < L(< s p o >) rdf*:object* M(o) >  if o is not a blank node
>>>     Finish when there are no embedded triples left.
>>>
>>>
>>>
>>>
>>>
>>> peter
>>>
>>>
>>>
>>>
>>>
>>> On 11/23/20 6:30 AM, Pierre-Antoine Champin wrote:
>>>> Hi all,
>>>>
>>>> as per my action assigned on our last call [1], I pushed a first version of
>>>> a test-suite. The first goal is to provide a set of concrete examples of how
>>>> RDF* implementations are expected to behave. An HTML rendering of that
>>>> test-suite is available here:
>>>>
>>>> https://w3c.github.io/rdf-star/tests/semantics/manifest.html
>>>>
>>>> so that everyone can review, reference, and comment each of the test cases.
>>>>
>>>> If "entail" sounds esoteric to you, think of the 2nd graph in each test case
>>>> as a SPARQL* ASK query, which is expected to return TRUE (or FALSE, in the
>>>> case of "not entail").
>>>>
>>>> Coming next: a similar test suite for SPARQL*.
>>>>
>>>>     best
>>>>
>>>> [1] https://github.com/w3c/rdf-star/issues/40
>>>> <https://github.com/w3c/rdf-star/issues/40>
>>>>