RDF Working Group Teleconference -- 10 Apr 2013

<trackbot> Date: 10 April 2013

<Guus> trackbot, start meeting

<trackbot> Meeting: RDF Working Group Teleconference

<trackbot> Date: 10 April 2013

<Guus> pls volunteer to scribe

scribenick cgreer

<scribe> scribenick: cgreer

<pfps> Minutes are beautiful

RESOLUTION: Minutes accepted from April 3 telecon

telecon bridge

sandro: zakim is over capacity at noon
... running late causes a problem
... there's a system called calliflower that I propose to use
... I propose we try it next week.
... I propose we use IRC as normal

<pfps> so no connection betrween IRC and the phone?

sandro: People using the phone won't show up on IRC

<davidwood> So we will lose some IRC/telephone integration

<Arnaud> I think attendance is the biggest loss

<Arnaud> for queue management I don't see why we don't keep using irc

sandro: the current list is generated by phone and IRC -- people only on the phone will have to be notated on IRC
... it would be easy to automate if turns out to be worthwhile

manu: We could allow use of our system
... If the JSON-LD minutes are acceptable, then we could try out that system.
... You can call in with voip or regular phone, as the latter costs money
... it's our service. We run an Asterisk server
... it's not as complete as Zakim, but it's open source and people can extend it

<ericP> appreciating manu's generous offer, i think we'd end up hacking the system and so we'd want to use digital bizarre's service only if we were going to adopt asterisk

ericP: I expect we'd want to hack the system though.
... this ups the value of w3c setting up an asterisk server.

davidwood: stay tuned for email about next week
... everyone OK to delegate to chairs about next week's telecon?

<pfps> Go wild!

<Arnaud> +1

guus: Any alternate we choose must not increase admin.

sandro: I'll take on any additional admin

action items

ericP: We can't wrap up test suite until stream of comments has calmed

guus: Gavin has an action.

ericP: We choose new URL, Gavin tags, then set up proxy.

<gavinc> First I get Grants from the two other contributors, which I will finally have time to do this week!

<gavinc> woohoo!

Action-241: closed

<trackbot> Did you mean to close ACTION-241? If so, please say 'close ACTION-241'.

ACTION-241: Closed

<trackbot> Did you mean to close ACTION-241? If so, please say 'close ACTION-241'.

close ACTION-241

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

<gavinc> Thanks Guus for finishing those

Document Publication

guus: There are four new FPWDs

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

guus: The respec document has a list where you should put comments, but the list doesn't exist. respec is generating the wrong HTML

<gavinc> that's respec today?

guus: Who maintains it? No email address for the comment list

<gavinc> https://github.com/darobin/respec/issues ;)

<gavinc> Magic, you know via Magic

markus: Robin is pretty good with responding from github

<gavinc> Yeah, pubrules is wrong ;)

guus: Leaving in RDFa generates pubrules errors

ericP: Use "1.1" rather than "true" for RDFa

sandro: It may generate errors that the web admin has to resolve

<gavinc> I'm pretty sure that RDFa only works in the XHTML output, not the HTML output

guus: Somebody help with publication wiki page maintenance please

JSON-LD

gkellogg: Markus has prepared JSON-LD 1.0 and JSON-LD-API
... They pass pubrules, etc, etc
... We've closed the loops with commenters, no outstanding issues

<markus> http://www.w3.org/2011/rdf-wg/wiki/JSON-LD_Features_at_Risk

gkellogg: We've marked a few things 'feature at risk' for those things we want feedback during LC
... We just want proposal and resolution to publish as LC
... The end

<manu> https://dvcs.w3.org/hg/json-ld/raw-file/default/spec/WD/json-ld/20130411/index.html

<manu> https://dvcs.w3.org/hg/json-ld/raw-file/default/spec/WD/json-ld-api/20130411/index.html

guus: I'd like to go through features at risk

manu: From the top --
... @base
... we were trying to cut down on the number of keywords, but we got feedback that it's a useful features
... The interop of blank @base vs. explicit @base is confusing (potentially)
... The other concern is what the empty string should do
... Next feature at risk is reverse property
... Allows one to switch subject and object position
... Again, concern is use vs confusion
... Next feature - -blank nodes as properties
... Compromise in spec now. We await feedback from implementors
... Converting list of lists. The algorithm for this is fairly complex, use is questioned.

gkellogg: We marked this feature as 'at risk' and we've not provided implementation

manu: Next has to do with Web IDL
... We use web IDL to express the API. There are rough patches in this standard.

<gkellogg> Also, note RDFa 1.1 does not support lists of lists.

manu: If you specify an optional parameter, you cannot mix and match optionality or parameters... you have to overload signatures to express this.

