RDF Working Group Teleconference -- 03 Apr 2013

<trackbot> Date: 03 April 2013

<gavinc> Ugh, it seems my update today is: No I haven't had time to send the Grant requests or setup something to deploy to 2013/turtle-testsuite/

Zakim: ??P4 is me

ivan, sorry, a bit slow today :)

<ericP> waiting for HCLS call to finish

<SteveH> sorry, I'm not on a speakerphone, so typing is not easy

yep

<scribe> scribe: yvesr

<pfps> can we start up the scribe list again? it is much easier to scribe if one knows in advance

ivan: We are back in schedule for the TZ, until October

<ivan> minutes of last meeting

<pfps> minutes are fine

RESOLUTION: Minutes from the 2013-03-27 are accepted

ivan: there are a number of actions to review

<cygri> ACTION-222?

<trackbot> ACTION-222 -- Richard Cyganiak to work with PatH to make sure there is no duplicated content between RDF Concepts and RDF Semantics -- due 2013-01-23 -- OPEN

<trackbot> http://www.w3.org/2011/rdf-wg/track/actions/222

ivan: 221 and 222 are the same action, on cygri and path

cygri: this is not something that needs to be addressed at this point
... i'd rather leave it open at the moment

<pfps> In my opinion Concepts and Semantics are not totally aligned, but there are no serious issues.

<cygri> pfps, I agree. Needs a careful review.

<cygri> ACTION-226?

<trackbot> ACTION-226 -- Richard Cyganiak to implement ISSUE-111 resolution -- due 2013-02-13 -- OPEN

<trackbot> http://www.w3.org/2011/rdf-wg/track/actions/226

ivan: there is another action on cygri's name - ACTION-226

<cygri> ACTION-227?

<trackbot> ACTION-227 -- Richard Cyganiak to present concrete wording for ISSUE-105 -- due 2013-02-13 -- OPEN

<trackbot> http://www.w3.org/2011/rdf-wg/track/actions/227

cygri: ACTION-226 is not done
... as is ACTION-227

ivan: ACTION-332 was on sandro

<gavinc> Issue is now mine.

sandro: my understanding is that we can close it

trackbot: CLOSE ISSUE-332

<trackbot> Error closing ISSUE-232 - the response from Tracker was missing data. Please contact sysreq with the details of what happened.

<TallTed> yvesr - it's action, not issue

<sandro> close action-232

<trackbot> Closed ACTION-232 Learn about the w3c test suite license.

<sandro> action-233?

<trackbot> ACTION-233 -- Gavin Carothers to publish the consolidated test suite -- due 2013-03-06 -- OPEN

<trackbot> http://www.w3.org/2011/rdf-wg/track/actions/233

ivan: is ACTION-233 more than publishing the consolidated test suite?
... we have 3 actions all on the JSON-LD review

<sandro> close action-240

<trackbot> Closed ACTION-240 Review JSON-LD API document.

ivan: i believe 3 have been done

<cygri> ACTION-239?

<trackbot> ACTION-239 -- Richard Cyganiak to review Semantics draft regarding move to FPWD -- due 2013-03-13 -- OPEN

<trackbot> http://www.w3.org/2011/rdf-wg/track/actions/239

<sandro> action-241?

<trackbot> ACTION-241 -- Zhe Wu to review JSON-LD API document -- due 2013-03-27 -- OPEN

<trackbot> http://www.w3.org/2011/rdf-wg/track/actions/241

close action-239

<trackbot> Closed ACTION-239 Review Semantics draft regarding move to FPWD.

<cgreer> close action-238

<trackbot> Closed ACTION-238 Review the JSON-LD syntax document, after Sandro's review has been taken into account.

action-235?

<trackbot> ACTION-235 -- Antoine Zimmermann to review RDF 1.1 Semantics -- due 2013-03-06 -- CLOSED

<trackbot> http://www.w3.org/2011/rdf-wg/track/actions/235

action-236?

<trackbot> ACTION-236 -- Guus Schreiber to put spec of scope bnodes in Concepts on agenda for 6 Mar -- due 2013-03-06 -- CLOSED

<trackbot> http://www.w3.org/2011/rdf-wg/track/actions/236

<gavinc> Non NON NFC

<gavinc> NFC only IRIs

gavinc: the job was to delete the non-non nfc test from the test suite

ericP: i added an approval status to all of the tests, make them all approved, and added a rejected column for that one
... i expect there will be some pushback

<ivan> close action-246

<trackbot> Closed ACTION-246 Remove #localName_with_PN_CHARS_BASE_character_boundaries.

<ivan> action-245?

<trackbot> ACTION-245 -- Eric Prud'hommeaux to (with Sandro) to copy or proxy Turtletests2013 to http://www.w3.org/2013/Turtletests/..., updating all base or ttl references to http://example/base/ to be http://www.w3.org/2013/Turtletests/ -- due 2013-04-03 -- OPEN

