Meeting minutes
<gb> Issue 156 Addressing SPARQL EXISTS errata (by afs) [discuss-f2f] [needs discussion]
<gb> Issue 128 map the annotation syntax to `rdfs:states` (by rat10) [discuss-f2f]
<gb> Issue 130 vocabulary to refer to the individual nodes in a triple term (by rat10) [discuss-f2f]
<gb> Issue 49 Define an interpretation of Triple Terms (by niklasl) [discuss-f2f] [needs discussion]
<pchampin> gb, ignore agendabot
ora: reminder, we apply our new way of working, using the issues list as a back log and bring issues up for our discussion
… during the admin meeting we do a reprio of the issues as needed
ktk: we continue the f2f backlog for now
Addressing SPARQL EXISTS errata & vote 1
ora: see email from James anderson on the topic
ora: james, can you summarize your concerns?
james: had corresponded with chairs to raise an issue, the suggested to post a comment on the ticket
… I did not do that, rather sent a note to the list
… summary of the note is: this group is not chartered to address the issue
… the group is very hard to try address what it is charted to do
<pchampin> James's email
james: the work on exists goes back many years
… was never supposed as something of significant level of maturity to get into a RECOMMENDATION
… this and other things should be considered with other topics together. The exists topic is not mature enough to discuss
… happy to discuss this but not on technical terms, because I believe this is not the place to do that
ora: one can argue that this is not just errata
… so it would make sense that this does not belong to our charter
james: given the scope this is not an errata
ktk: my technical estimate is that this is not editorial errata
pfps: looking up the charter
<AndyS> s/adrian:/james:/
pfps: I believe we cannot rule this out, looking at the charter
james: the paragraph then say: might consider rechartering
AndyS: there have been a number of problems identified, it only depends on the weight you give to things
tl: I read various comments, they seemed to suggest that this is a big discussion
… not only relevant to EXIST but to some other problems, not a quick fix
… other people who participated in the discussion are not here at the table
tpt: agree, we lack expertise
… would another w3c group would get more competent people on this topic
… if not, we are the best group to address this
… the topic is not about adding new features but to make explicit what is currently undefined in the sparql spec
<pfps> The paragraph in question is ambiguous. "This" might refer to addressing any non-editorial errata but it also might refer to integration into other documents.
pfps: the charter is ambiguous
(see the note above)
ktk: replying to thomas, Hannah Bast wants to fix the semantics of sparql exists, which were not thought through
… she thinks that this should not be mixed with extending SPARQL
… Hannah Bast, from Qlever, was excited about us discussing this, i.e. clarifying the current definition
gkellogg: WG can revise topics according to three different categories
gkellogg: if this is an erratum that is an substantive change, it is on scope for this WG
… since we have custody for this document
… lack of the expertise in the WG shows that people how have the expertise to work on exist, are not as compelled by rdf star changes
… it is very unlikely that another group will be chartered to fix exist, while this group is working
pchampin: the charter should not push for substantive changes but should also not prevent addressing substantive errata
… agree that there is ambiguity in the statement, but that was the spirit of the charter
… proposal on the table is not to make a substantive change but to make the exist definition clearer
… I am not a sparql expert either, but this is how I interpret the discussion
TallTed: a substantive change is variably defined
… in many groups I have been involved, this would could as both substantive and editorial
… intend is to document something more clearly, to remove ambiguities
… none of the changes would render an existing implementation non compliant
james: not true
TallTed: ok, then I misunderstood something
… it still does not rule out making the changes
james: the intent of what andy has done and of the CG that existed was to eliminate divergence that implementations make
… if we focus on one result, other implementations will be non complimant
… you then also end up with clearer conformance
… the issue is that other changes needed for sparql will need to be done and make it competitive
(discussion on the tone of the discussion)
<pchampin> the charter always said that the deliverables were RDF 1.2 and SPARQL 1.2
james: if we want to do sparql 1.2, the WG should include other things that should be in 1.2
… this WG does not have the proper participants to do that
tl: response to thomas, I do not have the knowledge about sparql needed
… I understand why the sparql experts are not here
… so cannot see how we can be the venue to discuss this
… this is also what I read from Hana's comment in the issue tracker
ktk: please do not interpret why people are not here
… to james, we called the deliverable sparql 1.2, that is how it is
… about the experts, we have andy and four other people who know well about sparql, please do not say that we miss the expertise
<pfps> We also have a representative from RDFox in the working group.
pchampin: the group is chartered to make the next version of sparql
<fsasaki> +1 to adrian about the scope of the charter
<tl> 1. Scope
<tl> The scope of this Working Group is to extend the recommendations defining RDF 1.1 and SPARQL 1.1 with the features introduced by RDF-star.
<tl> https://
pchampin: everybody can then decide if they want to join the group
james: I was not a member then the name changed from rdf star to sparql 1.2
… as a non member I had no standing
<pchampin> there was never a change... this was part of the WG charter from day 1
<pfps> EXISTS has a clear definition in 1.1. The definition has strange characteristics, for example it results in invalid syntax. The definition also has some cases where it produces valid syntax but that part of the definition is (as far as I remember) differs from what every SPARQL implementation does. So as far as I know, no SPARQL implementation is compliant with the 1.1 definition of EXISTS.
james: if it would have been charter as a sparql 1.2 group, I would have harder to become a member
… there are many things that should happen in 1.2
AndyS: we have 7 implementations in this call already
… data graph has made suggestions to changes to sparql, which are not covered by this charter
pchampin: we did not make any changes of the charter, sparql 1.2. was in scope from the start
… you are right, there is now a long wishlist for sparql in the CG, sparql-dev
pchampin: once we start sparql 1.2 as a REC, we can now make more changes than to RECs in the past
… e.g. including new changes, since one can add new features with a lightweight process
… so there can be additional features once we are a REC
… but the first set of features will be errata and the rdf-star part
<Zakim> pfps, you wanted to comment that my remembrance is that scope is a question largely left to the chairs
pchampin: the idea was not to rule out other features of sparql 1.2, but allow them once we have 1.2 published
pfps: questions of scope are normally left to the chairs
… I suggest to leave this to the chairs
james: andy said that my suggestions would be beyond scope
… I agree, and I think they should be discussed with other groups
… and exist should be taken up for further evolution in other venues
… one should have a WG that move such topics forward
AndyS: the features I meant was changes to sparql that are not errata
james: the changes are related to rdf-star
AndyS: they go well beyond rdf-star
ora: agree with peter's suggestions that chairs pick this up, we go in circle
… I do not think that the sparl CG has been very active or has shown interest to work on future versions of sparql
… in that sense I think: we are it
… people like pavel may have expertise but may not be interested in participating in w3c work
… this is w3c, we follow up the w3c process
… I suggest we pick this up next tuesday in our chairs meeting
… I see nobody else picking this up, so I think I think we should handle this
james: that is why I wrote to the chairs initially
ora: yes, the discussion was useful in the group, and, the chairs will bring this up again
… we should table this and go to the next topic
Map the annotation syntax to rdfs:states 2
tl: I can present it, but would then suggest to postpone it
ora: use this slot to put a bug in our heads so that we think about it
tl: here are some slides from tpac about the topic
tl: suggestion is to map annotation syntax to rdf:states
… we have unasserted assertations use case , problem of reification itself, turtle star syntactic sugar
… and then the mapping to n-triples without round tripping
<pchampin> that's why it's called "syntactic sugar"
tl: I am proposing rdf:states to solve the issue
on "unasserted assertations", at tpac we learned about use cases like competing viewpoints and others
… competing viewpoints is not core semantic web but also not a niche case
tl: other type of use case is annotating qualifications
… rdf-star does not do that explicitly
… reification is not related
… on unasserted assertations, I had to learn that there are different intuitions
… I am not logic driven, unasserted always means not endorsed
… the annotation on that reified statement may reflect that
… I may for example want to describe a fact that I am opposed to
… if the same fact is added to the graph, it looks like endorsement
… that was driving my approach to have another property
… logic driven has its elegance, is simple, but it conflicts with my personal intuition
tl: there is also the property graph intiution
… PG edge exists, there is no may, may not etc.
… I take that too as a sign that we need something else besides reification
… that covers all qualification use cases that add details to a fact
… reification is a weak construct, it is on purpose weak since it makes problems with logic
… it does not meet what the syntax suggests
… entailment can provide a solid link
… it will make things very clear on the logic level
… but we do not have entailment on the ground level of the RDF
… on syntactic sugar, we have different types of syntactic sugar
<pchampin> simple entailment exists even at the "lower layer" of RDF
tl: in turtle star we have 2 syntactic sugar
… turtle star reflects the layman intuition
… there was nether a discussion about the annotation syntax, because it makes things very clear
… the statements exists and it is being annotated
… these two syntactic sugar constructs is what we really need
… everything else can go into annotations, extra vocabularies etc.
… that is not what we should do
… problem with the two syntax variants is that they do not round trip
… there is no way right now in the example to say "I will never endorse the triple" for one of two annotations in turtle
… let us assume a property called unstated
… if you query data, every query will need to check if a property was unstated. who wants to do that?
<william_vw> note that the reason that asserted are prevalent may be related to the fact that reification was wholly underspecified until now
<pfps> As I have stated in the issue, I see no argument here that would cause me to believe that rdf:states should be included in RDF, which, in my view, is a very simple formalism. If these facilities are wanted they should be in some extension of RDF or RDFS.
tl: as soon as you got competing view points there is an issue
<niklasl> :Foo :madeOf :Bar {| :rejectedBy :Alice |} . << :Bar :madeOf :Foo >> :believedBy :Bob . # ?
ora: thanks a lot for the presentation! It was a good summary of the topic
<pchampin> is this a topic for the Semantics TF tomorrow?
ora: just one remark, this sounds like adding a memory how the graph was constructed
… these things are missing from RDF
… can you share the slides?
tl: yes