Re: RDF star and LPGs

Hi Felix,
done!
let me know if it is ok.
cheers
—e.

On 22 Jul 2024, at 15:37, Sasaki, Felix <felix.sasaki@sap.com> wrote:

Hi Enrico, and all,

Apologies for only providing feedback from time to time.

The RDF star and LPGs document is very helpful IMO for explaining RDF stars relation to LPGs folks.

What could help to make this even more useful: to add at the top another transaction, e.g.

CREATE (a1)-[:TRANSACTION {amount: 500, currency: "eur", date: "2003-10-24Z"}]->(a2)

That is: between the two accounts that already have a transaction

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



And then take the two transactions up in further explanations in the document.

Best,

Felix


Von: Franconi Enrico <franconi@inf.unibz.it<mailto:franconi@inf.unibz.it>>
Datum: Montag, 22. Juli 2024 um 11:33
An: Gregory Williams <greg@evilfunhouse.com<mailto:greg@evilfunhouse.com>>
Cc: RDF-star WG <public-rdf-star-wg@w3.org<mailto:public-rdf-star-wg@w3.org>>
Betreff: Re: RDF star and LPGs
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.
cheers
—e.


On 19 Jul 2024, at 11:56, Franconi Enrico <franconi@inf.unibz.it<mailto:franconi@inf.unibz.it>> wrote:

On 19 Jul 2024, at 02:53, Gregory Williams <greg@evilfunhouse.com<mailto:greg@evilfunhouse.com>> wrote:
I mentioned in the call today that I had concerns about the "RDF star and LPGs” document[1] that was linked on IRC. I didn’t find any previous mention of that document in the mailing list archives, so unsure if it has been discussed previously (perhaps on a previous call?). Overall, I'm skeptical of the mapping presented in the document, and especially as the basis for making arguments that the current baseline proposal is compatible with LPG use-cases that have been previously discussed.

(I may be making assumptions about the mapping here, but since it is presented in the form of a single, simple example, I guess that’s to be expected. Similarly, I may be reading a lot into the "<—>” mapping indicator used between the example LPG and RDF data; please let me know if I’ve misunderstood the intention.)

Your assumptions are correct. The intention of that sketchy document is to argue that the current baseline proposal is compatible with LPG use-cases that have been previously discussed.


I think on its face the RDF-LPG mapping presented does not preserve the intended semantics. To me, the intent of the LPG syntax is pretty clearly to assert that there are two transactions that occurred. They exist!

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

But the mapped RDF does *not* define any transactions. There are no `:TRANSACTION` triples in the graph – that predicate only exists inside triple terms. So maybe they are hypothetical transactions?

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

<< :e2 | :a2 :TRANSACTION :a3 >> ;
  :amount 900 ;
  :currency "gbp" ;
  :date "2002-10-03Z"^^xsd:date .
```

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

The purpose of the document is to show that the baseline is able to encode LPG information without any problem, and it is invertible (as argued in the “observations”). The document does not want to propose or define any canonical mapping. Maybe we could have a discussion in the WG on proposing such canonical mapping.

Furthermore, the mapping does not appear to be a bijection, and cannot be round-tripped. What happens to those triple terms if you try to map back to LPG? Do they disappear, as they are not asserted in the RDF graph? If, instead, they are mapped back into actual `:TRANSACTION` edges, how would that be different from mapping similar RDF that also asserted the `:TRANSACTION` triples in the graph (in addition to the triple terms)?

The mapping, by definition, defines a transformation between syntactic structures of LPGs and RDF-star. As such, the mapping exemplified in the document is perfectly invertible, as it would be the one extended by the triples I mentioned above.


I think this starts to touch on the point that Thomas has been making about asserted vs. unasserted assertions and the difficulty of modeling that difference in our current formalization.

I don’t think this has anything to do with asserted vs unasserted triples. It is up to the designer to decide what a transaction is in the RDF graph. In the example, it is a resource and, if the designer wants, it could be also a triple in the graph. No problem.

Under “OBSERVATIONS":

> Reifiers denote edge identifiers.

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 .


That doesn't seem viable, as all existing RDF data prior to rdf-star would be entirely inaccessible based on this mapping. I am nervous about any one-way mapping, as it has implications for the sorts of systems you can build and the use-cases that they can address.

I don’t see why you are nervous, since you decide the mapping. We just have shown that this is possible.


And I’m similarly nervous about basing support for the baseline proposal on this document as an assurance that we are now able to capture LPG use cases. The mapping is just too casual, and leaves out far too many specifics to be useful in understanding if it can practically address LPG use-cases.

If you still believe that this is the case, make a constructive proposal on which variant of RDF-star we need to practically address LPG use-cases, and how.

cheers
—e.


thanks,
.greg

[1] https://github.com/w3c/rdf-star-wg/wiki/RDF-star-and-LPGs