<trackbot> http://www.w3.org/2011/rdf-wg/track/actions/245

ericP: as people need to look up approved tests before running them

<gavinc> That's dependent on me finishing

ericP: has the license issue been sorted?

gavinc: no, not yet

<ivan> action-225?

<trackbot> ACTION-225 -- Eric Prud'hommeaux to update extension request with Turtle publication dates -- due 2013-01-30 -- OPEN

<trackbot> http://www.w3.org/2011/rdf-wg/track/actions/225

<ivan> close action-225

<trackbot> Closed ACTION-225 Update extension request with Turtle publication dates.

ericP: it is overtaken by events - it was for the CR publication
... about ACTION-245, I am still getting comments from the list on tests
... we made a decision last week to approve the tests
... some of the corrections I am seeing from the comments list are corrections

<gavinc> We had invalid Test case N-Triples as well

ericP: escaping, case, etc. - should we normalise what to do with escaped characters?

gavinc: we did resolve that - there is only one way to represent each character in n-triples
... there are a couple of edge-cases
... if we get further comments, we'll need to reapprove the test suite

JSON-LD

ivan: next topic is JSON-LD
... We have 3 reviews, could we get an overview of them?

manu: Markus has been dealing with the comments
... We do have one thing the RDF WG probably wants to look at

markus: most of the feedbacks are editorial
... sandro replied he's happy with the changes
... one comment was about the algorithm - they are too long
... but we decided not to change them
... it was agreed the decision was accepted

zwu2: It would be nice to modularise the algorithm description - it is very long
... I understand it is a big effort, so I am willing to let it pass

manu: We did start out with a fairly modularised way of explaining the algorithm
... when implementers were reading the spec, they were very confused, as you needed to jump between different points of the spec
... implementers seem to prefer the non-modularized versions

<gavinc> yay :D

manu: as they are much easiers to read
... the algorithm are long and verbose for a reason
... we want to be clear about what they're doing

ivan: I think we can move on with this

markus: the only other issue which hasn't been addressed is the data round-tripping section
... where we specify how e.g. json true and false are converted to RDF
... sandro raised some concerns about that

ivan: what about the third review from charles?

manu: it was mostly editorial comments

ivan: so we only need to discuss sandro's comment

<Zakim> sandro, you wanted to ask about lists-of-lists

markus: yes, i think that's right - we would be OK to go to LC

<sandro> manu: we agreed to add At Risk for the list-of-lists thing

gkellogg: marking the list-of-lists as 'at-risk' but it would cause a bit of a mess

markus: it's worth to say that list-of-lists are supported
... but there isn't a simple way to express that in short-form in JSON-LD

sandro: I missed the fact you could use first/rest
... If you can, then I can live with it
... I am certainly happy with the at-risk solution

<markus> Here's the list of the features at risk: http://www.w3.org/2011/rdf-wg/wiki/JSON-LD_Features_at_Risk

ivan: so the only other issue is the round-tripping?

manu: yes

sandro: I sent this in an email just before the meeting started
... If you have an RDF graph if you have things like doubles in it, which can be expressed in JSON
... there are situations where you can export to JSON and back again
... and not end up with the same graph
... e.g. when the literal is not in canonical form
... or when using doubles

<Guus> for the agena: see my admin message about the 4 FPWDs

sandro: you could keep it in expanded type in JSON-LD rather than native type
... which would ensure you end up with the same graph
... the question is, do we care?

manu: the guidance we give in the JSON-LD API spec is that if accuracy of numbers are important, use a string to express them
... and type it with xsd:double
... if you use JSON native types, then you will have rounding issues

<gkellogg> that flag is in fromRDF, not for native JSON-LD

manu: if the 'use native type' flag is off, then no rounding issues

<ericP> iirc, XML Schema requires preservation of 18 digits on doubles

<TallTed> may need to include something like -- http://msdn.microsoft.com/en-us/library/windows/desktop/ms716298%28v=vs.85%29.aspx

manu: The other advice we give in the spec is how to express the canonical lexical form

<TallTed> which data types convert cleanly, which have issues such as were just flagged

manu: there is an interoperability issue some of us are concerned about
... captured in the test suite

<gavinc> JSON has interop issues with large numbers ;) It's sadly not a JSON-LD issue

manu: The guidance we tell people is that you must use the string format when you convert a string literal with an xsd:double datatype

<gavinc> +1 sounds very reasonable!

<TallTed> explicit example is the numeric conversions page, here -- http://msdn.microsoft.com/en-us/library/windows/desktop/ms714147%28v=vs.85%29.aspx

manu: Do we want to do something else in the JSON-LD API spec?

sandro: I don't like the API flag - I don't think people are going to know how to use them
... It depends on the data

