AW: LPG-RDF1.2 interoperability is already nontrivial due to weakness of LPG edge-property vs RDF1.2 statement-about-statement

The cost is the LPG interoperability which could be improved by proposal we are discussing – without becoming perfect.

Why I ask about use cases for the core technology (RDF): a common pattern I have seen in standardization is to add capabilities that are not part of that core tech. to an application layer.
Again here is an XML example: XML does not allow overlapping hierarchies of markup. Esp. linguistic research communities need this feature and have created options e.g. in TEI [2].
Wouldn’t be the same an option for someone who needs several levels of annotations, leveraging e.g. the Web Annotation Data Model [3]?

Best,

Felix

[2] https://tei-c.org/release/doc/tei-p5-doc/it/html/NH.html

[3] https://www.w3.org/TR/annotation-model/

Von: Thomas Lörtsch <tl@rat.io>
Datum: Freitag, 12. April 2024 um 14:27
An: Sasaki, Felix <felix.sasaki@sap.com>, public-rdf-star-wg@w3.org <public-rdf-star-wg@w3.org>, Souripriya Das <souripriya.das@oracle.com>
Betreff: Re: LPG-RDF1.2 interoperability is already nontrivial due to weakness of LPG edge-property vs RDF1.2 statement-about-statement


Am 12. April 2024 12:59:03 MESZ schrieb "Sasaki, Felix" <felix.sasaki@sap.com>:
>Thanks, Thomas. Technically, i understand how
>
>    :e1 :influenced :e2 {| :ex:certainty ex:medium |}
>
>Technically works. And I understand the use case to express further metadata about the “influenced” relation. What I am trying to better understand is the strength of the need, based on use case examples. The more examples, the better.

I think some things are better assessed in the abstract. Some (modestly) abstract use cases:

- ingesting already annotated data and annotating those annotations
- using edge annotations to model n-ary relations with a main relation (the annotated edge) and secondary attributes of the relation (the anmotations). Then annotating all that ("main" edge and "secondary" attributes) with administrative meta data
- documenting opinions on opinions on opinions..., or versions of versions of versions... , or any other chains of attribution
- never say never ;-)

Graphs are already rather freewheeling creatures. I'd like the annotation mechanism to follow the same logic (at least on the RDF side, although I understand how LPG following an in many ways more constrained approach helps initial uptake).

What is the cost that you want to weigh the need against?

Best,
Thomas



