See also: IRC log
<ericP> trackbot, start meeting
<trackbot> Date: 05 December 2012
<scribe> scribe: Arnaud
<AndyS> I am muted
<davidwood> PROPOSED to accept the minutes of the 28 Nov telecon: http://www.w3.org/2011/rdf-wg/meeting/2012-11-28
<davidwood> RESOLVED to accept the minutes of the 28 Nov telecon: http://www.w3.org/2011/rdf-wg/meeting/2012-11-28
<davidwood> Review of action items
<davidwood> ▪ http://www.w3.org/2011/rdf-wg/track/actions/pendingreview
<davidwood> ▪ http://www.w3.org/2011/rdf-wg/track/actions/open
no pending review
davidwood: anyone claiming credit
for any of the open actions?
... none, moving on
<davidwood> Can we update http://www.w3.org/RDF/ ?
<sandro> sorry I'm late
<ivan> http://www.w3.org/standards/techs/rdf#w3c_all
ivan: this is wiki so it should be easy to update
<davidwood> Why doesn't http://www.w3.org/standards/techs/rdf#w3c_all list RDFa?
ivan: that page is automatically generated based on some magic formula
sandro: send an email to webmaster to request an update
<markus> Btw. JSON-LD API spec is also missing from the list at http://www.w3.org/standards/techs/rdf#w3c_all
<davidwood> ACTION: davidwood to arrange update of http://www.w3.org/2011/rdf-wg/track/actions/pendingreview and http://www.w3.org/2011/rdf-wg/track/actions/open [recorded in http://www.w3.org/2012/12/05-rdf-wg-minutes.html#action01]
<trackbot> Created ACTION-216 - Arrange update of http://www.w3.org/2011/rdf-wg/track/actions/pendingreview and http://www.w3.org/2011/rdf-wg/track/actions/open [on David Wood - due 2012-12-12].
subtopic: test preparations
<ericP> local name //subject/iri/PrefixedName/PNAME_LN
<ericP> objectList with two objects //predicateObjectList[objectList/object[2]]
<ericP> predicateObjectList with two objectLists //predicateObjectList[objectList[2]]
ericp: have been working on a script for testing
<ericP> dvcs .... /rdf-turtle/coverage/paths
<ericP> dvcs .... /rdf-turtle/coverage
ericp: should I commit this stuff to mercurial?
sandro: concerned this will get published
<ericP> http://dvcs.w3.org/hg/rdf/raw-file/default/rdf-turtle/
discussion on where to put eric's stuff
ericp: could put a README to give
instructions on publication
... will create a new directory
subtopic: LC comments
ericp: not sure where we stand on
the I18N comments
... will ping Richard Ishida
ivan: we need to give a firm
deadline
... you need to go to the chair
<ericP> is it better to mail the right person who won't respond or the wrong person who will respond?
ivan: specifying that by December
15 if we don't hear back from them we will consider the issue
closed
... for Prov they didn't reply
ericp: ok, will do
... we have another issue with the grammar we need to figure
out what to do with
... if we change the grammar I expect we'd have another LC
ivan: would only be required if there is a design change, don't think this applies
ericp: issue is that the language changes
this is because we didn't manage to make it an LL1 grammar
<sandro> AndyS ?
gkellogg: it's a performance issue
<AndyS> Let's be concrete - ptr to rule?
ericp: in any case the grammar now appears to be different, allows n trailing semi colons
<gkellogg> [7] predicateObjectList ::= verb objectList (";" (predicateObjectList)?)*
ericp: need to dig back into the history
sandro: still don'
... still don't think this qualifies for 2nd LC
ivan: according to ralph we could make note of the change when going to CR and still go to CR
<sandro> Ivan: quoting Ralph Swick -- how about we just make this AT RISK then we can go to CR without solving this first
<AndyS> eric wants something more ... non recursive which is a tool issue.
<PatH> Well, that was easy.
ivan: this is a corner case that
doesn't seem worth losing weeks over
... very few implementers will actually be impacted
<gkellogg> Andy's rule: predicateObjectList ::= verb objectList (";" (predicateObjectList)?)?
andys: this matters to people who automatically produce data
sandro: as a user I would like the freedom of adding extra semi colons
gkellogg: I agree
ericp: we need to figure this out to exit LC
<sandro> http://www.w3.org/TR/turtle/#grammar-production-predicateObjectList
LC rule has a * at the end: predicateObjectList ::= verb objectList (';' predicateObjectList?)*
<gkellogg> [7] predicateObjectList ::= verb objectList ( ";" ( verb objectList)? )*
<PatH> It's semicolons all the way down.
<sandro> In LC: predicateObjectList ::= verb objectList (';' predicateObjectList?)*
sandys: we should focus on what
we want, instead of what we have
... do we want to allow multiple semi colons or not?
<sandro> sandro: lets do test cases that have multiple and trailing semicolons
<PatH> allowing <anything> has obvious advantages. Are there any reasons to prohibit multiple semicolons? If not, I suggest we decide to allow them.
ericp: we had one that worked as LR1, changed for LL1
<AndyS> SPARQL allows multiple semis
<AndyS> therefore I think Turtle should.
ericp: concerned about what it will do to people who write tools
sandro: can we resolve on doing
test cases for this?
... would like to have a resolution on what is allowed and not
allowed, then see if we can get a grammar that matches it
ericp: would rather try to figure out the grammar
sandro: can you write test cases so I can test my implementation?
<AndyS> If it is LL(1) it is LALR(1) if the first part of the rule is clean (the trailing part is irrelevant)
ericp: yes
<ericP> <a> <b> <c> ; ;
<ericP> <a> <b> <c> ; ; .
<PatH> wherever we are, I vote for it.
ericp: will send mail to I18N
giving a week for replying
... if we figure out the grammar by next week we can then
publish
<sandro> ACTION: sandro to produce an LALR grammar that supports "<a> <b> <c> ; ;" and "<a> <b> <c> ; ; ." [recorded in http://www.w3.org/2012/12/05-rdf-wg-minutes.html#action02]
<trackbot> Created ACTION-217 - Produce an LALR grammar that supports "<a> <b> <c> ; ;" and "<a> <b> <c> ; ; ." [on Sandro Hawke - due 2012-12-12].
<AndyS> Err - the submission was LALR(1)
ericp: yes, but we changed it since then
<markus> https://github.com/json-ld/json-ld.org/issues/157
markus: most controversial is issue-157
<markus> http://json-ld.org/spec/latest/json-ld-syntax/index.html#data-model
markus: trying to reuse the same terminology but there still are some differences
<markus> http://json-ld.org/spec/latest/json-ld-syntax/index.html#relationship-to-rdf
markus: also blank nodes are allowed as graph names, which isn't allowed in RDF
<ericP> can a datatype be a bnode?
markus: trying to address that with a note stating people shouldn't create such graphs
<PatH> eric: no.
<ericP> PatH, sorry, i meant in JSON-LD
<sandro> sandro: how about "it's not a JSON-LD document if it has a free-standing node"
<AndyS> can a graph name be a literal?
<PatH> Not inside a typed lieral, anyway.
<PatH> OK
sandro: why do you use SHOULD instead of MUST?
markus: trying to remain permissive
sandro: SHOULDs are trouble, and
I see more value in aligning with RDF
... not a showstopper but I would vote no
... looks good otherwise
markus: other minor differences,
like lists
... in json-ld there are arrays
... other issue is about graph vs dataset
<Zakim> davidwood, you wanted to discuss the JSON-LD data model
<davidwood> "Summarized these differences mean that JSON-LD is capable of serializing any RDF graph or dataset and most, but not all, JSON-LD documents can be transformed to RDF. "
davidwood: this statement means
to me that there is still a significant difference despite the
effort to minimize the diff
... is that a fundamental issue?
... or just syntactic?
markus: not sure
davidwood: if you state in the spec the difference is merely syntactic we don't have a problem
<PatH> Yup.
markus: but I don't think we can just reuse the RDF data model, because of where we allow blank nodes
<sandro> davidwood: is there a reason you need to allow blank nodes there?
<sandro> manu: it would be complicated to prevent
<sandro> davidwood: lots of RDF tools don't prevent it either.
gkellogg: if we don't need to enforce this in the algos then I think we can do that
<sandro> I'm also happy with the algorithms allowing it.
<AndyS> RDF/XML does not allow bNodes as predicates ... easy to add to Turtle, RDF/XML less so.
PatH: json-ld doesn't have the same limitations as RDF and it allows users to experiment, don't think we should discourage that
sandro: could have a strict mode
markus: that creates interoperability problems
andys: this isn't just about parsers, it also affects data producers
<AndyS> So does this matter: receive JSON-LD -> publish Turtle -> someone else converts to JSON-LD
davidwood: where does that this leave us?
sandro: not happy but don't blame them for doing this
ivan: I can live with it
sandro: would like a procedure check, maybe consider that AT RISK
davidwood: could certainly prompt the community for feedback on whether this is really a problem
ivan: could say that the algos
only work for generalized triples
... but ok with leaving it as is
... not a showstopper for me
<markus> https://github.com/json-ld/json-ld.org/issues/182
markus: another thing is graph vs dataset
<markus> http://json-ld.org/spec/latest/json-ld-syntax/index.html#relationship-to-rdf
<sandro> Essential -- is JSON restricted to RDF, or is it Generalized RDF Triples? *shrug* Either way is okay with me, but GRT will cause some big problems, I'm sure.
markus: resolved it saying a json-ld doc can be used as a graph store
ivan: how do I find out whether the doc I get from the web is a graph or data set?
markus: it's always a dataset with json-ld
<PatH> I like that. Everything on the Web is a dataset. that makes perfect sense.
ivan: whether it's in the default graph is up to the application
markus: yes
<PatH> LOL
<sandro> issue-105?
<trackbot> ISSUE-105 -- Graphs, datasets, authoritative representations, and content negotiation -- open
<trackbot> http://www.w3.org/2011/rdf-wg/track/issues/105
<yvesr> PatH, but then we might need to group datasets together or track their provenance, and we end up with datasets of datasets :)
sandro: I think proposed resolution would work, can we use the same thing for TRIGG?
gkellogg: I think the solution we came up with for json-ld should work generically
markus: will send an email on that to the mailing list later
sandro: I think there is an issue with that but will get it in email
<AndyS> TriG isn't a grammar superset of TTL so works less cleanly.
markus: algos are still first in the spec but not as prominent anymore
ivan: what about compliance section?
markus: define two products: 1: compliant to algos, 2: compliant to algos and apis
ivan: I think the approach to
separate json-ld processor is fine
... I'm fine with the content of the document but not the
title
markus: I think that's something
the wg can address
... any suggestions?
ivan: needs alcohol for that :)
<PatH> I have to leave. Use it well.
<markus> https://github.com/json-ld/json-ld.org/issues/178
davidwood: any other business for
today?
... meeting adjourned
<zwu2> bye
<manu> great work on the call today, markus! :)
<markus> thanks :-)
<manu> (as well as all of the editing work you've been doing - great job all around!) :)
<Guus> trackbot, end meeting
This is scribe.perl Revision: 1.137 of Date: 2012/09/20 20:19:01 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/eripc/ericp/ Succeeded: s/will ping Richard/will ping Richard Ishida/ Succeeded: s/about// Found Scribe: Arnaud Inferring ScribeNick: Arnaud Default Present: +1.540.898.aaaa, +31.20.598.aabb, yvesr, Arnaud, pchampin_, gkellogg, davidwood, ericP, MacTed, AndyS, markus, zwu2, ivan, +1.603.897.aadd, Sandro, PatH, manu Present: +1.540.898.aaaa +31.20.598.aabb yvesr Arnaud pchampin_ gkellogg davidwood ericP MacTed AndyS markus zwu2 ivan +1.603.897.aadd Sandro PatH manu Found Date: 05 Dec 2012 Guessing minutes URL: http://www.w3.org/2012/12/05-rdf-wg-minutes.html People with action items: davidwood sandro[End of scribe.perl diagnostic output]