Meeting minutes
Approval of last week’s minutes: 1
<ora> PROPOSAL: Approve last week's minutes
<gtw> +1
<niklasl> +1
<ora> +1
<pfps> +1
<ktk> +1
<j22> +1
<AndyS> +1
<olaf> +1
<enrico> +1
<Souri> +1
<lisp> +1
RESOLUTION: Approve last week's minutes
CR Status
<TallTed> +1
ora: CR status. I thought I'd post on linkedin for attention. Looking for implementatino experience.
<ora> https://
ktk: Concepts and semantics are through. We will talk next about N-Triples.
… on hold from the TAG.
… linkedin post is good because abstract things are done.
ora: Working link to the N-Triples and other things.
… anybody opposed to my posting?
<Zakim> AndyS, you wanted to say that we haven't sorted out where impl reports should go to.
AndyS: I don't think we've said where to send implementation reports.
… not about your message.
… quick and dirty solution?
ora: yes. rdf-comments or something.
AndyS: raise a PR on rdf-tests.
… I think there's a directory.
… we could ask for PRs to the WG repo?
<niklasl> Cf. https://
TallTed: need to get replicated somehow.
AndyS: I was suggesting we have an inbox. Then we can sort out details as needed.
ora: could we ask to just post on the group mailing list?
AndyS: that would work.
ora: I can add that to the post.
AndyS: caveat is that there's a bug in the N-Triples test suite. PR to fix it.
ora: we'll get to that.
TAG Turtle family concerns 2 3
<TallTed> +1 post impl reports to mailing list. its unlikely to get flooded (and hey, if it does, validation!)
ktk: Basically two feedback from TAG about Turtle family.
… In both cases raised by Sarven. Concern is about forward compatibility.
… RDF 1.2 introduces new syntactic constructs, not understood by 1.1 processors.
… the TAG is concerned no guarantee of compatability by 1.1 systems.
… could end up in situation where unclear what happens when 1.1 processor consumes 1.2 data.
… not every impl would behave the same. could get incomplete data.
… we are aware of it.
… they invited us to a call.
… we propose to take next call in 2 weeks. we wanted to bump that with the group, think about how to we react.
… really hard to fix the past. we cannot change 1.1 parsers.
ora: The way I think about it is if an RDF 1.1 processor consumes 1.2 data, and produces an error, that's not our problem.
… I would be concerned where it consumes 1.2 content and produces something without an error, and result is somehow erroneous.
… do we need to worry about that? I don't see why we should worry about the first case. We're adding new stuff, things break when it comes to older stuff.
AndyS: in the discussion, they allude to other comments but I couldn't find them.
… if you've got a parser that parses RDF 1.1, finds somethign that isn't 1.1 (syntax error), all bets are off.
… you can't specify error conditions in all cases.
… Sarven makes this point in one of the minutes. I didn't see that being recognized.
… root concern wasn't technical. it was reputational damage to W3C.
… W3C would be endorsing a format that changed meaning.
… wonder if we can expand conversation to say new features in RDF 1.2 are not changing the meaning of 1.1.
… they are different and new. could not be expressed semantically in 1.1.
… we have encoding, but not the same semantics as RDF 1.2.
<niklasl> +1, it's new grammar (so conformant 1.1 parsers will break) and new meanings
AndyS: they won't have seen that document yet.
… if parsers do random things on errors, that's true for broken strings. if you emit half a string as a literal because it ran out, ...
j22: if it's reputational damage, I would mention that W3C has already endorsed standards in the past where the meaning of data has changed.
… XSD 1.1, gregorian years changed. shifted by +1 or -1.
… they've done this already.
… otherwise, you can't be forward compatible. LIke CSS with nested elements. Not parsable with old parsers. You can do anything with it.
<niklasl> +1 to that too
<ktk> +1
lisp: there is one line in 1.1 Turtle document in section 5 on conformance.
… does not define how parsers handle non-conforming documents.
… of which 1.2 document would be one.
… either we have ability to edit that, or the behavior is undefined.
tl: we could disconnect from the past and define a new name. add versioning mechanism.
… and be done with it.
TallTed: I don't understand what you're suggesting, tl.
tl: Call it "Startle" or something. Content is 1.2 as we define it. The file ending is "tts" or something like that.
TallTed: I don't think that maintains what most people understand semantic versioning to mean.
… 1.2 fully compatibile with 1.1.
… 1.1 can handle 1.2 data without problem, and vice versa.
… changing from undefined to defined behavior can be OK. But it has to be done in a non-breaking way.
… we can define that the way to handle 1.2 data is thus. but we cannot make a 1.1 processor do that.
… since 1.1 left a lot fo things undefined... lots of things do not trigger an error response. dropping data into /dev/null is not a good handling or an error response.
… saying I'm dropping this into /dev/null is OK if it allow some way to recover.
… if I'm loading n3 file, and some lines don't get put into the database because they don't conform with expectations, and dump those rows into a new document to be handled later...
… I don't lose data, it's just misplaced. I think that's more viable. But no way to really do that.
AndyS: I would point out i18n is asking exactly what TAG is asking us not to do: break 1.1.
… comes down to: should we have a new mime type?
… the other aspect of that is realistically RDF has applicability well beyond the web platform.
… putting files on a file server without control of mime type handling. Chemical database is a good example -- an ftp database.
… if you invent a new mime type that's RDF 1.2, you've split the world.
… 1.1 world and 1.2 world. yet the features of 1.2 are a superset of 1.1. Not a thing that changes 1.1.
… so you've cut off one of those halves from the other.
ora: To me, it's hard to define a spec that is somehow resilient against future changes.
… 1.1 could have specified something about errors, but they didnt'.
… we could put some note into our spec, recognizing the fact that 1.1 spec is somewhat incomplete.
ktk: interesting remark from list about Turtle.
… feedback from Sarven was about N-Triples. No similar language in N-Triples spec.
… is there a reason it's only written in Turtle spec?
ora: we could communicate with TAG before meeting.
… Anybody who would like to join...
AndyS: some of the TAG doesn't reflect the perfect answer. Has a lot of impact on implementations.
… they can be quite impactful. These ones would be very difficult to keep for the triple terms ones.
… to get a migration that the TAG would like to see. Data and parser writers are different communities.
… I think they have a slightly stronger case for text direction. It is so close to being language tag in Turtle.
<pfps> The "non-conforming" note in 1.1 Turtle is just an observation. 1.2 N-Triples has exactly the same situation, only missing the non-normative(?) Note.
AndyS: could imagine a parser was pretty lax about reading data in, would just merge the direction into the langtag.
… on the other side of the coin, that's a change that's being put upon us from the outside.
… ITS itself changes the meaning of an RDF/XML document.
ktk: Another aspect - I would like to test how parsers behave.
… they compared with web stack. we've seen how hard it was for a while to move forward with web stack.
… IE burned everyone on that.
… it's a different thing. This is not baked in in a browser.
… this are individual libraries for doing work with RDF.
… my parser for a long time was rapper/raptor. Never supported json-ld, for example. So I moved forward to other tools.
… you're not stuck with whatever browser the company gives you.
ora: would it make sense for us to concoct an example that demostrates some of this bad behavior?
… or should we ask TAG to prove us wrong and give us an example?
AndyS: I think that would be a good idea. Start with RDF 1.2 not using 1.2 features, does not change 1.1.
… it is claimed in TAG mintues that it does make a change.
… I don't think we share strong common technical ground with the people doing the review.
<niklasl> +1 to that (no change of meaning)
ora: pick this up in chairs meeting.
ktk: I will send AndyS the dates. If anyone else wants to join, let us know.
… pchampin and I already had ideas on how to make weird input, provoke some errors. We will work on that.
… I'm really talking about usual suspects.
AndyS: this is 5 years old. The community that's actually on the web have seen it for a long time and are expecting it.
… it's not something we're springing on people.
ora: this would be a benefit of working in public.
Review of open PRs, available at 5
ora: AndyS , you said there's a PR to fix a bug in N-Triples?
AndyS: in rdf-tests. On Windows, it will fail.
… or it should fail. Because the N-Triples tests include canonicalization. We aren't changing line endings.
<AndyS> w3c/
<gb> https://github.com/w3c/rdf-tests/pull/316
<pfps> Well if you use broken software ...
AndyS: PR covers two things. Extended test to cover langtags better. And I put that into Jena and got reports back from users on Windows.
<AndyS> https://
AndyS: already got approvals for the first half.
ora: rdf-xml ORCID IDs?
j22: that's ready to go. I can add it.
pfps: there's a couple of us working on SPARQL entailment. moving from 1.0 to 1.1.
… there's a PR to change URI refs to IRIs.
ora: please merge it.
pfps: everywhere in SPARQL, we should change URIs to IRIs.
AndyS: The rest of the web community is going around changing IRIs to URIs saying they're the same thing.
pfps: all RDF docs say IRIs. Need to match that.
AndyS: your PR on sparql-query has a couple of editorial things.
<gb> Pull Request 368 change equivalent to renaming blank nodes in scoping graph definition (by pfps)
pfps: I thought I pulled everything.
… should I be merging it in?
AndyS: there are suggested changes. If happy with them, pull those in.
pfps: I'll do that.
ora: Where are we with common files by reference? I need to review it.
niklasl: I think a bunch have been merged already.
… merge at will.
ora: we have it in a lot of specs. that would be great to merge.
AndyS: i18n input?
… comments on Turtle.
ktk: the ones linked in your issue?
AndyS: I'm not sure if they're official or not. Just appeared as issues.
… they are marked "i18n"
<AndyS> w3c/
<gb> Issue 130 Unicode escape sequences (by xfq) [i18n-needs-resolution]
<AndyS> w3c/
<gb> Issue 131 The `\u` escape range in Section 6.4 (by xfq) [i18n-needs-resolution]
AndyS: point out errata which I think have been addressed.
… they also have higher level requests.
ora: what are they asking?
AndyS: in #130, they are asking for a new escape sequence form
<gb> CLOSED Issue 130 vocabulary to refer to the individual nodes in a reified triple term (by rat10)
AndyS: based on convenience, not on future-proofing.
ora: this would mean messing with the Turtle EBNF?
AndyS: Yes. Also that you could write something with 1.1 meanign/semantics in a new way.
ktk: this would be a major and not a minor change?
AndyS: I think you could put it like that. I don't think it's a good idea.
… with a clean slate, yes, better. But now we'd have two ways of writing things.
… which is something they say not to do.
… if we were making other changes in the same area, maybe. But we're not.
pfps: I'm confused here. They want RDF strings to contain unpaired surrogates?
AndyS: you're looking at the other issue, but yes.
pfps: that seems bonkers.
<j22> +1
AndyS: if we've moved on to that one, I have no idea how you would implement that. It's not legal. You can't just convert the escape sequence into a surrogate.
… in utf8, surrogates are illegal.
pfps: rdf strings to utf8, and now I have illegal utf8 in my computer.
AndyS: you'd have to re-implement string.
pfps: any place that accepts an RDF string.
AndyS: I don't understand why they want this.
<Souri> +1 to not supporting \u{H…H}
ktk: I would bring up that this is a major patch. We are in a minor revision.
AndyS: re: surrogates, I don't understand why they'd want to encourage bad data.
… data is more transient on the web. between server and client. maybe a sense that you can fix things more easily. but different for published data.
ora: who is this?
AndyS: lead on i18n, I think.
lisp: I'm confused. Recommendation that things be unicode strings. And somebody asking that you have a string which is not unicode.
… not allowed unpaired surrogates (?)
AndyS: stonger than that. No surrogates at all.
lisp: 1.1 conformance section on "Unicode string".
AndyS: 1.1 has problems. "Unicode string" has no meaning. Reflects the byte-level. It is dependent on the encoding. Not the abstract sequence of scalar values.
… there's a test in the 1.1 test suite that shows if you put a surrogate in the string, it's a parse error.
… but that's no in the spec.
ora: could we say we really like the comment that Martin Duerst left, and just go with that?
pfps: works for me.
ora: I'll put a comment there.
AndyS: let them reply. if after a week…
… they're talking about GSP, which just doesn't work.
ora: I'm commenting right now.
… we'll wait for reply.
AndyS: for the other one on escape sequence, shall I reply saying WG feels impact on existing 1.1 data is too much?
TallTed: \u{} form limits you to 6 digits.
AndyS: unicode only needs six digits.
… difference between what you can encode and what is actually defined in unicode.
… everything above 10FFFF is undefined.