Meeting minutes
Some improved language, punctuation, and markup in rdf-semantics 1
ktk: let's start. Ora might not be able to make it
… Ted's PR
pfps: mostly emdashes. emdashes neither necessary nor useful. as an editor i'm strongly against them
TallTed: feel strongly that they should be added. Not having them looks like something is forgotten
… some could be replaced by colons in some last places, but that requires a little rephrasing
pchampin: don't feel strongly either way, but am not a native speaker
… understand ted's point about consistent sentences
… just now looking at an example where i don't agree with Ted
gkellogg: in general in support of emdashes
… but code blocks in specs are by convention not enclosed in emdashes
AndyS: general advice seems to be that emdashes, should be used sparingly
TallTed: will rephrase my proposal since nobody except pfps and me seem to feel strongly about this
treatment of structures that are not RDF graphs 2
ktk: will have a look at it after ted's update
<pfps> is there a pointer to 68?
ktk: now issue 68
gkellogg: n-triples got merged since we last discussed it
<AndyS> w3c/
<gb> MERGED Pull Request 68 Add language to require that only valid IRIs ... (by gkellogg) [needs discussion] [spec:substantive] [test:needs tests]
<gkellogg> w3c/
pfps: apparently there are apps (eg syntax processors) that do not output RDF graphs. that seems weird
… seems like having an XML processor that doesn't output XML
pchampin: concur with Peter's concern, but there are exception, e.g. invalid input being allowed to be output again
<pfps> w3c/
<gb> Issue 170 treatment of structures that are not RDF graphs (by pfps) [duplicate] [needs discussion]
pchampin: although often some signals of error etc is required
andys: there is no test that outputs nonconformant RDF graphs
pfps: so there are no approved tests that mandate outputting non-RDF graphs?
andys: yes, not that i know of
pfps: that would make me very happy
gkellogg: positive syntax tests should arguably always be positive evaluation tests
… we should ship negative syntax test for illegal forms
pchampin: do we have evaluation tests for n-triples?
gkellogg: closest would be canonicalization tests
pchampin: if we add negative tests for corner cases, maybe we should distinguish "good" from "bad" tests
gkellogg: most formats have pretty precise EBNF grammars, but eg JSON-LD hasn't
… I think a finer distinction of negative tests is unnecessary
AndyS: we can't have negative evaluation test since we can't precisely say what the outcome should be
gkellogg: we could test if they spot some wrong syntax
AndyS: but then: error, warning, something else?
… risk of pushing too much of what people do as being not an RDF graph
pchampin: should be clear of what "negative syntax check" should be
… not necessarily need to reject
… signaling a problem without normatively saying anything, not requiring rejection, but still report an error if one is detected, leave details to implementors (whatever makes most sense in their application)
… "negative syntax test" very plainly can not mean requirement for rejection
gkellogg: sometimes people run "valid" tests
… even more important when generating RDF if you want to make sure you generate valid RDF
pchampin: example an n-triples parser accepts n-quads and throws away the graph name
… could that be compliant (with a signal/warning)
ktk: conclusion: do we have to extend the test, or not?
gkellogg: will generate a PR for negative syntax tests
<pchampin> +1 to create tests for these corner cases
ktk: pfps, is your issue resolved?
pfps: yes, and i will close the issue
What else is still needed for moving to CR? 3
AndyS: will put in a PR wrt n-triples about a behaviour i'm not happy with
AndyS: concepts issues 129 clarification abstract syntax and datamodel, issue#??? , issue # 116 rdf json
gkellogg: #89 in turtle - resolving IRIs needs to be figured out, also in n-triples
<gb> CLOSED Action 89 follow up to the persons concerned [4] (on pfps) due 2023-09-19
<AndyS> w3c/
<gb> Issue 129 Distinguish the RDF Data Model from the Abstract Syntax (by gkellogg) [ms:CR] [spec:substantive]
<AndyS> w3c/
<gb> Issue 92 identity and equality of datatype values (by pfps) [spec:editorial]
<AndyS> w3c/
<gb> Issue 116 rdf:JSON value space incorrect (by pfps) [ms:CR] [spec:bug]
ktk: andy, please tag the issues that you mentioned as "needs discussion"
<AndyS> w3c/
<gb> Issue 89 Different parsing of the same absolute IRI with or without base IRI (by Tpt) [ErratumRaised] [needs discussion]
pchampin: we need some things sorted out before we go to CR, but can we ask for horizontal review from other WGs already? the remaining issues don't seem to have the potential to completely change the course of the specs.
… question to the group: do you think there is teh danger of such issues that could completely change the direction? would it bad practice to ask for horizontal review now?
gkellogg: if we add markers for the issues that we think do need discussion before we get into CR
ktk: do we have such issues?
<AndyS> Souri --all are the TR/rdf12-* for concepts, n-triples, semantics.
pfps: semantics work has been delayed largely because of discussion of what annotation of statements means
… underlying semantics might have to be changed
… until that's clarified it doesn't make sense to finalize semantics
pchampin: so peter think big changes in semantics are still possible, right?
… horiziontal review involves TAG, security, privacy, internationalization
pfps: only TAG would be possibly affected
… also small changes can be very time consuming
pchampin: suggest to give ourselves a deadline to identify blocking issues, and address them in a coming meeting
ktk: call, or issue, to establish that list?
pchampin: CR labels in github issues
ktk: and then discuss those labels in a WG meeting
… maybe send out a mail to the list to ask for those labels
pchampin: and then discuss them in 2 weeks?
andys: what are the risk points wrt semantics?
pfps: two PRs about the connection of statements and annotations (one in concepts, one in semantics)
ktk: will send out an email on this list of issues blocking going to CR
Issue Triage, available at 4
<tl> s/taht/that
<ktk> https://
<ktk> w3c/
<gb> Issue 61 CSS changes reduce readability of documents (by pfps) [documentation] [propose closing]
<pfps> fine by me
ktk: propose to close this if i don't hear anything
<ktk> w3c/
<gb> Issue 103 what is the relation between reifiers and annotation blocks? (by lisp) [propose closing]
ktk: proposed closing three weeks ago, no comments
<pfps> close it
ktk: closed
<Dominik_T> rrsagent, please draft the minutes
<ktk> s/test if they spot soem wrong syntax/test if they spot some wrong syntax/