Meeting minutes
<jbollema> hi
<ora> I will not volunteer as a scribe because I know that Zakim prefers me anyway in the lottery. ;-)
Announcement
pchampin: no newcomers
… and no announcements
Open actions
<pchampin> https://
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://
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://
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
Bye!