Re: Understanding reifiers and edges

On Wed, Apr 24, 2024 at 11:18 PM Sasaki, Felix <felix.sasaki@sap.com> wrote:
>
> Two ways to serialize LPG structures are tables and JSON collections.
>
>
>
> Below are serializations for the examples we have discussed in various threads.
>
>
>
> TABLE BASED ENCODING:
>
>
>
> Vertex.csv:
>
> ```
>
> VertexId
>
> liz
>
> richard
>
> ```
>
>
>
> Edge.csv:
>
> ```
>
> EdgeId,SourceVertex,TargetVertex,Relationship,From,To
>
> 1,liz,richard,MARRIED,1964,1975
>
> 2,liz,richard,MARRIED,1985,
>
> ```
>
>
>
>
>
>
>
> JSON BASED ENCODING:
>
> ```
>
> [
>
>     {
>
>         "entity_type": "vertex",
>
>         "entity_id": "liz"
>
>     },
>
>     {
>
>         "entity_type": "vertex",
>
>         "entity_id": "richard"
>
>     },
>
>     {
>
>         "entity_type": "edge",
>
>         "entity_id": "1",
>
>         "source_vertex": "liz",
>
>         "target_vertex": "richard",
>
>         "relationship": "MARRIED",
>
>         "from": 1964,
>
>         "to": 1975
>
>     },
>
>     {
>
>         "entity_type": "edge",
>
>         "entity_id": "2",
>
>         "source_vertex": "liz",
>
>         "target_vertex": "richard",
>
>         "relationship": "MARRIED",
>
>         "from": 1985
>
>     }
>
> ]
>
> ```
>
>
>
>
>
> How would you extend these encodings to realize the “many to many reifiers” approach?

I wouldn't; or I would use multiple tables. Which I would if I *had*
to shoehorn in basically any kind of RDF from the various contexts
I've worked in. One table is way too flat for graph-structured data in
general (or trees for that matter); there are all kinds of
many-to-many in that. Unless of course we shift down an abstraction
level and use columns like S_IRI, S_BLANK, P_IRI, O_IRI, O_BLANK,
O_LITERAL_LEXICAL, O_LITERAL_LANG, ... and so on (or some variation
thereof).

If you want to see the above data in JSON-LD-star (we're planning to
pick that up for standardization in JSON-LD 1.2), use the syntax
toggle in that visualizer (that's what's actually being rendered,
since LDTR uses JSON-LD as a kind of RDF AST).

Cheers,
Niklas

(PS. The RDF/XML mode in that demo page doesn't yet properly work for
these additions (it needs to produce the new rdf:reifier
occurrence-to-triple relations). Many months ago I tinkered a bit to
get rdf:ID working for annotations to get a better feel for the
old-school reifications. But we've moved on from that (it was option
1, "just reification").)


