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

Greg, you are right.
I overlooked the case with literals.
My example should still work if the database involves IRIs.

WEDDING-CERTIFICATE
+-----+---------+----------+------+
| ID  |  name   | location | date |
+-----+---------+----------+------+
| :b1 | :enrico | :rome    | 1962 |
| :b2 | :mary   | :rome    | 1962 |
| :b3 | :enrico | :rome    | 1980 |
| :b4 | :mary   | :rome    | 1980 |
+-----+---------+----------+------+
  Primary Key: ID
  Alternate Key: name, location, date

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

Cheers
--e.

On 25 Mar 2024, at 16:28, Gregory Williams <greg@evilfunhouse.com> wrote:



On Mar 25, 2024, at 4:54 AM, Franconi Enrico <franconi@inf.unibz.it> wrote:

As I wrote, :enrico identifies the name of a person, and it does not identify a person.

How can this be squared with the assertion

:enrico :born-in :rome

?

A name is not born in a city.

Generated graph-2:

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

This doesn’t look right to me. A birth certificate doesn’t have a location, the *birth* has a location. But the ID here seems to identify the birth certificate (as it is used as the primary key for "BIRTH-CERTIFICATE”?). And there’s an asymmetry in that :born-on is a property of the name, while :location is a property of the reification (in this case, I guess that’s really mean to be a property of the brith certificate?)

I am not convinced by this example at all. The modeling seems incomprehensible to me. Beyond the modeling issues, though, I think this is a fundamental problem:

Two departments decide to expose this data as LOD, but in different ways.

Why should we expect sensible data to result if two different departments use the same *universal* identifiers to model data in different ways? Of course this will lead to bad or confusing data.

Thanks,
Greg