14 May 2021


AndyS, gkellogg, james, jbollema, olaf, ora, pchampin, rivettp, TallTed, thomas
AndyS, olaf, pchampin

Meeting minutes

<jbollema> hi

<ora> I will not volunteer as a scribe because I know that Zakim prefers me anyway in the lottery. ;-)


pchampin: no newcomers
… and no announcements

Open actions

<pchampin> https://github.com/w3c/rdf-star/issues?q=is%3Aopen+is%3Aissue+label%3Aaction

pchampin: unfortunately, didn't find much time to work on open actions
… about 166, deferred to today
… 168 (charter) no progress because of work on another charter (signatures)
… learned a lot during this process, which may come useful for working on our charter
… action about service descriptions, no progress here either
… we may discuss relevant IRIs to be defined
… which means we need our own namespace
… which may then contain all these IRIs
… another option may be to leave this open for the potential WG to make a decision

gkellogg: we should record the issues/direction in sections now
… because the start of a WG may need a long time
… and things may become forgotten

thomas: about example "has occurrence" - that hasn't been discussed
… better leave it out because it hasn't been discussed
… or define a property for it because it is an important use case

pchampin: yes, defining such property may make sense

thomas: on the other hand, it's incomplete
… because there would be no way to state where the occurrence is
… or we may add vocabulary for that too

pchampin: makes sense, please create an issue
… last action: create outstanding issues list
… did some clean up
… in github
… but didn't remove any open issues in github

<pchampin> https://github.com/w3c/rdf-star/issues/121

pchampin: things that really need to be done before the final report: #121
… Andy has text that may be included here
… (this text is in the github issue)
… additionally, the intro section needs to be tidied up
… RDF-star vocab may wait

<AndyS> Sounds good.

olaf: sounds good for me too

pchampin: everyone should look at the open issues in github
… and see whether they find some of these important enough

Action: everyone to check in the issues if they believe one of the need to be addressed before "final report"

AndyS: merged a text in the doc
… regarding comparison for SPARQL
… that should be added

idea: define it recursively
… first for S, then P, then O

jbollema: regarding #121
… embedded triples should be last in the comparison order
… because it allows for a slight optimization if the data is organized in a specific way

<AndyS> Assign it to me.

Action: AndyS to make a PR for issue 121

