- From: <ddooss@wp.pl>
- Date: Tue, 20 Aug 2024 12:03:51 +0200
- To: Franconi Enrico <franconi@inf.unibz.it>,Souripriya Das <souripriya.das@oracle.com>,Peter F. Patel-Schneider <pfpschneider@gmail.com>
- Cc: public-rdf-star-wg@w3.org <public-rdf-star-wg@w3.org>
- Message-ID: <0582256e41dc4913a5e1147effe8f082@grupawp.pl>
Hi Enrico, I agree that this approach is a good one and has the potential to simplify the handling of reification in RDF. However, I believe that this does not necessarily exclude the possibility of standardizing other properties we are currently discussing. While rdf:reifies may serve as a foundational property, the specific use cases we are addressing might still benefit from the formalization and standardization of additional properties. These additional properties could provide more precise semantics or facilitate specific types of queries and reasoning that go beyond the general reification pattern. Best, Dominik
Dnia 20 sierpnia 2024 10:30 Franconi Enrico <franconi@inf.unibz.it> napisał(a):
Along these lines, we could introduce in RDF the class rdf:reificationProperty (or another agreed upon name), of which rdf:reifies is an instance of (axiomatic triple: rdf:reifies a rdf:reificationProperty).
Then, we weaken the well formed fragment to allow any property instance of rdf:reificationProperty to have a triple term as object.
So, we don't need to standardize any other property than rdf:reifies, and we do not need to extend RDFS.
What do you think?
--e.
On 20 Aug 2024, at 01:52, Souripriya Das <souripriya.das@oracle.com> wrote:
Hi Peter,
Just realized that Thursday has been reserved for discussing the feasibility of creating "profiles."
> What is the difference you want between rdf:reifies and rdf:asserts?
Two distinct properties are meant for use in being able to designate each triple-term (not triple) to one of the two types – asserted or reified. RDF does not attach any special semantics or entailment rules for these two types for triple-terms. Lack of any
special semantics means if we wanted we could even name these two types anything -- A and B, for example.
Having two distinct properties makes it easy to separate one kind of triple-terms from the other kind which helps in avoiding verbosity of the data and avoiding additional patterns (or FILTER NOT EXISTS) in the SPARQL queries for retrieving only one of the
two kinds of triple-patterns.
Example 1: Compact data and low-complexity query with the two-property (rdf:asserts and rdf:reifies) approach
=========
RDF data: (100 triples)
# 99 reliable triple-terms – if no reliability info, then assume reliable
:id1 rdf:asserts <<( :s1 :p1 :o1 )>> .
:id2 rdf:asserts <<( :s2 :p2 :o2 )>> .
...
:id99 rdf:asserts <<( :s99 :p99 :o99 )>> .
# one unreliable triple-term
:id100 rdf:reifies <<( :s100 :p100 :o100 )>> .
SPARQL query to retrieve the reliable ones: (single BGP)
select ?id ?s ?p ?o { ?id rdf:asserts <<( ?s ?p ?o )>> }
Example 2: Increased verbosity of data and complexity of query with the single-property (say, rdf:reifies) approach
=========
RDF data: (200 triples)
# 99 reliable triple-terms
:id1 rdf:reifies <<( :s1 :p1 :o1 )>> ; :reliable "YES" .
:id2 rdf:reifies <<( :s2 :p2 :o2 )>> ; :reliable "YES" .
...
:id99 rdf:reifies <<( :s99 :p99 :o99 )>> ; :reliable "YES" .
# one unreliable triple-term
:id100 rdf:reifies <<( :s100 :p100 :o100 )>> ; :reliable "NO" .
SPARQL query to retrieve the reliable ones: (single BGP with two triple-patterns)
select ?id ?s ?p ?o { ?id rdf:reifies <<( ?s ?p ?o )>> ; :reliable "YES" }
Example 3: Limited increased in verbosity of data and but higher complexity of query with the single-property (say, rdf:reifies) approach
=========
RDF data: (101 triples)
# 99 reliable triple-terms – if no reliability info, then assume reliable
:id1 rdf:reifies <<( :s1 :p1 :o1 )>> .
:id2 rdf:reifies <<( :s2 :p2 :o2 )>> .
...
:id99 rdf:reifies <<( :s99 :p99 :o99 )>> .
# one unreliable triple-term
:id100 rdf:reifies <<( :s100 :p100 :o100 )>> ; :reliable "NO" .
SPARQL query to retrieve the reliable ones: (two BGPs + anti-join)
select ?id ?s ?p ?o { ?id rdf:reifies <<( ?s ?p ?o )>> FILTER NOT EXISTS { ?id :reliable "NO" } }
Do you
want different simple entailments, different RDF entailments, or different
RDFS entailments? If none of these then what is the difference between them
and why then should they both be in RDF (or RDFS)?
No special semantics in RDF. Hence no special entailments at all. The only purpose is to make it easy to distinguish between two types of triple-terms (could be to differentiate them in terms of reliability at a yes/no level, for example). If more fine-grained
distinction is needed among the triple-terms, user can always create their own properties and classes.
Thanks,
Souri.
From: Souripriya Das <souripriya.das@oracle.com>
Sent: Monday, August 19, 2024 1:41 PM
To: Peter F. Patel-Schneider <pfpschneider@gmail.com>; public-rdf-star-wg@w3.org <public-rdf-star-wg@w3.org>
Subject: Re: [External] : example showing why rdf:state is essential
Not sure if you read the final paragraph that starts with "Finally, ..." in my last email. Rest we can discuss on Thursday.
From: Peter F. Patel-Schneider <pfpschneider@gmail.com>
Sent: Monday, August 19, 2024 12:11 PM
To: Souripriya Das <souripriya.das@oracle.com>; public-rdf-star-wg@w3.org <public-rdf-star-wg@w3.org>
Subject: Re: [External] : example showing why rdf:state is essential
What is the difference you want between rdf:reifies and rdf:asserts? Do you
want different simple entailments, different RDF entailments, or different
RDFS entailments? If none of these then what is the difference between them
and why then should they both be in RDF (or RDFS)?
peter
On 8/19/24 06:51, Souripriya Das wrote:
> (Just for reference, these comments were meant for my original email on this
> thread [1].)
>
> > I found the original pair of examples completely unconvincing. The first
> > example has four different rdf:reifies triples prov[i]ding nothing about
> > provenance or assertive force. But even if these triples were added
>
> There is no need to include detailed provenance in the example to illustrate
> the issue. Here is a simpler example:
>
> Example:
> # I know for sure that Bob had a stint working for B, but I think he had a
> second stint there as well.
>
> # ALT1: using two-property approach
> :stint1 rdf:asserts <<( :Bob :workedFor :B )>> . # confident
> :stint2 rdf:reifies <<( :Bob :workedFor :B )>> . # unsure
>
> # ALT2: using single-property approach – had to add annotations to distinguish
> the two stints regarding sure or unsure
> :stint1 rdf:reifies <<( :Bob :workedFor :B )>>
> ; :sure "YES" . # confident
> :stint2 rdf:reifies <<( :Bob :workedFor :B )>> .
> ; :sure "NO" . # unsure
>
> Clearly, ALT2 is more verbose because addition of the :sure properties is the
> only way to distinguish :stint1 to be different than :stint2. Even if the user
> adds the Bob-workedFor-B triple to ALT2, that will not help in distinguishing
> :stint1 from :stint2. Any related SPARQL queries in the ALT2 case would
> contain more patterns to match the :sure property and that may affect query
> performance. Support for the two-property approach in the baseline would
> eliminate such overheads.
>
> > ... there is nothing to say that :stint4 is in any way asserting
> anything just
> > because the triple it reifies is present in the graph.
>
>
> I am actually looking for such independence, but I thought that there was a
> different opinion in the group – may be I misinterpreted something I heard in
> the discussions. Such independence in RDF1.2 will ensure that 1) in ALT1,
> there should not be any automatic addition of the Bob-workedFor-B triple just
> because :stint1 uses rdf:asserts, and 2) in both ALT1 and ALT2, even if the
> Bob-workedFor-B triple was added explicitly by the user, that should not cause
> the :stint2 to be seen as asserting the event it reifies. (Of course, user's
> application-level logic could interpret things that way, but that will happen
> outside of RDF1.2.)
>
> > ... Changing the name from rdf:reifies also does nothing to change the
> > situation. The proposed rdf:id [d]oes have the unfortunate connotation
> of being
> > an identifier, which clashes with the many-to-many characteristic of
> rdf:reifies
>
>
> We had some discussion during our Semantics TF meeting on Friday about the
> mismatch between the one-to-one connotation of rdf:id [2] vs. the many-to-many
> mapping that we are trying to express. Same issue IMO with rdf:reifies though
> – because AFAIU, one-to-one – not many-to-many – is the norm for reification
> too. One possible alternative I can think of is rdf:hasTriple – goes well with
> many-to-many.
>
> > Adding assertional force information to provenance nodes *does* provide
> > information about which provenance node supports the presence of triple
> in the
> > graph whether this is done via a property like prov:reliability or a class
> > like prov:Unreliable.
>
> None of this affects the baseline, which does not touch on provenance or
> assertional force.
>
> I am hoping that within RDF1.2 there will be absolutely no built-in dependency
> between the presence (or absence) of an s-p-o triple and presence (or absence)
> of any corresponding id-s-p-o tuples (regardless whether the property used in
> the id-s-p-o tuples is rdf:asserts or rdf:reifies). Any such dependency, if
> needed, can be implemented by users using custom properties and/or classes
> that are outside of RDF1.2.
>
> Finally, given the pushback I am seeing for the two-property approach, I think
> it is okay to go with the single-property approach (because I do expect that
> most RDF graphs in practice will contain only one kind of id-s-p-o tuples).
> However, keeping in mind the one-to-one connotation of rdf:reifies and its
> perceived complexity among (a significant chunk of) potential users of RDF1.2,
> I'd like the group to consider an alternate like rdf:hasTriple.
>
> Thanks,
> Souri.
>
> [1] urldefense.com
https://urldefense.com/v3/__https://lists.w3.org/Archives/Public/public-rdf-star-wg/2024Aug/0077.html__;!!ACWV5N9M2RV99hQ!ItvPTIiSyrTIl8AjjFjNckOMwtkcB-Dw8mO6Zm0yLwoBflqGJQtb3xMkK
> < https://urldefense.com/v3/__https://lists.w3.org/Archives/Public/public-rdf-star-wg/2024Aug/0077.html__;!!ACWV5N9M2RV99hQ!ItvPTIiSyrTIl8AjjFjNckOMwtkcB-Dw8mO6Zm0yLwoBflqGJQtb3xMkKv >
> [2] urldefense.com
https://urldefense.com/v3/__https://lists.w3.org/Archives/Public/public-rdf-star-wg/2024Aug/0081.html__;!!ACWV5N9M2RV99hQ!ItvPTIiSyrTIl8AjjFjNckOMwtkcB-Dw8mO6Zm0yLwoBflqGJQtb3xMkK
> < https://urldefense.com/v3/__https://lists.w3.org/Archives/Public/public-rdf-star-wg/2024Aug/0081.html__;!!ACWV5N9M2RV99hQ!ItvPTIiSyrTIl8AjjFjNckOMwtkcB-Dw8mO6Zm0yLwoBflqGJQtb3xMkKv >
> ------------------------------------------------------------------------------
> *From:* Peter F. Patel-Schneider <pfpschneider@gmail.com>
> *Sent:* Saturday, August 17, 2024 1:12 PM
> *To:* public-rdf-star-wg@w3.org <public-rdf-star-wg@w3.org>
> *Subject:* Re: [External] : example showing why rdf:state is essential
> I support the comments of Gregg Kellogg and provide the following extra
> information on this stance on triple terms and reification.
>
>
> I found the original pair of examples completely unconvincing. The first
> example has four different rdf:reifies triples provding nothing about
> provenance or assertive force. But even if these triples were added, for
> example via
>
> :stint1 prov:source :workhistory .
> :stint1 prov:reliability :high .
> ...
> :stint4 prov:source :alice .
> :stint4 prov:reliability :low .
>
> there is nothing to say that :stint4 is in any way asserting anything just
> because the triple it reifies is present in the graph. To say otherwise is a
> complete misreading of the meaning of rdf:reifies, which was only created to
> provide an RDF-blessed predicate for the nearly-always-required-standoff when
> using triple triples.
>
> Using a second predicate that has no semantics does nothing to change the
> situation. Changing the name from rdf:reifies also does nothing to change the
> situation. The proposed rdf:id oes have the unfortunate connotation of being
> an identifier, which clashes with the many-to-many characteristic of rdf:reifies.
>
> Adding assertional force information to provenance nodes *does* provide
> information about which provenance node supports the presence of triple in the
> graph whether this is done via a property like prov:reliability or a class
> like prov:Unreliable.
>
>
> None of this affects the baseline, which does not touch on provenance or
> assertional force.
>
>
> peter
>
Received on Tuesday, 20 August 2024 10:04:04 UTC