Re: against injective annotations - Re: RDF-star "baseline" with IRI opacity

My apologies for missing the previous meeting - I was in the midst of
moving at the time, and so had very limited availability.. I hope to
present on Peter's point at the next meeting, and have attached the
presentation below so that people have a chance to comment and critique at
that point.

I'm very much in agreement with Peter on single triple annotations. I'd
argue that most annotations are not in fact statements about individual
assertions but rather are clarifications of object state changes. This,
moreover, changes the dynamics of modelling.

For instance, (and this is the notation that I'm using in the presentation):

[ Marriage:m1 |
    Marriage:hasGroom Person:John ;
    Marriage:hasBride Person:Suzy ;
    Marriage:hasStartDate "1965" ;
    Marriage:hasEndDate "1974" ;
    Marriage:terminationReason MarriageTermination:Divorce ;
    Marriage:hasLocation Location:Westminster ]
         rdf:hasAnnotation
              [ Annotation:an101 |
                 Annotation:reportedBy [Publication:NYT |
                       rdfs:label "New York Times";
                       Publication:date "1965-08-01"]].

Here you are annotating the Marriage:m1 object.

Now, the argument can be made that this is not equivalent to

:John :marries :Suzy.

or, with classes made explicit:

Person:John Person:marries Person:Suzy.

and I would concur, but I'd also argue that the latter expression is fairly
lossy. This is where the current proposed reification notation actually
complexities things.

<< _:Marriage1 | :John :marries :suzy>> rdfs:hasAnnotation _:Ann1.

is the same as:

_:Marriage1
       rdf:s :John ;
       rdf:p :marries ;
       rdf:o :Suzy ;
       rdf:g :DefaultGroupIRI .
_:Marriage1 rdfs:hasAnnotation _:Ann1

or using Named Node Expressions (see the presentation)

[ _:Marriage1 | rdfs: John; rdf:p :marries; rdf:o :Suzy; rdf:g
:DefaultGroupIRI] rdfs:hasAnnotation _:Ann1 .



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


On Fri, Jun 14, 2024 at 8:01 AM Peter F. Patel-Schneider <
pfpschneider@gmail.com> wrote:

> It has been suggested in the previous version of the "baseline" that
> annotations should use a predicate that is injective, i.e., each
> annotation is
> for a single triple term.  But it is very common to want to provide
> provenance
> for not just one triple term but multiple triple terms at once.  Consider
> John
> married Suzy in Westminster as evidenced by the New York Times of Tuesday
> gathered by KRBOT on Wednesday.  Here the annotation is for the entire
> n-ary
> relationships John married Suzy in Westminster, not just for John married
> Suzy
> and not just for ... in Westminster. As in
>    _:b rdf:isAnnotationOf ( John married Suzy ) .
>    _:b rdf:isAnnotationOf ( ( John married Suzy ) in Westminster ) .
>    _:b :source _:nyt .
>    _:nyt :publication :NYT .
>    _:nyt :date Tuesday .
>    _:b :gathered _:krbot .
>    _:krbot :agent :KRBOT .
>    _:krbot :date Wednesday .
> So requiring annotations to be just for one triple term does not seem
> desirable.
>
> peter
>
>
> On 6/14/24 08:20, Franconi Enrico wrote:
> > Hi,
> > after the discussions last week arguing the non-intuitiveness of fully
> opaque
> > triple terms as literals, and after the comments that opaque tripe terms
> > should have transparent bnodes, I have prepared a new version of the
> baseline
> > document, where opaque triple terms have opaque IRIs and transparent
> bnodes:
> > https://github.com/w3c/rdf-star-wg/wiki/RDF-star-"baseline-with-IRI-opacity”
>
> > <https://github.com/w3c/rdf-star-wg/wiki/RDF-star-
> "baseline-with-IRI-opacity">
> > Note that annotations are not anymore functional with opaque triple
> terms
> > anymore, since it would make little sense with transparent bnodes in
> opaque
> > triple terms. Still, as I already discussed privately with some of you,
> even
> > without functionality we should still be able to capture the LPG use
> cases.
> > See you later,
> > —e.
>
>