manu: It depends on the application
... We tried to make the documentation very clear around rounding errors introduced by native JSON datatypes

<cygri> castToNativeType?

gavinc: JSON and JS do not specify the exact behavior of numbers
... they are plenty of incompatible JSON implementations in terms of numbers

TallTed: It would be worth introducing a table of conversions in the spec
... What are the status messages you get back when errors are introduced?

manu: We would have to make one table per javascript implementation - which would be very hard

gkellogg: it's also all the JSON processors

TallTed: so basically JSON doesn't preserve data?

markus: It's just not specified

<gavinc> or python! until you run out of memory bit!

manu: lots of people use JSON to exchange data and it doesn't seem to have caused any issues

pchampin: I see two things about the useNativeDatatype flag
... the first one is that you may have rounding problems
... the second one is that even without it, you end up in an interoperability issue
... it should be said in the specification
... that round-tripping is not possible in this case
... If you care about round tripping, this flag should be set to off

sandro: I know JS requires IEEE 24 bits, I didn't realise people implemented JSON at a lower level than JS

<pchampin> pchampin: if I care about round tripping preserving the lexical values of literals, this flag should be set to off

<TallTed> +1 sandro

sandro: If you care about data integrity - this flag should be set to off

ivan: So if this is closed, where are we exactly wrt JSON-LD to LC?

markus: That's the only remaining change we need to make

<sandro> WebIDL

ivan: the LC shows the design is done
... Let's discuss that later, but can we plan that next week we vote for LC?

markus: sure

<gkellogg> agreed

