Meeting minutes
Approval of minutes from the last two meetings:
<ktk> PROPOSAL: Approve minutes 2023-11-02
<eBremer> im not listed as present last time
<ora> +1
<ktk> +1
<gkellogg> +1
<rubensworks> +1
<olaf> +1
+1
<enrico> +1
<niklasl> +0 (was not present)
<TallTed> +1
<tl> +1
<pchampin> +1
<fsasaki> +1
RESOLUTION: Approve minutes 2023-11-02, https://
<ktk> PROPOSAL: Approve minutes 2023-11-16
<niklasl> +1
+1
<olaf> +1
<gtw> +1
<Souri> +0.5 (present only during the first half)
<tl> +1
<ora> +1
<rubensworks> +1
<TallTed> +1
<ktk> +0 (not present)
<enrico> +1
<gkellogg> +1
<pchampin> +1
RESOLUTION: Approve minutes 2023-11-16, https://
Proposal for next week's discussion
ora: I was lost after the last discussion. Not sure what to do next. I discussed with Adrian. We strongly suggest that we select a course that leads to completion of the work in the expected time
ora: but without closing door
ktk: Regarding Thomas' mail, I propose that we try to get into a clear direction. I do not want to open more doors. We should have something ready in summer next year
ktk: we can extend on that afterwards
ktk: that is ora's and my proposal
ora: we do not want to dictate a solution, but we want to finish the charter
ktk: I was asked whether graphs are not allowed as a solution. The charter is on triple terms and we should discuss these first
fsasaki: I'd like to second that. I think a fast solution is important also to assure that RDF keeps competitive to other graph related approaches
TallTed: Even though the charter talks about triple terms, but it is possible for the working group to widen the scope. The charter is not binding in that way
tl: I can reduce nested graphs to nested triples. I would like to discuss the possible problems about graph terms. I am not convinced that they are that big. I would like to do that in seperate meeting
<pfps> I am totally unconvinced that using nested graphs is "for free". Where is the complete proposal for this?
tl: My plan was not to go hijack the group to solve the named graph issues, but I think that graphs and triples are related
TallTed: even though graphs and triples are similar froma philosophical point of view, they technically differ
ora: I would like people to think about which compromises they would accept to prepare for next week
<TallTed> +1 "can I live with this?" is a key question for each proposal
ora: do we all agree on that we want to talk about graph terms vs. triple terms and possible compromises next week?
ora: I really hope to reach a decision next week
<pchampin> +1 to AndyS
AndyS: could we make sure that all material is available long before the meeting (48h?)
gkellogg: I second that, especially having the time difference in mind
<olaf> s/AndaS:/AndyS:/
gkellogg: we should also think about how we deal with the Christmas break and how we do planning
<gkellogg> s/gKellogg:/gkellogg:/
tl: so we won't have the discussion about named graphs next week?
tl: I would like to have the discussion without pressure
ora: we could discuss through the mailing list and in the meeting
ora: I really want to reach a decision
ora: that includes that we take a decision as a group at some point
Review of open actions, available at
<ktk> https://
<pchampin> w3c/
<gb> Action 84 1.1 specs should reference 1.2 versions (on pchampin)
pchampin: I investigated on w3c/
pchampin: the links will be changed
pfps: I worked on updating the use cases. I worked on it and will continue today
<Zakim> pfps`, you wanted to talk about my aciton
Review of pull requests, available at
<ktk> https://
olaf: There is an open request w3c/sparql-query#132, will you have a look at it Andy?
AndyS: yes
<gb> Pull Request 132 More accurate definition of the Group operator (by hartig) [spec:editorial]
<AndyS> Apologies for my tardiness on query#132
<gb> Issue 132 [not found]
gkellogg: there is tests for text-direction in n-quads, turtle and trig I added, if there is no objection, I will merge
olaf: What do we do for SPARQL 1.2 tests? how do we proceed?
AndyS: are these tests for the repository?
AndyS: there is a directory for it which is empty, we can start to fill it. We can follow the structure of the old tests
olaf: do we add the old tests there as well?
AndyS: Only the new ones
gkellogg: what do we do with the tests from RDF-star Community Group
AndyS: these are premature, we should not add them now
AndyS: all tests need to be manually checked
ora: can we deprecate tests if needed?
gkellogg: I would add some tags, but from experience, that can cause confusion
niklasl: we should for sure add tests for the things we change
Issue Triage, available at
<ktk> https://
ora: how do we do the triage?
gkellogg: we wanted to focus on the tasks with "needs discussion" tags
w3c/sparql-results-csv-tsv#10
<gb> Issue 10 TSV: state how to handle special characters in strings (by Tpt) [needs discussion]
<pchampin> discovering this issue right now, but I tend to agree with AndyS
ACTION: AndyS to follow-up on on issue TSV#10
<gb> I created issue #10
<gb> but I could not add the "action" label.
<gb> That probably means I don't have push permission on w3c/rdf-common.
<gb> I created issue #11
<gb> but I could not add the "action" label.
<gb> That probably means I don't have push permission on w3c/rdf-common.
AndyS: I will have a look at the issue
<gkellogg> Now in w3c/
<gb> Action 98 follow-up on on issue TSV#10 (on ) due 2023-12-07
w3c/rdf-concepts#55
<gb> Issue 55 Compare language tags after normalizing to lower case. (by gkellogg) [needs discussion] [spec:enhancement]
gkellogg: the issue is that language tags can be done differently by different implementations
<Souri> In Oracle, we lowercase it.
ora: do we know what the major implementations do with the issue
gkellogg: we do not need to fix that in the abstract syntax
AndyS: does that not break canonicalization?
gkellogg: yes it would
<AndyS> Ontotext GraphDB uses RFC formatting.
gkellogg: we could leave it open for serialisations and fix it in the abstract syntax
ora: Are the issues about comparisons or storage?
gkellogg: comparison is case-insensitve
AndyS: we could say within a concrete system the representation should be consistent
pchampin: I wanted to suggest the same as Andy just did. We should only say that two literals only differing in lower vs. upper case letters in their language tags should be the same without dictating what this needs to be
pchampin: we can add that there can be a canonical case
tl: I would like to have a semantic task force
<TallTed> tomorrow currently shows as cancelled. but I will join if it happens. https://
enrico: If you want, we can have a meeting. I wanted to write a very concise proposal as well covering the minimal requirements
enrico: I want to propose two possibilities, we could discuss
enrico: I can de-cancel tomorrow's meeting
<doerthe> not sure, I can join tomorrow
<gb> Created action #99