Re: A single reifier can reify more than one triple term

As I wrote, :enrico identifies the name of a person, and it does not identify a person. From the table schema it is clear that the name attribute alone does not identify a birth certificate.
The introduction of an iri for the name is necessary in order to have it in subject position.
If you don’t like that, imagine an example with a genuine ternary relation with iris as values, for example our classical wedding: attributes are :spose1 :spouse2 :location, with a PK made by the three attributes, assuming that no two people marries in the same location 🙂. Following the same structure of my example, the predicates in the triple terms would become :has-spouse and :married-in.

Does it make sense now?
—e.

On 25 Mar 2024, at 12:29, Lassila, Ora <ora@amazon.com> wrote:


The example is flawed. In RDF identifiers are supposed to be unique (in the sense that they identify a unique “thing”), and so now in your generated graph-1 there is an identifier :enrico twice, with two different birth dates (maybe he is Dionysos ;-).

Uniquely identifying a person allows the birth certificate to be constructed around the person. So I fail to see the need for a reifier to reify more than one triple, at least from this example.

Aside from this, I also worry about having to explain an identifier reifying a set of triples vs. an identifier identifying a set of triples (a named graph). I promise that distinction will be lost on many people.

I cannot stress the importance of our ability to explain RDF. We have had 25+ years of uphill battle, and it is not going to end now.

Ora

--
Dr. Ora Lassila
Principal Technologist, Amazon Neptune




From: Franconi Enrico <franconi@inf.unibz.it>
Date: Monday, March 25, 2024 at 4:12 AM
To: RDF-star Working Group <public-rdf-star-wg@w3.org>
Subject: [EXTERNAL] A single reifier can reify more than one triple term
Resent-From: <public-rdf-star-wg@w3.org>
Resent-Date: Monday, March 25, 2024 at 4:12 AM


CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.

I wish to insist on the meaningfulness of my example:

<< :b1 | :enrico :born-in :rome >> :date 1962 .
<< :b1 | :enrico :born-on 1962 >> :location :rome .

Please read on to understand my argument.

Suppose there is a database in the registry office:

BIRTH-CERTIFICATE
+-----+---------+----------+------+
| ID  |  name   | location | date |
+-----+---------+----------+------+
| :b1 | :enrico | :rome    | 1962 |
| :b2 | :mary   | :rome    | 1962 |
| :b3 | :enrico | :rome    | 1980 |
| :b4 | :mary   | :rome    | 1980 |
| :b5 | :enrico | :milan   | 1962 |
| :b6 | :mary   | :milan   | 1962 |
| :b7 | :enrico | :milan   | 1980 |
| :b8 | :mary   | :milan   | 1980 |
+-----+---------+----------+------+
  Primary Key: ID
  Alternate Key: name, location, date

It is important to notice that no pair among the three attributes name, location, date is sufficient to identify a birth certificate.
Two departments decide to expose this data as LOD, but in different ways.

Generated graph-1:

<< :b1 | :enrico :born-in :rome >> :date 1962 .
<< :b2 | :mary :born-in :rome >> :date 1962 .
<< :b3 | :enrico :born-in :rome >> :date 1980 .
etc

Observe that they had to choose a different name for the attribute within the context of the triple term: this is because the predicate :born-in in the triple term relates the name of a person with its birth location, as opposed the attribute :location which relates a birth certificate with the birth location of the name of a person at a certain date.

Similarly for the second department - they also changed the predicate :date to :born-on:

Generated graph-2:

<< :b1 | :enrico :born-on 1962 >> :location :rome .
<< :b2 | :mary :born-on 1962 >> :location :rome .
etc

If we merge the two LOD graphs (set union):

<< :b1 | :enrico :born-in :rome >> :date 1962 .
<< :b1 | :enrico :born-on 1962 >> :location :rome .
etc

which entails

<< :b1 | :enrico :born-in :rome >> :location :rome .
<< :b1 | :enrico :born-on 1962 >> :date 1962 .
etc

➡️ Observe that even if it seems that there is redundant information, the predicates are different (:born-in vs :location, and :born-on vs :date). This is because they serve different purposes: one applies to the name of a person, the other applies to a certificate.

I hope this clarifies:

  1.  the need to allow a reifier to reify two distinct triple terms;
  2.  the possibility to express the same information in different ways.

cheers
—e.