<scribe> ACTION: WG to resolve on LC status on 10/04/2013 [recorded in http://www.w3.org/2013/04/03-rdf-wg-minutes.html#action01]

<trackbot> Error finding 'WG'. You can review and register nicknames at <http://www.w3.org/2011/rdf-wg/track/users>.

<manu> So, we're going to shoot for a LC of JSON-LD and JSON-LD API for April 19th 2013...

redefinition of blank nodes

<scribe> ACTION: davidwood to resolve with WG on LC status of JSON-LD on 10/04/2013 [recorded in http://www.w3.org/2013/04/03-rdf-wg-minutes.html#action02]

<trackbot> Created ACTION-249 - Resolve with WG on LC status of JSON-LD on 10/04/2013 [on David Wood - due 2013-04-10].

<manu> (just to be clear about what the JSON-LD editors and CG are going to shoot for)

<ivan> issue-107?

<trackbot> ISSUE-107 -- Revised definition of blank nodes -- open

<trackbot> http://www.w3.org/2011/rdf-wg/track/issues/107

<sandro> ivan, are we going to talk about Guus' report of not publishing as planned?

pfps: I went through both concepts and semantics, they describe the current situation quite well already
... they only need tiny changes
... What it doesn't have is an explanation of what the change is
... It needs to be added to concepts or primer

ivan: It would be good to have an explicit action on cygri and path to check whether it's fine with them

<scribe> ACTION: cygri to review pfps's proposal on ISSUE-107 [recorded in http://www.w3.org/2013/04/03-rdf-wg-minutes.html#action03]

<trackbot> Created ACTION-250 - Review pfps's proposal on ISSUE-107 [on Richard Cyganiak - due 2013-04-10].

cygri: Happy to take the action, however I don't see how that would close the issue

Update on publications

ivan: The plan is to publish the first public working draft tomorrow

sandro: They need to be using the latest version of respec

pfps: I don't know what exactly is required

<Guus> if Peter can do the links, that would be great

pfps: I can fix up the links, but not sure how to rebase respec

sandro: We shouldn't have a local copy of respec

<Guus> we should point to the new version, the https version

<Guus> i'll unmute myself

Guus: We need to point to the new respec version - what I didn't realise is that it's nice for editing, but difficult for publishing

<gavinc> Where is the THE ReSPEC?

<gavinc> https://github.com/darobin/respec ?

<sandro> The right version is: http://www.w3.org/Tools/respec/respec-w3c-common

<markus> here's the ReSpec script to convert to html on the command line: https://github.com/darobin/respec/blob/develop/tools/respec2html.js

gavinc: the XHTML processor for respec uses divs instead of sections, the HTML one uses sections

<gkellogg> We should be using the version in w3c space: https://www.w3.org/Tools/respec/respec-w3c-common

<gkellogg> That's what the EARL report uses

<pfps> someone has to tell me where the references database is

Guus: in our repository i created a draft repository with all the documents

sandro: We need to do the same across all our different specs

<pfps> OK

<sandro> +1 guus saved-from-respec goes in to pub/<shortname>/Overview.html

Guus: if pfps fixes the links, I can fix the references

<gavinc> https://www.w3.org/Tools/respec/respec-w3c-common

Guus: I may be able to do it tonight, or next Tuesday

<pfps> I'll work on the links today

dependencies

ivan: We have a bunch of dependencies when we go to CR
... JSON-LD depends on the concepts document
... It already depends on the not-yet-existing Schema document
... Concepts depends on DOM4 and HTML5
... We have the WebID dependency on the JSON-LD API
... Hopefully we can avoid putting documents on hold because of that

<Zakim> ericP, you wanted to ask if we can refer but shortname to our internal specs 1 version behind the doc being published

<pfps> were are is our respec publications DB?

ericP: What we try to avoid is to point to first drafts, which can change
... But we can point to version of documents that are one step behind us

ivan: But HTML5 won't become a PR before 2014
... So if we depend on it, we can't go to REC with RDF Concepts before then
... JSON-LD would like to go to REC quickly, and we might have to wait for Concepts before we do that

cygri: About the DOM4 dependency, there are a couple of options
... When we moved the DOM3 ref to DOM4, we could change that back

<gavinc> DOM3 is WRONG :P

cygri: And still refer to DOM3
... We might have to do some explanation there
... When we reference the HTML5 parsing algorithm, we might need to describe the output in terms of DOM3
... So we might need to be careful
... But that might be the easiest way

gavinc: We can refer to DOM3, but every implementers is going to run into bugs

ericP: Are we confident DOM4 is backward-compatible?

ivan: Nobody knows

ericP: The WG should have a pretty good idea

<gavinc> Reality ;) http://dom.spec.whatwg.org/

ivan: For the time being all the evolution of DOM4 is happening in the WhatWG
... Maybe a possibility is to have a normative ref to DOM3, and a note pointing at DOM4 elsewhere in the doc
... Not sure how to do that exactly, but there might be some wording that could work

ericP: What's the trick to point people to what they need to read to actually implement it?
... If I support HTML literals, I will have to read that spec on the WhatWG
... We could move that out of the doc, and push them as notes, but no one would really care

ivan: Could we push it in a non-normative section?

ericP: we should really explain what to do with HTML literals - if we don't then it needs to be pushed somewhere else
... We're saying that the processing of XHTML literals has changed - where is the example data showing what's changed?

<scribe> ACTION: cygri to investigate dependencies in concepts and semantics [recorded in http://www.w3.org/2013/04/03-rdf-wg-minutes.html#action04]

<trackbot> Created ACTION-251 - Investigate dependencies in concepts and semantics [on Richard Cyganiak - due 2013-04-10].

<cygri> ACTION-251?

<trackbot> ACTION-251 -- Richard Cyganiak to investigate dependencies in concepts and semantics -- due 2013-04-10 -- OPEN

<trackbot> http://www.w3.org/2011/rdf-wg/track/actions/251

ivan: Another dependency is WebIDL from JSON-LD

markus: I'll try to figure that out

<cygri> (I changed the description of ACTION-251)

<cygri> ACTION-251?

<trackbot> ACTION-251 -- Richard Cyganiak to investigate dependencies on DOM4 and HTML5 in Concepts -- due 2013-04-10 -- OPEN

<trackbot> http://www.w3.org/2011/rdf-wg/track/actions/251

markus: We have to right a couple of tests ourselves to prove the part we're using is stable enough
... ... I am working with Robin to address that

ivan: AOB?

<zwu2> bye

pchampin: I was wondering with Turtle being in CR - would it be too late to add a small feature

<markus> profile media type parameter?

<cygri> LDP-WG perhaps would like text/turtle;profile=xxx

pchampin: Would it be possible to add a parameter to the media-type registration

<gavinc> why do we want profile?

pchampin: I raised this question in the LDP WG

cygri: The LDP WG is considering whether to define a new media type to Turtle

<pchampin> I agree we don't have time to discuss that today;

<pchampin> I was just asking to know if it was not too late

<gavinc> or just point to LDP thead... clearly

cygri: Adding a parameter would enable them to avoid that

<pchampin> If it is not, I can send an email as well

RRSAgent: make logs public

<gavinc> http://www.w3.org/2012/ldp/track/issues/57 ?

<TallTed> http://tools.ietf.org/html/rfc2616#section-14.20

<TallTed> EXPECT header

<ericP> `curl -H "Expect: fail" http://www.w3.org/` => 417 Expectation failed

hmm

'the name "steveh" does not match any of the 47 active names'

how can i edit that list of names?

<cygri> yvesr, I think you can say "Guest: steveh" near the top of the chatlog to make that error go away

cool, ok

hmm ('Cant parse name', "u'SteveH'")

ah, ok - it expects first name/last name

<Guus> trackbot, end meeting

- DRAFT -

RDF Working Group Teleconference

03 Apr 2013

Attendees

Contents

JSON-LD

redefinition of blank nodes

Update on publications

dependencies

Summary of Action Items

Scribe.perl diagnostic output