>Best,
>
>Felix
>
>Von: Thomas Lörtsch <tl@rat.io>
>Datum: Freitag, 12. April 2024 um 11:26
>An: public-rdf-star-wg@w3.org <public-rdf-star-wg@w3.org>, Sasaki, Felix <felix.sasaki@sap.com>, Souripriya Das <souripriya.das@oracle.com>, RDF-star WG <public-rdf-star-wg@w3.org>
>Betreff: Re: LPG-RDF1.2 interoperability is already nontrivial due to weakness of LPG edge-property vs RDF1.2 statement-about-statement
>
>
>Am 12. April 2024 09:03:22 MESZ schrieb "Sasaki, Felix" <felix.sasaki@sap.com>:
>>Hi Souri and all,
>>
>>We did not discuss this during the call yesterday. It would be great to get feedback from others on the list.
>>
>>About
>>
>>:e3 rdf:reifies <<( e1 :influenced :e2 )>> .
>>
>>I continue to ask what use case is behind this additional layer of reification. With
>>
>>e1 :influenced :e2
>>
>>I can easily query all edges that have been influenced by each other. Why do I need another reification?
>
>You don't need to create a reification to state that
>
>   :e1 :influenced :e2.
>
>Only if you want to annotate that relation with e.g. a certainty account you'll have to create a reifier:
>
>    :e3 rdf:reifies <<( :e1 :influenced :e2 )>> .
>
>and annotate it:
>
>    :e3 ex:certainty ex:medium .
>
>But that is just the NTriples syntax, which needs to expose all the details. The annotation syntax provides some syntactic sugar to state and annotate a fact in one go:
>
>    :e1 :influenced :e2 {| :e3 | ex:certainty ex:medium |}
>
>Or even shorter, if you don't need an explicit identifier for that reification:
>
>    :e1 :influenced :e2 {| :ex:certainty ex:medium |}
>
>which creates a new blank node en lieu of  :e3.
>
>
>I hope that answers your question.
>
>Best,
>Thomas
>
>
>>Best,
>>
>>Felix
>>
>>Von: Souripriya Das <souripriya.das@oracle.com>
>>Datum: Donnerstag, 11. April 2024 um 17:43
>>An: RDF-star WG <public-rdf-star-wg@w3.org>
>>Betreff: LPG-RDF1.2 interoperability is already nontrivial due to weakness of LPG edge-property vs RDF1.2 statement-about-statement
>>Sie erhalten nicht oft eine E-Mail von souripriya.das@oracle.com. Erfahren Sie, warum dies wichtig ist<https://aka.ms/LearnAboutSenderIdentification>
>>(Let me admit first that, for me, "edges" are fundamental, not triples, and, IMHO, not having user-friendly support for edges, and hence edge-properties and parallel edges, is a major deficiency in RDF1.1 that has let LPG zoom past RDF in popularity.)
>>
>>Since the debate regarding whether rdf:reifies should be single-valued or multi-valued is considering its implications on interoperability of LPG and RDF1.2, we need to take into account the fact that the fundamental restriction in LPG that "edge-properties can only connect an edge to a scalar value" already makes conversion of RDF1.2 to LPG difficult because RDF1.2 supports unrestricted "statement about statement" capability. Let me explain.
>>
>>Based on the latest thoughts  on RDF1.2, each "edge" will have an associated id ("reifier") that can be used to say anything about the edge. Besides allowing connecting an edge to a scalar value, this capability also allows the data creator to create an edge that connect a pair of edges, or a vertex and an edge, without any restructuring of pre-existing data. LPG, with its restriction that an edge-property can only connect an edge to a scalar value, cannot handle connecting a pair of edges or an edge with a vertex, so easily. It has to restructure the pre-existing data, jeopardizing the validity of pre-existing queries. I have illustrated this with a simple example below. (I had illustrated this deficiency of LPG with a similar example in the "Appendix: A Complete Example" section of [1] as well.)
>>
>>So, capability wise, I'll argue that LPG is less capable than RDF1.2, and, regardless of whether we decide to restrict rdf:reifies to being single-valued or not, this deficiency in LPG will affect interoperability unless LPG is extended from what it is today.
>>
>>Example to support my argument that LPG is less capable than RDF1.2:
>>=========================================================
>>Consider this "edge connecting two edges" scenario: We know initially the facts that John donated to a campaign (probably millions of dollars :-)) and that John was appointed (later) an ambassador (to some country). Later, some analysts connected the two facts, asserting that the first fact has influenced the second.
>>
>>In RDF1.2, initially, we store the following two edges: (here, I use an edge as representing a named binary relationship instance, not just a reification):
>>-------------
>>      :e1 rdf:reifies <<( :john :donatesTo :campaign )>> .
>>      :e2 rdf:reifies <<( :john :appointedAs :ambassador )>> .
>>
>>Later, we add the following to represent the "influenced" relationship:
>>      :e3 rdf:reifies <<( e1 :influenced :e2 )>> .
>>
>>Since this involved only addition of a new edge, and no restructuring of the original edges, none of the pre-existing queries are affected.
>>
>>In LPG, however, one cannot implement this without a major restructuring, involving "vertexification" of the edges:
>>---------
>>Initially, LPG would use the following two edges:
>>      (john) -[:donatesTo]-> (campaign)
>>      (john) -[:appointedAs]-> (ambassador)
>>
>>Later, when the need arises to connect these two edges via the "influenced" relationship, LPG has to "vertexify" the original edges to get this done:
>>      (donatesToVertex) -[:donator]-> (john)
>>      (donatesToVertex) -[:receiver]-> (campaign)
>>      (appointedAsVertex) -[:appointee]-> (john)
>>      (appointedAsVertex) -[:role]-> (ambassador)
>>
>>      (donatesToVertex) -[:influenced]-> (appointedAsVertex)
>>
>>This restructuring in LPG case, completely invalidates all pre-existing queries that relied upon the edge labels :donatesTo and :appointedAs. All such queries now have to redesigned.
>>
>>Thanks,
>>Souri.
>>
>>[1] https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fblogs.oracle.com%2Foraclespatial%2Fpost%2Fmodeling-evolving-data-in-graphs-the-power-of-rdf-quads&data=05%7C02%7Cfelix.sasaki%40sap.com%7C9c1defb9a73e484898c408dc5aebea4d%7C42f7676cf455423c82f6dc2d99791af7%7C0%7C0%7C638485216544081594%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=DJ3CBO5N7EG9tcTBd7PvLHSFcc8jSKJK1CjPr8YtiIA%3D&reserved=0<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fblogs.oracle.com%2Foraclespatial%2Fpost%2Fmodeling-evolving-data-in-graphs-the-power-of-rdf-quads&data=05%7C02%7Cfelix.sasaki%40sap.com%7C9c1defb9a73e484898c408dc5aebea4d%7C42f7676cf455423c82f6dc2d99791af7%7C0%7C0%7C638485216544091602%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=7CzHPTByCu9u5HizlGJ%2Bp%2FdeqJb3P9QnBj19Am7DeNw%3D&reserved=0><https://blogs.oracle.com/oraclespatial/post/modeling-evolving-data-in-graphs-the-power-of-rdf-quads>
>>