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

Hi Enrico, All,

So the question is what are you identifying with the << :b1 | :enrico :married-in :rome >> here? Do you want :b1 to refer to a single triple or a set of them?
If a set of triples e.g. :b1 is a "graph" identifier then what you want is possible if :b1 is a "single triple" identifier then no.

Now I can understand the desire for being to reify sets of triples as in in the UniProt evidencing use case it would be nice to evidence paths in the graph.
As a simple example

:nice-route-to-work {
  :front-door :walkTo :park .
  :park :walkTo :office .
}
and
:horrible-route-to-work {
  :front-door :driveTo :highway .
  :highway :waitIn :trafficJam .
  :trafficJam :driveTo :office .
}

This comes down to the chosen semantics and there are pro and cons to both. I again encourage the WG look for use cases that are not well served by RDF/SPARQL 1.1.
Here we have graphs to collect sets of data, and this way they are currently used, and are very suitable in practical terms.
While we don't have an easy way to refer to a single triple, to attach data that describes information about a single subject-predicate-object arc.
Now you might feel that there is a large overlap between these, and I agree. However, I think the primary difference between these is the use cases.
Here :nice-route-to-work and :horrible-route-to-work are key concepts in the use-case of getting me to the office in a good mood.
While the triple terms will often be used for secondary use cases that are not the primary use-case of the data-modeller.

From the LPG examples

<< :pipe1 | :vatA :connectsTo :vatB >> :length "15"^^si:m .

Is a modelling choice for whom the :length and other attributes of that pipe are not that important.
Because if that was important the natural modelling would be.

:pipe1 a :Pipe ;
  :flowsFrom :vatA ;
  :flowsTo :batB ;
  :length ""15"^^si:m ;
  :max-presure "100"^^si:Pa ; #etc.

As when that length is important you start to want to have lot's of information about that pipe (think chemical plant maintenance).
i.e. if something is important it will have it's own identifier and not depend on a triple term to hang on.


Regards,
Jerven

P.S. I have some ideas on RDF/XML for both triple terms and named graph support in what I think are highly backwards compatible maners.









[SIB logo]
Jerven Tjalling Bolleman
Principal Software Developer
SIB | Swiss Institute of Bioinformatics
1, rue Michel Servet - CH 1211 Geneva 4 - Switzerland
t +41 22 379 58 85
Jerven.Bolleman@sib.swiss - www.sib.swiss

________________________________
From: Franconi Enrico <franconi@inf.unibz.it>
Sent: 27 March 2024 11:38
To: Kurt Cagle <kurt.cagle@gmail.com>
Cc: Gregory Williams <greg@evilfunhouse.com>; Lassila, Ora <ora@amazon.com>; RDF-star Working Group <public-rdf-star-wg@w3.org>
Subject: 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.