james: symmetry should not be applied
… (#121)

<rivettp> question: regarding action 1, HOW should we indicate issues that we think should be addressed?

AndyS: think james misread
… sameTerms is equals but not the other way around

james: will review it again

pchampin: the PR will be subject to review as well, of course

pchampin: anything else?

pchampin: none

<AndyS> james - [[ "A = B" is defaults to "sameTerm(A,B)" as it does for URIs. ]] is only stating SPARQL normal for "=". Can you suggest better text?

Referential opacity/transperency of embedded triples

thomas: wrote some emails
… hope everyone read them
… 5 sec summary may be difficult

pchampin: stepped back
… this group is not an official WG
… acting as a chair and editor is tricky here
… became less convinced about the current solution
… although it is still the best option on the table
… it's not constructive to repeat arguments again and again

pchamin: disappointed that the 2nd strawpoll attracted little participation
… didn't want to seem biased by invoking a 6-months old strawpoll as an argument
… unfortunately, the new strawpoll has muddied the waters more than cleared it

thomas: strawpoll is not binding, right?

pchampin: right - we are not a WG

olaf: I didn't manage to read the long email, unfortunately.
… I skimmed it. I am not totally agains moving towards a transparent semantics.
… But I consider the opaque semantics as a better building block.
… It allows to add "local transparecy" for dedicated properties.
… I can't see how it could work the other way.
… You were not convinced by my arguments; that might have been because I was targetting James' question.
… It was modelled with SPARQL, but can be modelled otherwise.

thomas: strong feeling against attaching it to specific properties.
… This is not how the semantic web works at the moment.
… I understand that SPARQL is not the issue here, but I still find this solution too complex.
… It is not how people use RDF.

olaf: I would like to see more concrete use cases which you think might not be possible.

thomas: everything does not work. This is not the way RDF-star is adverstised.
… The SemWeb works in a transparent way. You can replace an identifier with another one.
… Switching in the middle of a sentence from transparency to opacity is confusing.
… Better to separate concerns, as proposed by Antoine Zimmermann: using literals for opacity.

olaf: you are making strong claims about how people use the Semantic Web.
… If someone says that A owl:sameAs B, you don't have to accept it.

gkellogg: I out of my depth on this discussion.

gkellogg: Peter had reasonable examples in his email
… such as the one about the Berlin population

pchampin: the problem is related; Peter's example shows something that can be confusing
… and we need to address that

AndyS: Peter's example highlights difference between denotation and entailment
… choice what to apply are local
… entailment is about adding extra believes
… local ontology comes into play
… Peter argues from a syntax point of view
… Also, it uses D-entailment

it uses the intuition that this entailment regime is usually considered as globally agreed upon
… which is different from other entailment regimes

jbollema: my understanding of opacity ...
… it is not permissive
… because a query engine must not use owl:sameAs for embedded triples

<pchampin> transparency is not "allowing", it is "mandating"

jbollema: second part, having to preserve syntactic form of embedded triples
… maybe a practical issue for systems
… it may prevent practical optimizations

AndyS: that#s what I mentioned in my message
… what you do locally is up to you
… the issue is that the reverse is not possible

pchampin: to Jerven's question ...
… semantic transparency is not just allowing it but mandating it
… that's "killing" some use cases
… e.g., provenance
… opacity is not as restrictive
… some things may require additional machinary
… but that's the same in RDF

thomas: that's a bad argument because we are not caring only about RDF

pchampin: saying that this breaks the SemWeb doesn't make sense either

thomas: I think I explained in my emails what exactly is breaking the SemWeb
… it is a feature if you can rely on what you get form something else

pchampin: yes but you can add

thomas: that#s dangerous

<jbollema> they are dangeling in sparql query behaviour

thomas: provenance example ship1 versus ship2

<jbollema> << :a :b :c >> ?x ?y would not be found << :d :b :c >> ?x ?y . even if :a owl:sameAs :d was added to the graph and reasoned about

AndyS: You make strong statements
… entailment is local but denotation is global

thomas: asking pchampin for the distinction between syntax and interpretation
… the problem wouldn't exist if we had an explicit identifier for the embedded triple

pchampin: it really depends on what you want to identify with an embedded triple -- a triple or a statement
… the triple itself is closer to the syntax and allows for more use cases

william: in N3 we have formulas which have ref.opacity
… for quoted graphs
… the reasons for choosing it this way is because it allows to add more things on top

<thomas> but its a different use case

william: in contrast to having ref.transparency

<thomas> because they stand for themselves

william: interpretation of cited formula may differ

<gkellogg> That’s a pretty convincing argument for defaul opacity.

william: ref.opacity is the building block that allows for this

STRAWPOLL: do we keep a referential opacity?

<gkellogg> +1

<william> +1

<olaf> +1

<pchampin> +1

<thomas> -1

<AndyS> +0.9

<james> -1

<ora> 0

<TallTed> +0.5

<jbollema> -1

<william> for those who are interested: http://ceur-ws.org/Vol-2438/paper6.pdf

pchampin: still hardly a consensus ... unfortunately
… we have to reflect this lack of consensus in the document

<ora> Good discussion

pchampin: other item on the agenda (mimetypes as propsoed by James') postponed to next week

<william> thanks!

<jbollema> bye


Summary of action items

  1. everyone to check in the issues if they believe one of the need to be addressed before "final report"
  2. AndyS to make a PR for issue 121
Minutes manually created (not a transcript), formatted by scribe.perl version 127 (Wed Dec 30 17:39:58 2020 UTC).