Re: RDF star and LPGs

>> On Jul 22, 2024, at 2:33 AM, Franconi Enrico <franconi@inf.unibz.it> wrote:
>> 
>> Gregory Williams,
>> can you please tell us whether you are happy with the response?
>> I have updated the RDF star and LPGs <https://github.com/w3c/rdf-star-wg/wiki/RDF-star-and-LPGs> document, to reflect a discussion we had on Friday, namely that the encoding could easily be extended to include the triples I mention in my message below.

Hi Enrico. I don’t think the responses have made me any less concerned. Let me respond to several of the responses below, and show some examples of trying to work through the mapping.

>> :e1 and :e2 ARE the transactions, so, the transactions are in the graph.
>> But if you prefer, you are free to enrich the mapping by adding any or all of the following:
>> 
>> :e1 a :transaction .
>> :e2 a :transaction .
>> 
>> :e1 :sourceOfTransaction :a1 .
>> :e1 :targetOfTransaction :a2.
>> :e2 :sourceOfTransaction :a2 .
>> :e2 :targetOfTransaction :a3.
>> 
>> :a1 :TRANSACTION :a2 .
>> :a2 :TRANSACTION :a3 .

:e1 and :e2 may be transactions, but that isn’t the same as asserting the triple the last two :TRANSACTION triples above. It’s not just a matter of whether I **prefer** to assert them. Asserting them fundamentally changes what is true in the graph. As Thomas said in his response:

> That definitely surprises me. :e1 and :e2 describes transactions, but nowhere is it said that those transactions actually happened.




>>> I think this suggests that you'd end up with an empty graph if you tried to map RDF without any reifiers back to LPG (or at least a graph with no edges).
>> 
>> 
>> I don’t suggest even remotely this. Indeed, you could encode a LPG directly in RDF-1.1 without using reifiers at all, if the LPG does not have any edge label. As a best practice, though, I would IMHO suggest to always involve reifiers when mapping a LPG in RDF-star, otherwise you may end up to have an inhomogeneous way to represent transactions, for example with the triple:
>> :a1 :hasTransactionOn "2002-09-24Z"^^xsd:date .

When you say " if the LPG does not have any edge label,” is that just a typo that meant an edge without any edge *properties*?



## Example 1

I’d like to focus on this part, in particular: "you could encode a LPG directly in RDF-1.1 without using reifiers.” Let’s simplify the example down to just one edge with no properties:

CREATE (a1)-[:TRANSACTION]->(a2)

Then map that to:

:a1 :TRANSACTION :a2 .

I think that’s what you mean by encoding it “directly in RDF-1.1 without using reifiers at all.” You also said:

>> the mapping exemplified in the document is perfectly invertible

So if we try to map this triple back to LPG, I think the implication is that we’d expect to get back to:

CREATE (a1)-[:TRANSACTION]->(a2)


## Example 2

Now let’s do a single reifier using a subset of the example from the document:

CREATE (a1)-[:TRANSACTION {amount: 1000, currency: "gbp", date: "2002-09-24Z"}]->(a2)

<—>

<< :e1 | :a1 :TRANSACTION :a2 >>
  :amount 1000 ;
  :currency "gbp" ;
  :date "2002-09-24Z"^^xsd:date .

The suggestion is that this is invertible, too. But you’ve claimed that I can "enrich the mapping by adding” the transaction triple:

:a1 :TRANSACTION :a2 .
<< :e1 | :a1 :TRANSACTION :a2 >>
  :amount 1000 ;
  :currency "gbp" ;
  :date "2002-09-24Z"^^xsd:date .

This happens to be the union of the RDF triples from the two examples above. So if I try to map this back to LPG, how am I to know whether this is two edges (one with no properties, the other a lone reifier without a corresponding :TRANSACTION triple), or simply a single edge with properties? Even if we include the :TRANSACTION triple in the second example (which I think is important to preserve the semantics), this problem persists.

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