<gkellogg> (Rather, neither have syntactic sugar for lists of lists, they do support explicit rdf:first/rdf:next

manu: We ran API against Web IDL test harness.
... It fails method overloading, but we think the JSON-LD-API is correct nevertheless
... This isn't a technical issue, but how to get around problems in Web IDL and still reference it
... Last feature,
... We're thinking we might change default value of @base
... to null, so that by default relative IRIs are not compacted
... That's it

<davidwood> +1

sandro: This is important work, not perfect, but I think it's ready for LC

<PatH> +1 sandro

PROPOSED to publish Last Call WDs of the JSON-LD documents

<gkellogg> +1

<PatH> +1

<markus> +1

<sandro> PROPOSED: to publish Last Call WDs of the JSON-LD documents

<sandro> manu: 4 weeks last call

manu: Publication date is 4/11, LC period is for four weeks

<yvesr> +1

<sandro> +1

<manu> +1

<pchampin> +1

<ericP> +1

<Souri> +1

<FabGandon> +1

<Guus> +1

<AZ> +1

<davidwood> +1

RESOLUTION: publish Last Call WDs of the JSON-LD documents.

<Arnaud> +1

<davidwood> Whew!

<ericP> congrats!

<sandro> much thanks!

sandro: Question about LC period. Semtech is in the middle of it.
... Do we want to be in CR or LC for semtech?

guus: We'd thought of skipping CR --

markus: There's a marker in the spec the we could skip if there are a lot of implementors

<Arnaud> usual rant: there is no such thing as "skipping CR" per se, the question is whether we believe we already qualify to exit CR right away

sandro: LC ends on May 11. So that would give us three weeks to get to CR for Semtech

<tbaker> +1

manu: We want to make sure we can address any issues during LC

<sandro> sandro: Given all the Features as Risk, let's not skip CR.

Arnaud: There's no such thing as skipping CR
... You have to go to CR technically. If we meet criteria to exit right away, then we can move through it quick.

sandro: well, you can skip, but we're not going to.

<sandro> 4 Weeks puts us at May 9

guus: Correct date -- May 10 for end of LC

<gavinc> +1

manu: OK we'll update docs

<gkellogg> http://json-ld.org/test-suite/

<gkellogg> http://json-ld.org/test-suite/reports/

manu: Test suite is in good shape. Gregg has put together a quick publication of test suite. Fairly rough but improving.

gkellogg: The process is similar to that from turtle, but needs further documentation -- the differentiation of different test types.
... We don't have any syntax-only tests

<davidwood> Arnaud, regarding skipping a CR, please see http://www.w3.org/2005/10/Process-20051014/tr.html#rec-advance where it says: "Call for Implementations. Note: The Director may permit the Working Group to skip this step if the entrance criteria for the next step have already been satisfied."

<davidwood> NB: "Call for Implementations" = CR

gkellogg: There are submanifests for JSON-LD tests. And an umbrella manifest that references them.
... We don't need to consolidate further

manu: We're going to use RDF-WG tracker for issues, since it folds in email conversations

<Arnaud> david, ok, I stand corrected!

manu: Do not use github issue tracker for LC

<gkellogg> SOTD references public-rdf-comments@w3.org

<gavinc> Yeah, it sort of sucks.

<Arnaud> it's just a technicality anyway, the result is the same

manu: For disposition of comments, you need an issue tracker.
... we create an issue for each comment. At end of last call we have a good set of issues.

sandro: How do you create a summary?

manu: by hand

RDF-JSON

guus: We have a note about RDF-JSON.
... Is this useful to publish as a note?

Arnaud: IBM has been experimenting with JSON-LD and RDF-JSON
... Because of the use cases, RDF-JSON is a better fit
... JSON-LD is designed for JSON developers to access data stores.
... A different use case is a completely JSON environment, such as using MongoDB.
... And you want to use RDF within JSON syntax
... Storing RDF in JSON database
... Compacted form doesn't work, you want to store expanded form.
... Structure of expanded JSON-LD doesn't lend itself to RDF processing out of the box -- this has led us to conclude that RDF-JSON meets other use cases better.
... This has left us with RDF-JSON listed as ED... IBM intends to use it with a stable reference.
... We'd like to have it moved to a WG note as stable reference.
... WG did recognize that different JSON RDF specs are useful for different use cases.

guus: In first F2F we did consider exactly this.

<AndyS> By user usage and requests -- the Talis doc got archived/made safe at http://jena.apache.org/documentation/io/rdf-json.html and implemented.

AndyS: We've seen uptake in use of RDF-JSON.
... A note would be good.

manu: I'm fine with publication as a note.
... I want to find out more specifics though.
... about the IBM case.
... We thought that JSON-LD was made for this use case.
... I'm concerned that IBM is making --- well, why is RDF-JSON better for this?
... It seems like a dump format, but I'd like to hear more.

<AndyS> mailing list please

Arnaud: OK we can keep this discussion going

guus: THe RDF-WG list please

pchampin: I see IBM's reason for not storing JSON-LD.

The argument is about storing, not exchange.

pchampin: Maybe the note should emphasize that exchange and storage do not have to be the same JSON.

<manu> You don't have to store and exchange the same document in JSON-LD either.

gkellogg: We discussed one of the advantages of RDF/XML is that you can index by subject. We'd discussed a feature called subject maps.
... We're considering extensions/notes.
... If you're storing JSON in MongoDB, URIs as keys is problematic.
... The compact form of JSON-LD has advantages for this.
... For query purposes, an enhanced triple format is better for indexing/storage.

Resolved: Arnaud is willing to serve as editor for this putative note.

turtle test suite

ericP: We'd hoped to be done, but we keep getting bug reports and comments

<ericP> -> http://www.w3.org/mid/1364751722.5708.24.camel@verne.drobilla.net <d@drobilla.net>'s patches to: upcase \U000b don't \U-ify unnecessary punctuation (e.g. \" or #)

ericP: Traditional ntriples (ascii ntriples) has an issue
... Verne Drobilla (?) provided a patch to unify them.

AndyS: At some point we're testing RDF not turtle. This seems to be the same case.

ericP: I'll use my own discretion in order to accept these patches.

guus: I'd prefer you use your own discretion

AndyS: results are invalid if we go around changing tests.

gkellogg: So we must get some communication about location of tests.

ericP: People will have to run tests again after location move. I'm happy to leave the tests alone.
... The effort to change is small.
... Before we publish the test suite, we have to confront the fact that xsd:strings are not xsd:strings.
... Andy suggested we leave these alone.
... I'll take this to list

<AndyS> XML 1.1 -- http://www.w3.org/TR/xml11/#NT-Char

<Guus> trackbot, end meeting

- DRAFT -

RDF Working Group Teleconference

10 Apr 2013

Attendees

Contents