Meeting minutes
RDF 1.2 Semantics document review 1
ora: Thoughts on the semantics document?
pfps: Not many comments. The interpolation lemma remains to be proved. We probably shouldn't move before that.
… This document also depends on Concepts, which should ve considered for advancement as well.
… We could conditionally advance Semantics w/o the interpolation lemma.
ora: How close are we re. Concepts?
AndyS: The SemTF also discussed that there needs to be tests before advancing semantics.
… I also thought we'd need Concepts and possibly N-triples prior to Semantics
<Zakim> pfps, you wanted to talk about Concepts
pfps: Re. Concepts - it seems to normatively depend on every surface syntax. That seems unlikely.
… There is also the blocker re. rdf:JSON on Concepts.
ora: What is needed to accept a fix?
<Zakim> AndyS, you wanted to ask about dependencies of Concepts on syntaxes
pfps: There is disagreement re. where external datatypes should be defined [?]
… There's a section for normative references in Concepts. It seems unlikely that there are normative sections in Concepts that uses N-Quads; or even Turtle.
AndyS: There is mention of them, but probably a normative dependency.
pfps: But they listed in the normative sections.
gkellogg: Syntaxes appear as examples in conformant sections, but references should be informative.
<pfps> The issue for rdf:JSON is w3c/
<gb> Issue 116 rdf:JSON value space incorrect (by pfps) [ms:CR] [spec:bug]
gkellogg: The easy fix is to make references informative (use a question mark before)
ora: So the rdf:JSON issue is the only blocker?
pfps: No, 23 issues are open on Concepts.
… We could to a review on concepts.
ora: Can people take a look at the rdf:JSON issue and make up their minds?
gkellogg: The points of disagreement appears to be in the use of INFRA maps for describing JSON objects (regarding order and equality).
<Zakim> pfps, you wanted to talk about RDF datatypes
pfps: I disagree. For an RDF datatype you need a value space. the values space for JSON does not include ordered maps. So for definitions you have to be super-picky about definitions.
… This can be fixed by a short definition of unordered maps
gkellogg: And INFRA maps are ordered, so we would go against that by defining our own maps.
… My point is to point out what the contention is. It would be good for other members to chime in here.
… My own position is to stick with the INFRA definition of maps, which is ordered.
<pfps> in the end the value space for rdf:JSON MUST include unordered maps and MUST NOT include ordered maps
ora: So either define our own map to use, or use INFRA maps (but say "we don't think of them as ordered")?
<pfps> they can include equivalence classes of ordered maps under an equivalence relation that makes two maps equivalent if they differ only in order
ora: Both seem to require new definitional language IIUC.
gkellogg: There is language in there now to get around the fact that INFRA maps are ordered. We may need more language around that.
… Many other W3C specs use INFRA. We would be at odds with that if we deviate.
… More opinions are needed.
tpt: Definitions should be unordered, since JavaScript objects are unordered.
… JSON-LD refers to JSON C14N.
<Tpt> link: https://
<AndyS> Semantics has a normative reference to Turtle 1.1
ora: Make this a point of discussion in two weeks?
olaf: I'm more on pfps' side, for a cleaner definition. But I am fine with anything that moves us forward.
ora: Anything else on the Semantic spec?
AndyS: A reference to Turtle 1.1....
gkellogg: More editorial things; some section [3?] may be turned informative
… acknowledgements for RDF 1.2, and other editorial things.
pfps: We need to normatively define what a semantic extension is (re. section 3)
gkellogg: See the common subdirectory (from rdf-common)
Everybody: check the spelling of your names in rdf-common (and W3C profile) ;)
pfps: There is a good pointer (from enrico) for working on the interpolation lemma
Streamline Turtle-star syntactic sugar and future-proof it for graphs 2
ora: So, for Semantics, some editorial and interpolation lemma work, and next time [in two weeks] we'll discuss rdf:JSON
tl: A summary posted today. I think my proposal still stands. Syntactic issues appears resolved. Last one is minor, can be used with required blank space.
… It's about illegal in an IRI but legal in Turtle/SPARQL
… If you see a star, that's something about an annotation.
… I would like to get rid of the curly braces, as it is reserved for graphs.
… The star is nicely visible.
<tl> w3c/
<gb> Issue 131 Streamline Turtle-star syntactic sugar and future-proof it for graphs (by rat10) [needs discussion]
tl: See the initial comment.
… James had another proposal, closer to what we have now, but get's rid of the curly braces. Not as distruptive.
<TallTed> w3c/
(link to summary)
<pfps> I looked at some papers by Jos and they all say Jos De Roo, so this should be changed.
james: My intent is to understand what a simpler alternative could be.
… the chevron and the chevron+parenthesis seems to have led to confusion. The LLM I asked concluded the same thing.
… Would preclude fewer things in the future, and I would prefer fewer tokens.
… and align the annotation block with those.
… I understand the star preference but wonder if that visual prominence is necessary.
pfps: Re. the angles vs. the curly braces. They bracket different things. So it's not helpful to make them more visually similar.
… People might end up putting brackets for annotations around triples.
… I don't like two charactes as token, but it is reasonably warranted here.
… The three-character syntax is discouraging, which we want; we discourage its use.
… I think what we have is viable and doesn't break too many possibilities.
I agree with pfps that annotation syntax is too different from triple forms for them to benefit much from the use of similar delimiters (I think it would even make them harder to distinguish).
niklasl: I'm symphatetic with the issue that curly braces might be problematic. They are not solely used for graph purposes in SPARQL. They are mostly used for triple groups of various form. For graphs, you need to use the GRAPH keyword. They are also used for OPTIONAL and VALUES.
… so it's not the strongest of arguments that they are reserved for graphs.
… Also with Notation-3, that's not really aligned with SPARQL anyway.
… Using blank node brackets makes it hard to distinct annotations with blank nodes.
… I don't see a problem with the current syntax, I'm used it it after using them in the past years.
… Given how hard it is to come to an agreement and avoid all the various collisions and pitfalls, I think what we have now is validated for many years and it works. There is no collision.
ora: And we won't have evidence on parser ambiguity.
tl: My proposal is for square-bracket + star, so it is different from triple terms.
<ktk> s/I agree with pfps that annotation syntax is too different from triple forms for them to benefit much from the use of similar delimiters (I think it would even make them harder to distinguish).
tl: people mix these things and should have cut down the options; but we're past that.
… I still think my proposal is best.
AndyS: I agree with pfps summary. I particularly don't like open angle brackets for annotation blocks. It's not a term.
… I don't think the summary reflects the thread. Such as regarding SPARQL.
… JSON also uses curly braces for other things.
ora: I don't sense strong support for the proposal to change syntax.
tl: I support a vote and wouldn't vote a strong plus/minus one.
gkellogg: I think we need a vote; there's been a lot of testing; changes would be disruptive.
… Any character within ASCII does run into issues. Unless we use emojis there are no perfect solutions.
<ora> PROPOSAL: Adopt Thomas' proposal on syntax change
<tl> +1
<pfps> -0.9
<doerthe> 0
<gkellogg> -0.5
<enrico> 0
<james> 0
<ora> -0.9
<gtw> -0.9
<niklasl> -0.9
<Souri> -0.5
<ktk> -0.5
<Tpt> -0.8
<olaf> -0.5
<TallTed> -0.8
<AndyS> -0.99
<eBremer> -0.3
RESOLUTION: We will not adopt Thomas' proposal on syntax change
Addressing SPARQL EXISTS errata 3
ora: This will be a meta-discussion on whether we're going pursuing a solution.
<pfps> +1 to adrian
ktk: I propose to not talk about this unless we're really done on all RDF-star things on all required documents
<niklasl> +1
<tl> +1
james: I agree with this. This is not the time to do it.
tpt: It seems to me we already have a strong proposal. Hence, this might not be a real distraction.
AndyS: It has been on the query issues list for a long time, and discussed it on TPAC. We can make more progress on the list and on github.
… My discomfort is the suggestion for people to focus on particular issues. In a WG that's not a management's role.
ora: But prioritization is.
AndyS: Absolutely.
james: If the chairs decide that other things come first, why does that require people to work on specific things?
AndyS: We can do things in sequence, but objecting to do the SPARQL thing (as out of scope) I disagree with.
tpt: Errata is allowed in the Charter and this has been in the errata on SPARQL for quite some time.
ktk: My proposal is only to move forward with the rest, not to discourage further work on resolving this.
<AndyS> w3c/
<gb> Pull Request 177 Definitions for Values Insertion (by afs)
tpt: Makes sense. We prioritize getting the RDF specs done, and then do this on top.
ktk: No objections to that.
ora: So is it OK to consider this a prioritization, not about resource allocation.
AndyS: yes
TallTed: This seems ripe for a Task Force, which can work with this and then present this to the wider group.
james: I concur with that suggestion. I would very much like to resolve this; it is a deficiency in SPARQL. My objection is that it involves more than EXISTS and would require more time.
<Tpt> And there is the follow up https://
ora: Next time we can discuss the formation of this Task Force.
AndyS: I just point to the PR. The SPARQL EXISTS CG did not publish anything, so we could not peruse that here.
… I've put material into the PR to make it legal for this WG to use.