Meeting minutes
Which parties carry what costs of text/turtle changes, and do those outweigh which benefits for whom? 1
rubensworks: summary
… consolidated propose form issue discussions
… 3 remaining issues
… There are two ways to specific the version protocol and in-document syntax
… should there be a requirement on one/other form
… second open question - scope of the VERSION keyword - applis after keword or whole document
… third - what about NT and NQ? which are line based.
gkellogg: NT/NQ. Not in favor of adding a keyword.
… various line based usages
… recognize that this has a downside
pchampin: Discuss the options on issue.
… for NQ/NT line count is not robust - e.g. have comments
… maybe @ form is grep friendly.
ktk: use case example - file upload in browser has no way to specific the version
pchampin: Pref version is SHOULD.
… modern parsers understand the directive- not sure what the would do different.
ora: do we want 1.,1 parsers to break on new content?
pchampin: I see this as making old parser break earlier and in a cleaner way.
andys: pref SHOULD bceause not always relevant
<niklasl> Yes, an old parser *will* break on triple term stuff. So this is for allowing (as as should) to breaking early (by "announcing").
<pchampin> to be clear, I expect a 1.2 parser to also break when it encounters "VERSION 1.3"
gkellogg: agree on SHOULD
… early break for older parsers
TallTed: don't want everyone (existing deployment) to be forced update if they don't use new features.
… what about bug fixes and errata?
… this is where MUST has use
ora: makes sense.
… should we explicitly use encourage use of VERSION?
rubensworks: would pref allow VERSION if no features in use.
<TallTed> interop (especially data exchange) is where things get extra interesting.
AndyS: I agree with Tpt's point, issue with streaming.
… Not keen of mandating the use of the keyword, it is expensive.
<TallTed> file splits would have to immediately precede a version declaration
AndyS: A SHOULD is an encouragement to use it, you should have reasons not to use it.
pchampin: think spec "SHOULD" is best
… best to make 1.1 if it is possible but not a MUST because of the cost in some situations.
… if this marker is there to break old parsers, could use at the point of use but that interacts with "fail early"
james: if the marker is to cause a failure, then a 1.1. marker, crashes a 1.1. parser.
<niklasl> +1 for discouraging `version 1.1`
gkellogg: Agree with james. Only becomes interesting at 1.3/2.0.
<pchampin> +1 gkellogg, "marking" a file as ≤1.1 amounts to put NO version marker
gkellogg: general case of serializing graphs, stream of triples so not known if 1.2 until a feature use is seen.
<pfps> +1 to gkellogg about not knowing whether there are 1.2 features until a long time into the serialization
gkellogg: adding at point of use is at the point of syntax failure anyway.
gtw: Benefit is a better error message.
james: Is there no way that to operate where the app says what to do.
AndyS: content-type parameter can be used with HTTP, it will be ignored if it is not recognized
… for the rest, we can't expect deployment to occurr at day 1 of RDF 1.2
ora: how to proceed?
… we need some kind of informative language to guide best practice.
AndyS: it is a good idea, but I'm not sure where this language should go
… rdf-new seems a good place, but it tends to be ignored
ora: could go in one spec (Turtle?)
… other point to that.
<TallTed> should be in new *and* in whichever serialization specs can carry it
gkellogg: needs to be each syntax spec. TriG does reference to Turtle.
… RDF/XML is also a syntax ... what about RDF 1.1 reifications
james: general description in graph store protocol?
ora: makes sense.
… more people read Turtle doc
gkellogg: a big change in how we layer information
<niklasl> I was +1 on turtle-syntax, but note also the section on concrete syntaxes in concepts: https://
<TallTed> rdf-new is fully informative, isn't it?
ora: we need a place for normative pieces.
tallted: put in each serialization
andys: Possible in RDF Concepts.
<TallTed> +1 appendix of concepts is a good idea. to which rdf-new should then also point. :-)
ora: key is one place and docs point to it.
… need to decide the normative bits.
pchampin: later discussion. Agree on principles now.
niklasl: appendix in concepts, maybe the basic/full section.
… this is about strict syntax not if the data has rdf:reifies triples.
ora: understand principles then normative pieces. Still some details to pin down.
… someone to write the informative piece?
gkellogg: I'll help
map the annotation syntax to rdfs:states 2
rubensworks: I'll help.
<niklasl> Specifically, an Accept: text/turtle;version=1.1 may trigger an application to turn data into RDF 1.2 Classic/Basic to be nice to the client parser (but thus also semantically lossy).
ktk: request to postpone because of late input
tl: agree
Task Force for SPARQL EXISTS 3
ora: Idea is to prepare for EXISTS - not a priority for the whole WG at this time.
… does the group agrees?
… who will chair?
<AndyS> s/agress/agree/
ora: james - would you chair this?
james: insufficient experience of W3C processes
ora: it involves scheduling and making the TF moves forward
gkellogg: Agree to TF and maybe other items in the WG for subsets of the participants
… creates a place for discussions. I would participate.
james: sub-group decide chair?
Andys: I can schedule a first meeting
<TallTed> TF(s) will let focused conversation(s) take place in parallel with main group without consuming main group time. I don't think I will have the time to do much if any more than participate (which I will *try* to do).
ktk: can external people participate?
<TallTed> TF participants must be WG members, whether as W3CMember reps or as IEs
james: certainly agree for external participants
pchampin: chairs can invite (and to WG meetings)
… need to check if a member org can specific a person outside of their org.
<TallTed> IP issues can quickly become quite hairy.
tallted: depends on their input (IP issues need care)
… if they are contributing significantly, should do the IP side.
ora: adjourned