RDF Working Group Teleconference -- 20 Jun 2012

<trackbot> Date: 20 June 2012

trackbot-ng, start telecon

<trackbot> Meeting: RDF Working Group Teleconference

<trackbot> Date: 20 June 2012

<scribe> scribenick: cgreer

<davidwood> Chair: David Wood

Admin

<davidwood> PROPOSED to accept the minutes of the 13 Jun telecon:

<davidwood> http://www.w3.org/2011/rdf-wg/meeting/2012-06-13

<AndyS> +1

Action Items

RESOLVED accepted minutes

<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

davidwood: look at open action items
... eric youve forgotten about frbr

ericp: frbr didnt have appropriate use cases

davidwood: please send email about that
... 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.

Turtle Last Call

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...

Turtle LC

<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.

<gkellogg> s/L17/LL1()/

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 semicolons...
... I'm successful with a production that allows infinite semicolons.

<ericP> an LL(1) of the form A (B C D)* B? -- (a single-letter representation of [7])

gkellogg: If it's not LL1 grammar, and the group intends to have one, we need to address that.
... 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?

<pchampin> q

<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 these grammars.
... 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> +1

<gkellogg> +1

<gavinc> [7] 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: [7] predicateObjectList ::= verb objectList ( ";" ( verb objectList)? )*

gavinc: Richard, could you talk about your feedback after call?

davidwood: Friday still reasonable?

gavinc: yes...

<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 limitation.
... 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 token.
... 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...

<gavinc> http://tools.ietf.org/html/bcp47#section-2.2.9

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>

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'

<gkellogg> +1

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 by Friday.
... 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.

JSON-LD

<AndyS> manu - good idea

<manu1> Actually, the editors should /definitely/ mark the grammar as an issue and say that it could change.

<cygri> AndyS++

<gavinc> AndyS++

manu1: We have four reviews in. This is good coverage.
... Most reviews have both major and minor issues, but nothing to hold up.

FPWD

<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 reviewers)
... 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:

<manu1> https://github.com/json-ld/json-ld.org/issues/135

<manu1> https://github.com/json-ld/json-ld.org/issues/136

<manu1> https://github.com/json-ld/json-ld.org/issues/137

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.

<gkellogg> +1

<cygri> cgreer, it's pchampin speaking

pchampin: We needed to position JSON-LD spec so as not to be explicitly linked to RDFa.

<manu1> http://json-ld.org/spec/latest/json-ld-syntax/#rdf

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 public-rdf-comments@w3.org (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 public-rdf-comments@w3.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.

RDF Spaces and Datasets

<davidwood> Deferred until next week

AOB

<gavinc> I think we have Defered Graphs not Named Graphs

<gavinc> Deferred too

<gavinc> No, we won't talk about Turtle

<zwu2> bye

<AZ> bye

rssagent, generate minutes

- DRAFT -

RDF Working Group Teleconference

20 Jun 2012

Attendees

Contents

Admin

Action Items

Turtle Last Call

Turtle LC

JSON-LD

RDF Spaces and Datasets

AOB

Summary of Action Items

Scribe.perl diagnostic output