Re: [External] : Re: RDF star and LPGs

Gregory Williams said in an earlier message [1]: " ...to get a good mapping, you’d have to enforce the use of reifiers on every triple, whether or not there are any annotations attached to the reifier." I agree, but, in the following, I would use the term "identifier" (or, id) instead of "reifier" to cover asserting as well.

I also agree with the theme of Thomas' arguments in his last several messages, including [2] , where he talks about the need for supporting both "stated" and "described" triples. In the examples below, I have used rdf:asserts instead of rdf12:states and rdf:reifies instead of rdf12:describes.

Since every edge in LPG is concrete (asserted) and each has a unique id, we could convert an edge in LPG to an RDF1.2 triple as follows:
Example 1:
=========
    LPG => (s) -[:p]-> (o), with edge-id e
    RDF1.2 => :e rdf:asserts <<( :s :p :o )>> .

In general, I'd posit that every RDF1.1 (asserted) triple and every edge in LPG can be modeled in RDF1.2 as an rdf:asserts triple with an auto-generated resource as its id. So, below I assume that there is a function "foo" that maps each (s,p,o) to a unique id (and it is a one-to-one correspondence between identifiers and triple-terms). As to how to make foo() invisible to the users, I am leaving out that aspect from here.

RDF1.1 supports asserted triples only. Converting them to LPG and RDF1.2 can be done as follows:
NOTE: The two forms :s :p :o . and foo(s,p,o) rdf:asserts <<( :s :p :o )>> . are equivalent in RDF1.2.
Example 2:
=========
    RDF1.1 => :s :p :o .
    LPG => (s) -[:p]-> (o) with edge id computed using value of foo(s,p,o).
    RDF1.2 => foo(s,p,o) rdf:asserts <<( :s :p :o )>> .

Constraint in RDF1.2: The same "id" and triple-term pair cannot be related by both rdf:asserts as well as rdf:reifies at the same time. So, the following combination is invalid.
Example 3: invalid combination
==========================
    foo(s,p,o) rdf:asserts <<( :s :p :o )>> .
    foo(s,p,o) rdf:reifies <<( :s :p :o )>> .

SPARQL results for a given query remains unchanged:
=========
- The following original SPARQL1.1 query pattern { ?s ?p ?o }  will still return the same results even when executed against the RDF1.2 data (by internally converting the pattern to foo(?s,?p,?o) rdf:asserts <<( ?s ?p ?o )>> ).
- A new SPARQL query pattern, { ?e rdf:asserts <<( ?s ?p ?o )>> }, will, for each solution, return the same values for ?s, ?p, and ?o as does the above query, but will return a value for ?e as well.

Roundtrip RDF1.1 -> RDF1.2 -> RDF1.1 works as follows:
Example 5:
=========
    RDF1.2 => foo(s,p,o) rdf:asserts <<( :s :p :o )>> .
    RDF1.1 => :s :p :o .

What if annotations got added in RDF1.2 version, as shown below? Can we convert such expanded expanded content to an equivalent representation in RDF1.1? Yes, but only with use of reification.
Example 6:
=========
  RDF1.2 =>
    foo(s,p,o) rdf:asserts <<( :s :p :o )>> .
    foo(s,p,o)  :prop :val .
  RDF1.1 =>
     :s :p :o .
     foo(s,p,o) a rdf:Statement; rdf:subject :s ; rdf:predicate :p ; rdf:object :o .
     foo(s,p,o) :prop :val .

Another interesting example of RDF1.1 to RDF1.2 conversion:
Example 7:
=========
  RDF1.1 =>
    :s :p :o .
    :r1 a rdf:Statement; rdf:subject :s ; rdf:predicate :p ; rdf:object :o .
    :r1 :prop :val .
    :r2 a rdf:Statement; rdf:subject :s ; rdf:predicate :p ; rdf:object :o .
    :r2 :prop2 :val2 .
  RDF1.2 =>
     foo(s,p,o) rdf:asserts <<( :s :p :o )>> .
     :r1 rdf:reifies <<( :s :p :o )>> .
     :r1 :prop :val .
     :r2 rdf:reifies <<( :s :p :o )>> .
     :r2 :prop2 :val2 .

Thanks,
Souri.

[1] https://lists.w3.org/Archives/Public/public-rdf-star-wg/2024Jul/0112.html (Gregory Williams, Wed, 24 Jul 2024 21:17:03 -0700)
[2] https://lists.w3.org/Archives/Public/public-rdf-star-wg/2024Jul/0109.html (Thomas, Tue, 23 Jul 2024 14:24:45 +0200)

________________________________
From: Andy Seaborne <andy@apache.org>
Sent: Thursday, July 25, 2024 10:52 AM
To: public-rdf-star-wg@w3.org <public-rdf-star-wg@w3.org>
Subject: [External] : Re: RDF star and LPGs




On 25/07/2024 05:17, Gregory Williams wrote:

The more I look at this, the more I think that to get a good mapping, you’d have to enforce the use of reifiers on every triple, whether or not there are any annotations attached to the reifier. Triples without corresponding reifiers would simply be invisible in LPG data. And reifiers without corresponding asserted triples would have to be invisible as well.

thanks,
.greg


Let's refine exactly what we're trying for.

I don't think the WG objective is to define a systematic or universal mapping from LPG to RDF. For any given data, a mapping may take into account the LPG context, such as written documentation about the data, to give a mapping that captures the usage and intent of the LPG data. There may even be several mappings if the mapping enriches the data.

We should show that mappings from a specific LPG data domain to publishable RDF are possible.

Secondly, automatic round-tripping is not a requirement. A reverse mapping from RDF to LPG can be based on an understanding of the forward mapping, taking into account unreified triples that are generated in the forward direction. It would be nice if there is a unique/canonical/preferred reverse mapping; it's not a requirement though.

A complete solution to LPG<->RDF is a working group in its own right.

    Andy