Re: Tentative summary of today's Semantics TF meeting

> On 22. Dec 2023, at 18:10, Pierre-Antoine Champin <pierre-antoine@w3.org> wrote:
> 
> Hi everyone,
> 
> below is my attempt at summarizing the discussion we had today in the Semantics TF

Thank you for the nice summary!

> presents: Andy, Enrico, Niklas, Peter and myself

And sorry that I couldn’t make it!

> We started with a question from Andy:
> if :x is an occurrence of (:s :p :o) and :p is a subproperty of :q,
> should :x be considered an occurrence of (:s :q :o) ?
> -- similar questions could be asked, e.g. with (:s a :C), :C subclass of :D and (:s a :D)
> 
> The general consensus was that this should not be the case in general,
> but some consider that if :x is an occurrence of (:s :p :o) and :o owl:sameAs :o2,
> then :x should be considered an occurrence of (:s :p :o2).
> (referential transparency)

Two kinds of entailments - owl:sameAs vs all the rest - seems pretty daring. 
Would that general consensus mean that

    :Alice :buys :Sportscar {| :x | :in :2023 |}
    :Sportscar rdfs:subClassOf :Car .

would not entail

    :Alice :buys :Car {| :x | :in :2023 |}

That seems logical - it’s another statement, so it can’t be named :x as well - but also unsatisfying. IMO the following should hold:

    :Alice :buys :Car {| :xy | :in :2023 |}

I.e. a new occurrence mandates a new identifier, but apart from that annotations apply to entailed occurrences just the same. 


> Then we discussed whether triple terms and/or triple occurrences should be elements of the abstract syntax.
> My reading of Andy's proposal is that only triple terms are part of the abstract syntax, occurrences are arbitrary resources.
> Andy responded that he had not thought about it so deeply.
> Enrico presented his alternative abstract syntax + semantics where triple occurrences are part of the abstract syntax, and triple terms are absent [1] .
> 
> We discussed this for a while, coming to the conclusion that Enrico's proposal above and my proposal of an "RDFn" profile of Andy's proposal [2] were essentially achieving the same thing, each with its own kind of "bizarreness":
> * in Enrico's proposal, triple occurrences are bizarre terms, because they are acting like a new kind of statement ("naming statement"), and they are dependant on other terms (they denote the same thing as their first component, the name);

This reminds me of the semantics defined in the original Named Graphs proposal, Carroll et al 2005. 

And that made me wonder: why does Enrico’s formalization [1] describe triple occurrences in such detail, e.g.

    • <[I+A](ts.id), <[I+A](ts.s),[I+A](ts.p),[I+A](ts.o)>> ∈ IO
      if t.s is a tripleOccurrence ts

Why isn’t it sufficient to refer to the occurrence by its (iri|BlankNode) name? 


> * in PA's proposal, triple terms are bizarre terms because they can only be used with one predicate (rdf:occurrenceOf).

I was thinking about something like that too (also meeting Niklas’ concern about preventing people from annotating the type itself), but I’m returning to the same question again: does such little result really justify all the fuss with a new term type?


> Then we discussed about monotonicity and how "temporal annotations" (e.g. annotating a triple with start date and end date) could be misused. The conclusion was that this was to be addressed by schema/ontology designer, by clealy define under which condition the temporal annotations should be used. It is not to be addressed at the level of RDF itself, which is schema-less.

I fully agree. Sometimes I think we would have much less problems with freewheeling intuitions if RDF hadn’t that usability feature of self-describing infix properties, but vocabularies were designed as more sober prefix notations, e.g.

    :marriage( :Burton , :Taylor)

carries much less "intuitive" connotations and unfounded assumptions about now-ness etc than

    :Burton :marriedTo :Taylor .


Best,
Thomas


> [1] https://github.com/w3c/rdf-star-wg/wiki/Semantics:-Andy's-proposal
> [2] https://lists.w3.org/Archives/Public/public-rdf-star-wg/2023Dec/0076.html
> 
> <OpenPGP_0x9D1EDAEEEF98D438.asc>

Received on Friday, 29 December 2023 11:27:17 UTC