Meeting minutes
Scribe: Gschwend, Adrian (alternate: Pellissier Tanon, Thomas)
Approval of last week's & TPAC minutes: 1
<AndyS> Last time: https://
ktk: Minutes from last week https://
<ktk> https://
<ktk> PROPOSAL: Approve last week's minutes
<gkellogg> +1
<olaf> +1
<ktk> +1
<Dominik_T> 1+
<gtw> +1
<TallTed> +1
<enrico> +1
<AZ> +0 (was not present)
<AndyS> +1
<Souri> +1
RESOLUTION: Approve last week's minutes
ktk: Minutes from TPAC https://
… pchampin applied the fixes.
<ktk> PROPOSAL: Approve minutes 2023-09-12
<gkellogg> +1
<Dominik_T> +1
<ktk> +1
<AndyS> +1
<ora> +1
<Tpt> +1
<gtw> +1
<AZ> +1
<TallTed> +1
<olaf> +1
<enrico> +1
RESOLUTION: Approve minutes 2023-09-12
Review of open actions, available at https://github.com/orgs/w3c/projects/20/views/3
<ktk> https://
close #85
<gb> Closed action #85
#86
<gb> Action 86 Follow up to persons concerned regarding SPARQL EXISTS (on afs, pfps) due 2023-09-19
ktk: pfps seems to have completed this item. I also sent to Pavel.
close #86
<gb> Closed action #86
pfps: pchampin completed work for #92
<gb> Action 92 email where section headings should go (on pfps) due 2023-09-28
close #92
<gb> Closed action #92
pfps: Last week's meeting's scribe should have been me.
… (it is correct, sorry)
close #93
<gb> Closed action #93
#19
<gb> Action 19 work with antoine and others to come up with a proposal for weak and strong compliance (on Antoine-Zimmermann, rdfguy)
az: I'm not sure how to move forward with this.
ora: I'm not sure what we should do next, We need some statement about compliance.
… I suggest everyone review this issue and review for next week.
… az and I will go and clean up the comments.
az: Reading the whole thread would not be productive.
az: I'll work on cleaning this up.
ktk: Please send out an email when it's ready for review.
Review of pull requests, available at https://github.com/orgs/w3c/projects/20/views/4
<ktk> https://
w3c/rdf-concepts#48
<gb> Pull Request 48 Add base direction as a fourth element of literals. (by gkellogg) [i18n-tracker] [needs discussion]
TallTed: I have a comment-in-process on rdf-concepts#48. I think there should be a better way to present 2, 3, or four elements and the structure isn't quite clean enough.
Related is w3c/rdf-n-triples#34.
<gb> Pull Request 34 Adds BNF and text to extend LANGTAG to support base direction (by gkellogg) [spec:substantive]
pfps: Is the datatype required of all RDF implementations.
<gb> Pull Request 48 Add base direction as a fourth element of literals. (by gkellogg) [i18n-tracker] [needs discussion]
gkellogg: I think so.
… Eventually, should go in what's new in RDF 1.2 but now is in changes since 1.1.
pfps: Someone at some point should make sure this is correct.
ktk: Proposal is to accept the two PRs barring last minute editorial changes.
PROPOSAL: Add base direction as a fourth element of Literals, relating to w3c/rdf-concepts#48 and w3c/rdf-n-triples#34.
<gb> Pull Request 48 Add base direction as a fourth element of literals. (by gkellogg) [i18n-tracker] [needs discussion]
gkellogg> +1
<AZ> +1
<pfps> 0 - I still worry that this is neither necessary nor sufficient but it is "mostly harmless"
<ktk> +1
<AndyS> +1
<ora> +1
<TallTed> +1
<olaf> +1
<gtw> +1
<Tpt> +1
TallTed: Please, let's give w3c/rdf-concepts#48 until next week for editorial time.
<Dominik_T> +1
<enrico> +1
<Souri> +0 - I have to study it more carefully
RESOLUTION: Add base direction as a forth element of Literals, relating to w3c/rdf-concepts#48 and w3c/rdf-n-triples#34.
<gb> Pull Request 34 Adds BNF and text to extend LANGTAG to support base direction (by gkellogg) [spec:substantive]
<gb> Pull Request 48 Add base direction as a fourth element of literals. (by gkellogg) [i18n-tracker] [needs discussion]
ktk: You can always open something new on this.
ktk: Some of the editorial PRs have been there for two weeks, and should probably just be merged.
… w3c/rdf-turtle#39
<gb> Pull Request 39 Unicode terminology and representation updates. (by gkellogg) [spec:editorial]
gkellogg: I think we might want to come back on this in a subsequent PR
TallTed: I want to make it as clear as possible for new people.
gkellogg: Maybe use character with a tool-tip and link to a definition.
TallTed: Multiple characters that roughly look the same can be a problem for non-english natives.
gkellogg: suggest we merged.
<pfps> Similar characters can also be a problem for English natives - they don't even need to be all that similar.
w3c/rdf-schema#27
<gb> CLOSED Pull Request 27 added rdf:JSON datatype (by domel) [spec:editorial]
ktk: This can be merged.
w3c/sparql-query#123
<gb> Pull Request 123 Fixes the definition of the Flatten function (by hartig) [spec:editorial]
olaf: I wanted to bring this one up for attention.
w3c/sparql-query#124
<gb> Pull Request 124 Improves the section about the Sum set function (by hartig) [spec:editorial]
olaf: This is an in-progress proposal that I'd like feedback on.
… If other co-editors can have a look, I'll make changes to similar functions (MIN, MAX, ...)
w3c/sparql-query#110
<gb> Pull Request 110 WIP: introduces a function called multiplicity to replace card[Ω](μ) (by hartig)
olaf: Please, if editors can also look at this proposal, I'll need to do more edits, but want to be sure it's generally acceptable.
w3c/rdf-concepts#66
<gb> Pull Request 66 Updates rdf:JSON value space. (by gkellogg) [spec:substantive]
AndyS: It might be helpful if we could see what the differences are in effect.
… Particularly comparing how canonicalization works.
<ktk> niklasl: can you present plus?
AndyS: I don't think we've seen what the effect would actually be and what the tradeoffs are.
<Dominik_T> I-JSON https://
AndyS: I-JSON focuses on the JSON that processors agree on, rather than a flawed original representation.
gkellogg: I'm not aware of any thing currently depending on the details of the value space.
<Zakim> pfps, you wanted to commment on the lexical space
pfps: My worry is that the value space will change, which is significant. It will change in a restrictive way.
… I also worry that the value space of I-JSON is not properly defined.
Semantics feedback
ktk: I was at Semantics in Leipzig, which was interesting due to the interest in RDF-star.
… There was some interest from Thomas Loertch who looked me up.
… Dydra is becoming a W3C member and he plans to join the WG.
… I assume he'll join via Dydra.
… I also talked with another company that does a lot of work on exporting RDF to Neo4J.
… They read some papers and have a lot of ideas.
… I encouraged them to read the use cases and contact me or others as we're really interested in real-world applications
… It was great to see people come up, it demonstrates interest in the community.
Issue Triage, available at
<ktk> https://
AndyS: If we're doing a two week cycle on technical vs process, can we be sure what the topic is going to be for next week?
… I'm happy for the chairs to choose the topic, but I want to be able to read the background material.
ktk: Noted.
close #54
<gb> Closed issue #54
ktk: we should remove the "duscuss-f2f" from those issues.
AndyS: The Echidna issue was paused due to random errors.
<gb> Issue 55 Compare language tags after normalizing to lower case. (by gkellogg) [discuss-f2f] [needs discussion] [spec:enhancement]
<pfps> at some time all issues need to be resolved so it is useful to have them all in a list somewhere
w3c/rdf-concepts#55
AndyS: It's also a normalization case.
… I emailed the Jena users list for feedback.
… There are people for whom it's important.
… Important is how to normalize
gkellogg: There's a question on how many triples get added to a graph.
AndyS: If we're going to do it, we should choose a normalization form.
… A processor would place the literal into normalized form.
ktk: Let's follow up on the issue.
Any Other Business (AOB), time permitting
ktk: is there a semantics TF tomorrow?
<ora> Thanks Adrian for chairing and Gregg for scribing.
enrico: Yes, I'll send out the update.
<AZ> bye