>
> Best,
>
>
> Felix
>
>
>
>
>
> Von: Niklas Lindström <lindstream@gmail.com>
> Datum: Mittwoch, 24. April 2024 um 22:55
> An: RDF-star Working Group <public-rdf-star-wg@w3.org>
> Betreff: Re: Understanding reifiers and edges
>
> For the dual purpose of A) getting a better feel for many-to-many
> reifiers in practice, and B) experimenting with annotation naming
> syntax (see [1]), I just updated my TriG-star parser and RDF
> visualizer to try out some of that. Here's a view of a TriG dataset
> containing various examples:
>
>     https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fniklasl.github.io%2Fldtr%2Fdemo%2F%3Furl%3D..%2Ftest%2Fdata%2Freifiers-misc-m2m.trig%26edit%3Dtrue&data=05%7C02%7Cfelix.sasaki%40sap.com%7Cc75c1135b88c48bb224a08dc64a0be19%7C42f7676cf455423c82f6dc2d99791af7%7C0%7C0%7C638495889506594113%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=cz8MOKiIG7Zxs9Tny94t1WhQaUgCGL8bF7engyPNVFs%3D&reserved=0
>
> (It's editable, just running in the browser with nothing persisted.
> The editor area is toggled with the button in the bottom right
> corner.)
>
> This is also an example of how named graphs and m2m reifiers are
> indeed orthogonal for, on the one hand, dataset partitioning, and on
> the other, describing different kinds of situations and events which
> underlie simple triples, including granular triple provenance.
>
> Best regards,
> Niklas
>
> [1]: <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c%2Frdf-star-wg%2Fissues%2F116&data=05%7C02%7Cfelix.sasaki%40sap.com%7Cc75c1135b88c48bb224a08dc64a0be19%7C42f7676cf455423c82f6dc2d99791af7%7C0%7C0%7C638495889506605293%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=IthePRJw40%2BcMfzuPoEu90PRQKRZCGaGxyAcIBv4gsA%3D&reserved=0>
>
>
>
>
>
> On Tue, Apr 23, 2024 at 10:42 PM Niklas Lindström <lindstream@gmail.com> wrote:
> >
> > For Thursday's discussion it would be great if those who can to take
> > some time, especially those favoring "edge properties", to look at
> > various definitions and patterns for reification using many-to-many
> > notions (including such patterns for N-ary relations, like [1]).
> > Enrico has mentioned many formal references. Here is just a short one
> > in UML: [2]. (We've also given several examples on the list
> > (marriages, book collaborations, pipe connections); but I think formal
> > definitions may be more convincing to those who remain unperturbed.)
> >
> > I also tried to see things more from the LPG perspective. We already
> > know that the edges in LPGs are not identified by their vertices and a
> > label, but by a unique id. Enrico has pointed to this more than once,
> > and it was recently very clearly illustrated by Kurt in [3].
> > (Otherwise, if they were just the two vertices and the edge label,
> > that would simply be the seminal mistake all over again; preventing
> > the entire point of distinguishing edge properties. Something Kurt
> > also illustrated as the "naive" approach [4] (which I readily concur
> > with).)
> >
> > This actually makes edge properties *very* similar to singleton
> > properties [5]. A pattern that has been dismissed for multiple reasons
> > (e.g. [6]). But in fact, at least Neo4J refers to the label of edges
> > as their *types*. And that is exactly how singleton properties are
> > explained in the aforementioned paper (their proposed
> > `rdf:singletonPropertyOf` is defined as a subproperty of `rdf:type`).
> > (This similarity is also shared by RDFn (named triples), as Thomas
> > pointed out quite some time ago [7].)
> >
> > I continue to favour many-to-many reifiers, as they appear more
> > intuitive to me. Simple relationships, as abstracted using triples,
> > always stem from something more concrete and/or detailed, that reify
> > them in some way. Depending on which perspective and distance that
> > reifier is conceptualized from, one or more triples will be naturally
> > reified. I find it *harder* to rely on an a priori domain-restrictive
> > notion of an edge as a slightly more "instantiated" relationship of
> > the same "type" as a simple predicate. I found it odd when I first
> > encountered Neo4J over a decade ago, and I still find it constrained
> > by implementation (or *perhaps* representation), rather than reason. I
> > can see cases for it (ex:MarriedToDirectedEdge), cases beneath it
> > (ex:TripleToken), and cases clearly beyond it (ex:DescriptionIngest,
> > ex:CataloguerSuggestion, ex:Marriage, ex:BookCollaboration,
> > ex:TJunctionConnection). Using rdf:reifies to link from an instance of
> > any of those concepts to one or more triples simply works for all such
> > cases alike.
> >
> > And yes, in *some* of them making an OWL restriction on the
> > cardinality for rdf:reifies to have an effectively functional
> > *semantic* behavior for some specific class is perfectly fine. But not
> > built-in to RDF proper. (And, to also answer Dörthe, absolutely not as
> > a syntactic restriction; but I don't think anyone is asking for that?)
> >
> > (For fun I also checked with a certain famous, pretrained neural
> > network, asking: "In conceptual modeling, can one single reification
> > reify multiple simple relations?", and got: "Yes, in conceptual
> > modeling, it's possible for a single reification to reify multiple
> > simple relations. Reification is the process of representing abstract
> > concepts or relationships as concrete entities or objects.", along
> > with yet another example: an Assignment reifying the two relations X
> > workedOnProject P and X aquiredSkill Y. I leave it to you to determine
> > how much of a hallucination that was.)
> >
> > Best regards,
> > Niklas
> >
> > [1]: <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FTR%2Fswbp-n-aryRelations%2F%23useCase3&data=05%7C02%7Cfelix.sasaki%40sap.com%7Cc75c1135b88c48bb224a08dc64a0be19%7C42f7676cf455423c82f6dc2d99791af7%7C0%7C0%7C638495889506612484%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=4GL8k0GvP%2BHSTPkvBOXwCi5pebvqAZHdkZ33b8taG3o%3D&reserved=0>
> > [2]: <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fd37djvu3ytnwxt.cloudfront.net%2Fassets%2Fcourseware%2Fv1%2F947b66081249d2aa46671a9f04b8503a%2Fasset-v1%3AKULeuvenX%2BUMLx%2B1T2017%2Btype%40asset%2Bblock%2FUMLx_6b_AssociationReification.pdf&data=05%7C02%7Cfelix.sasaki%40sap.com%7Cc75c1135b88c48bb224a08dc64a0be19%7C42f7676cf455423c82f6dc2d99791af7%7C0%7C0%7C638495889506617078%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=yFS3yssVH%2FkejkI%2Bd6n%2FTgfUBYE8VRB67nxrpPm%2Bxqo%3D&reserved=0>
> > [3]: <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.w3.org%2FArchives%2FPublic%2Fpublic-rdf-star-wg%2F2024Apr%2F0134.html&data=05%7C02%7Cfelix.sasaki%40sap.com%7Cc75c1135b88c48bb224a08dc64a0be19%7C42f7676cf455423c82f6dc2d99791af7%7C0%7C0%7C638495889506621521%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=sPAzNzCUEkdIj4IQEqKiLiQiHfQQJQ1v4PAlDsaBnls%3D&reserved=0>
> > [4]: <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.w3.org%2FArchives%2FPublic%2Fpublic-rdf-star-wg%2F2024Apr%2Fatt-0134%2FNaive_RDF-2024-04-19-213559.png&data=05%7C02%7Cfelix.sasaki%40sap.com%7Cc75c1135b88c48bb224a08dc64a0be19%7C42f7676cf455423c82f6dc2d99791af7%7C0%7C0%7C638495889506625614%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=RVJmBahyx4oTJdQeK6ZLZmYpuSuGtpCPJaK%2F5LflDRI%3D&reserved=0>
> > [5]: <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ncbi.nlm.nih.gov%2Fpmc%2Farticles%2FPMC4350149%2F&data=05%7C02%7Cfelix.sasaki%40sap.com%7Cc75c1135b88c48bb224a08dc64a0be19%7C42f7676cf455423c82f6dc2d99791af7%7C0%7C0%7C638495889506629627%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=etQUiNsqTJeQfWJCfq%2BwzWMYmWnHGRdTqWFZI%2BUlZv4%3D&reserved=0>
> > [6]: <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgraphdb.ontotext.com%2Fdocumentation%2F9.4%2Ffree%2Fdevhub%2Frdf-sparql-star.html%23singleton-properties&data=05%7C02%7Cfelix.sasaki%40sap.com%7Cc75c1135b88c48bb224a08dc64a0be19%7C42f7676cf455423c82f6dc2d99791af7%7C0%7C0%7C638495889506633536%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=7ssPEype9G%2FhM6PhOaGn9Ex9xGfVQAqflqtvUdPeJ6M%3D&reserved=0>
> > [7]: <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.w3.org%2FArchives%2FPublic%2Fpublic-rdf-star-wg%2F2022Dec%2F0029.html&data=05%7C02%7Cfelix.sasaki%40sap.com%7Cc75c1135b88c48bb224a08dc64a0be19%7C42f7676cf455423c82f6dc2d99791af7%7C0%7C0%7C638495889506637672%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=XTP9eS7wMWfw%2BoHf%2BYBPd91svEbm1XFhTSPH77KSsZw%3D&reserved=0>

Received on Wednesday, 24 April 2024 21:39:17 UTC