See also: IRC log
<trackbot> Date: 20 June 2012
trackbot-ng, start telecon
<trackbot> Meeting: RDF Working Group Teleconference
<trackbot> Date: 20 June 2012
<scribe> scribenick: cgreer
<scribe> scribenick: cgreer
<davidwood> Chair: David Wood
<davidwood> PROPOSED to accept the minutes of the 13 Jun telecon:
RESOLVED accepted minutes
<davidwood> Review of action items
davidwood: look at open action
... eric youve forgotten about frbr
ericp: frbr didnt have appropriate use cases
davidwood: please send email
... guus is going to work on rdf spaces document and identify controversy
... he'll split it into rdf concepts and rdf semantics. It will hopefully be ready by next wednesday
<davidwood> Reminder: Summer schedule for telecons: 27 Jun, 11 July, 25 July, 8 August, 22 August, 5 September.
davidwood: we will have meeting next week. The next will be 11 July. Summer schedule, plan accordingly.
<ivan> regrets for next week, will be on a trip, and then on vacations in July...
<AndyS> Regrets for next week
ericP: There's still more
discussion to have about the grammar, issues around what
grammar will communicate decisions best.
... the BNF drops parans where it needs them. One other issue is text about tokens.
davidwood: how much left?
ericp: done by friday.
gavinc: no comments.
davidwood: Turtle will be better for this work
gkellogg: Have been working with LL(1), still an open issue: predicate-object list.
ericp: I mocked up an LL grammar. Greg thinks it's a tool issue.
ericp: I believe this should highlight behavior that Greg's tool should be exhibiting.
<AndyS> predicateObjectList ::= verb objectList (';' verb objectList)* ';'? is ambiguos - I proposed a better way to write it.
gavinc: I don't think this
grammar is the only grammar that can parse turtle. If it turns
out to be not LL1 that's not a bug.
... There are other grammars that can parse Turtle documents.
davidwood: There's more than one way. Do we know for certain that there is really an LL1 grammar?
gavinc: Yes, it's just not in the specification.
gkellogg: There's an older
version, with caveat that it allows multiple
... I'm successful with a production that allows infinite semicolons.
gkellogg: If it's not LL1
grammar, and the group intends to have one, we need to address
... Every other grammar I've used have been parsed with 'this type of parser'
davidwood: no matter what we come up with, there will be other ways to do it.
gkellogg: It this grammar is NOT LL1, then we need to see what the intention of the group is.
<SteveH> how would you prove that the grammar we publish, and some hypothetical LL(1) grammar were the same?
sandro: Some people want LALR,
some people want LL1. It doesn't make sense to provide both. It
would be a bad idea to provide both.
... Is there some preference for LL1?
<Zakim> ericP, you wanted to address LL-ness vs. LALR-ness
ericp: Previous versions of
SPARQL (neither LL1 nor LALR), but you can turn it into one of
... Has checked with peers about state table. Is the tool generating the state table correctly? I think not.
... The difference between LL1 and LALR handling was * and +
AndyS: Whether it's *+ not the
issue. There's an ambiguity about semicolon.
... Most LALR also have a pragmatic rule -- longer match over shorter match.
... I'll take action to make a rule.
<gavinc>  predicateObjectList ::= verb objectList (';' verb objectList)* ';'?
<gavinc> The rule in question
<AndyS> ACTION AndyS Draft a rule for predicateObjectList
<trackbot> Created ACTION-175 - Draft a rule for predicateObjectList [on Andy Seaborne - due 2012-06-27].
<gkellogg> my alternate:  predicateObjectList ::= verb objectList ( ";" ( verb objectList)? )*
gavinc: Richard, could you talk about your feedback after call?
davidwood: Friday still reasonable?
<AndyS> gkellog - yes - that is what SPARQL has an accepts many trailing ";" which seems (1) no big deal and (2) better for SPARQL/Turtle compatibility.
erikp: No more convenient expression of this rule. A reformulation will not make it easier for LALR parser.
AndyS: The reason the rule is a
problem -- when you have verb-object list there are two
branches for ';'
... Either new object list or end.
<gavinc> I found predicateObjectList ::= verb objectList ( ";" ( verb objectList)? )* to be perfectly fine
ericp: But you don't communicate with BNF. The ambiguity goes away with pasted grammar.
AndyS: I use LL1 tool to generate SPARQL grammar. I can see why bison would accept it.
ericp: I've been working in an LL parser -- perl Parse::RecDescent
??: This is not LL1
ericp: What if I try rewriting it.
<gavinc> This document WILL be done by the end of the week.
ivan: Will Eric be gone next week? What this means is that, if this doc is not done, we won't be done til August.
davidwood: publication freeze?
<AndyS> I withdraw my action.
davidwood: why did you withdraw your action?
ericp: If you want to supply the rule, I'm happy to have it.
AndyS: We've given our feedback.
gavinc: I don't mind restoring
previous rule. It allows for multiple semicolons. Many existing
parsers already allow this. SPARQL also doesn't have a
... I see no problem with infinite ';' following this production.
ericp: I don't much care either.
davidwood: If there's a clean way to do it, great. We won't hold up LC for this though.
ericp: There's a debate about -- whether to have rule that states that base and token are permitted as language tags.
gavinc: Other than riot, no
existint turtle parser allows @base or @prefix as languate
... any parsers that tries to specify this needs to allow for language tags that are not permissible.
richard: For 1.1, the reference for language tag has changed. The current one defines two things. The generic grammar...
richard: and spells out in detail
the admissible words and abbreviations.
... So since '@prefix' is not a language it's not a valid language tag.
ivan: We're spending time on very minute corner cases.
<manu1> +1 to Ivan!!!
ivan: What's simpler to write down and move on?
<SteveH> +1 to ivan
ericp: So if we don't care, there's a simple way to write it.
ericp: If you want to make it explicit... negative is harder than positive.
ivan: Whatever is simpler. Let's take first case where we don't care.
<SteveH> or we could say that it's undefined behaviour
<sandro> +1 not making any statement
ericp: Stating that it can happen is simpler. This may be simpler than no statement at all.
ivan: Whatever is simpler for editors.
<zwu2> +1 to SteveH
Sandro: If we define it we'd need a test case that could break parsers.
gavinc: And it would break compatibility with RDF 1.1
<gkellogg> suggest that it is specifically disallowed
sandro: I don't see that.
davidwood: And if it's undefined behavior?
ericp: The production for language tag subsumes @base and @prefix. Parsers may or may not accept it.
<MacTed> is this accurate summary?
<MacTed> 1. state it can happen. requires test cases... or statement that resulting behavior is undefined.
<MacTed> 2. state it cannot happen. requires test cases.
<MacTed> 3. say nothing.
<MacTed> ignore that, if problem is solved...
<SteveH> MacTed, it requires a comment, otherwise people will wonder
<LeeF> oh, by the way, +1 to ivan :-)
<AndyS> Don't test.
<SteveH> yeah, don't test
ericp: We're not saying whether it can happen. 'Don't Test'
davidwood: LC on Turtle LC
ericp: This simplifies rules we have to adopt from SPARQL. Lexer is expected to parse longest terminal it can.
<cygri> @base and @prefix are "reserved for future extensions" or "discouraged" in BCP47
<AndyS> BTW -- RIOT is recursive decent which is how it does @base as a language.
ivan: We seem to have resolution. Where are we for LC?
ericp: We're needing some text about @base and about terminals.
gavinc: Only remaining issue is resolving things with Richard.
ivan: Can we vote last call next week?
gavinc: We will have a document
... Confident about agreement with Richard by end of day.
<AndyS> As far as I am concerned, publishing with the right language but not-ideal grammar for that language is "editorial" and can grammar change after LC IMHO.
<manu1> AndyS - especially if we mark it as an issue in the document.
<AndyS> manu - good idea
<manu1> Actually, the editors should /definitely/ mark the grammar as an issue and say that it could change.
manu1: We have four reviews in.
This is good coverage.
... Most reviews have both major and minor issues, but nothing to hold up.
<Arnaud> sorry, I have to drop off
manu1: What issues markers we
want to put in, we must decide. Today, we need to hear from
Eric about what issued need to be outlined. (and other
... We're talking grammar fixes, nothing major. Then the documents will move into the final CG stamp, handing to this group within next week.
... With the IPR-- two issues. We need to hear what the issue markers are, and then we'll finalize and do IPR.
... The w3c form for IPR document is not working. Once Greg has edited the spec, then the documents will be frozen and we'll get the IPR committments.
davidwood: how comfortable that nobody else will have issues?
manu1: Comfortable. Anyone who
opened an issue has been accomodated.
... All the people who have contributed more than a paragraph have committed to IPR preliminarily.
<Zakim> ericP, you wanted to say i have two proposals: 1. move 1.3 to SOTD 2. in §3.1 ¶2, add "Issue: the term "object" is used represent both JSON objects and terms in the object
gkellogg: Use 'JSON Object' to avoid ambiguity of word 'object'
AndyS: Section 3.1 needs discussion by WG, but that's not a document issue.
<manu1> We are tracking the issues here, btw:
AZ: My issues can wait for version of document. The term 'property' is an issue for me, but there may have been other discussion. "Property" is not an "edge".
pchampin: Property is the label of the edge, not the edge itself.
<cygri> cgreer, it's pchampin speaking
pchampin: We needed to position JSON-LD spec so as not to be explicitly linked to RDFa.
davidwood: We do need to make the relationship between RDF and JSON-LD more clear. However, this doesn't need to affect your activities.
manu1: We did agree to put a section on RDF in the spec.
davidwood: We need something up front in the introduction. Even if it's a short paragraph with links.
manu1: We thought this would scare people away.
davidwood: I'm sure we can manage a sentence or two that wouldn't be scary to web developers.
<sandro> sentence that talk about "compatibility" might work.
<manu1> AndyS - both Semantic Web /and/ RDF scares people away (because they associate RDF with RDF/XML)
<ericP> clarification: we're not discussing a prerequisite for FPWD, right?
<zwu2> come on, it is OWL Full that is scary
pchampin: We can figure out some non-scary way to mention RDF.
davidwood: There was similar discussion about Turtle, and Dave B. made objection, Turtle will be better for the argument. RDF WG will have to mention RDF somewhere beyond the appendix.
manu1: I'm concerned more about marketing of the spec. We want it adopted as quietly as possible
MacTed: This is not a blocker for FPWD. Bait-and-switch doesn't do what we want.
davidwood: I said, just one or two sentences.
MacTed: But if it's not part of the FPWD process, we can not hold it up for this.
<pchampin> +1 to discuss the language later
<gavinc> Err.. it's going to say RDF in the STOD... yeah, what Ivan is saying :D
ivan: So the point is -- if you look at the document status. The RDF-WG will be right at the top of the document.
<gavinc> at the top of document it WILL say "This document was published by the RDF Working Group as an Editor's Draft. If you wish to make comments regarding this document, please send them to email@example.com (subscribe, archives). All feedback is welcome."
<sandro> ehhh -- NO ONE EVER reads the SOTD. :-)
ivan: A warning to Manu that this will happen.
<davidwood> From the current Turtle ED: "This document was published by the RDF Working Group as an Editor's Draft. If you wish to make comments regarding this document, please send them to firstname.lastname@example.org (subscribe, archives). All feedback is welcome."
<davidwood> I do *not* think that the Abstract needs to state, as the Turtle ED does, with "The Resource Description Framework (RDF) is a general-purpose language for representing information in the Web."
ivan: It's not completely hidden. If you want to add in the SOTD, that might be the best place to add RDF terminology.
manu1: Can we let this go for now? It should not affect FPWD.
davidwood: We can leave to editors.
<sandro> the SOTD could downplay it even more, like: "This document was published by the W3C JSON LD Task Force, under the supervision of the RDF Working Group, "
<sandro> or "with approval by the ... "
<ericP> i propose we add "we got you, sucka" after B.1
<cygri> lol @ericP
<manu1> ISSUE: Mention RDF in the JSON-LD Syntax Introduction.
<trackbot> Created ISSUE-92 - Mention RDF in the JSON-LD Syntax Introduction. ; please complete additional details at http://www.w3.org/2011/rdf-wg/track/issues/92/edit .
<ericP> "suckas" if we're feeling particularly cocky
<sandro> If you talk about RDF Compatibility as one of the advantages of JSON-LD, I don't think it'll bug anyone.
manu1: We'll get these edits done and have document by Wednesday.
davidwood: We need to close the issue, but it doesn't have to be a big issue.
manu1: It's important for RDF community to understand how people are adopting RDF. There are fringe communities, anti-RDF, who come around.
<gavinc> hey, danbri, your anti RDF? ;)
<manu1> no, not danbri!
<manu1> /other/ people at Google :)
<manu1> What is Linked Data? http://www.youtube.com/watch?v=4x_xzT5eF5Q&feature=g-upl
<manu1> What is JSON-LD? http://www.youtube.com/watch?v=vioCbTo3C-4&feature=g-upl
<Zakim> ericP, you wanted to ask if there are folks who have a way to evaluate these trade-offs
MacTed: There are people who build things similar to RDF, then come around realize it's really got something to bring to the table.
ericp: Who is good at such marketing?
manu1: The HTML5 people. They're great at marketing, speaking, telling people how easy it is.
<davidwood> Deferred until next week
<gavinc> I think we have Defered Graphs not Named Graphs
<gavinc> Deferred too
<gavinc> No, we won't talk about Turtle
rssagent, generate minutes
This is scribe.perl Revision: 1.136 of Date: 2011/05/12 12:01:43 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/end/send/ Succeeded: s/Tpoic/Topic/ Succeeded: s/??/ericP/ Succeeded: s/gcarothers/gavinc/ Succeeded: s/L17/LL(1)/ FAILED: s/L17/LL1()/ Succeeded: s/??/sandro/ Succeeded: s/LL1/LALR/ Succeeded: s/parse:rectisense/Parse::RecDescent/ Succeeded: s/davidwood/Sandro/ Succeeded: s/lable/label/ Succeeded: s/AZ/pchampin/ Found ScribeNick: cgreer Found ScribeNick: cgreer Inferring Scribes: cgreer WARNING: No "Present: ... " found! Possibly Present: AZ AlexHall AndyS Arnaud Guus ISSUE Ivan LeeF MacTed NickH OpenLink_Software P13 P18 P27 P36 P37 P4 P9 RDF Reminder ScottB Souri SteveH SteveH__ Tony aaaa aabb aacc aadd aaee aaff aagg aahh cgreer clarification cygri danbri davidwood ericP erikp gavinc gkellogg https joined manu manu1 mhausenblas of pchampin position rdf-wg richard sandro scribenick trackbot triples yvesr zwu2 You can indicate people for the Present list like this: <dbooth> Present: dbooth jonathan mary <dbooth> Present+ amy Found Date: 20 Jun 2012 Guessing minutes URL: http://www.w3.org/2012/06/20-rdf-wg-minutes.html People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]