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

Hi,
the issue is not which is the most reasonable representation of this case, but how many legitimate different ways there are to represent this case, and allow for all of them, so to support data integration from different sources.
—e.

On 27 Mar 2024, at 09:51, Kurt Cagle <kurt.cagle@gmail.com> wrote:

Wouldn't a better approach be something like:

Person:Enrico a Person: ;
       Person:hasMarriage [
              a Marriage: ;
              Marriage:location Location:Rome ;
              Marriage:startDate Year:1962 ;
              Marriage:to Person:Serafina ;
              ] ;
.

(I'm using the class names as prefixes here simply to make it obvious what these resource interfaces are).

The one area where I can see this working with reifiers is when you want to connect existing entities:

<< Marriage:m1 | Person:Enrico Person:married  Person:Serafina >>
      Marriage:child Person:Paolo, Person:Linetta ;
      Marriage:location Location:Rome ;
      Marriage:startDate Year:1962 ;
      Marriage:endDate Year:1971 ;
      .

<< Marriage:m2 | Person:Enrico Person:married  Person:Elizabetta>>
      Marriage:child Person:Antonio ;
      Marriage:location Location:Venice ;
      Marriage:startDate Year:1973 ;
      Marriage:endDate Year:1994 ;
      .









      .


Kurt Cagle
Editor in Chief
The Cagle Report
kurt.cagle@gmail.com<mailto:kurt.cagle@gmail.com>
443-837-8725<http://voice.google.com/calls?a=nc,%2B14438378725>


On Wed, Mar 27, 2024 at 12:42 AM Franconi Enrico <franconi@inf.unibz.it<mailto:franconi@inf.unibz.it>> wrote:
>> << :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 .
>
> It helps with the issue of naming, but it doesn’t address the asymmetry. Now Enrico has married-in and married-on properties, and the reification has date and location properties. Why is this a good model of properties that all come from the same relation where they are all properties of birth certificates?

They are not: has married-in and married-on have domain person, while date and location have domain birth certificate. They NEED to be distinct properties, and depending on what are you talking about (people or birth certificates) you use the former of the latter.

> And I still think this is a fundamental problem with this example: “two departments decide to expose this data as LOD, but in different ways.” That would be one thing if they were each exposing LOD using local identifiers, but they’ve both used the universal identifiers (b1, b2, …) for the reification in incompatible ways.

They are not incompatible.
You are assuming that organisations are rational entities that structure their data in a syntactically uniform and consistent way all over the world. The fact that this assumption is not true is witnessed by the mess that enterprises have in doing data integration, which is the main raison d’être of semantic web technologies: deal with syntactically different ways of representing semantically equivalent information.

—e.