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

Consider this as a counter-example to your claim in [1] that

3. Otherwise, IMO, we need to somehow extend RDF semantics.

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.


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.


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>
>>>

Received on Tuesday, 24 November 2020 11:40:59 UTC