<trackbot> Date: 08 May 2013

<scribe> scribe: gkellogg

guus: propose to resolve the minutes

RESOLVED accept minutes

Action items

guus: david and path claim completion of 3 open action items.

<pfps> I went through some of the old action items on Semantics and noted that they were done during the editing process.

<pfps> I think that there may be a couple more actions that are actually done, but that can be handled next week

JSON-LD

<davidwood> close ACTION-166

<trackbot> Closed ACTION-166 Remove list of XSD datatypes and related discussion from RDF Semantics (and reference the list in RDF Concepts instead, if appropriate).

<davidwood> close ACTION-170

<trackbot> Closed ACTION-170 Implement ISSUE-13 resolution (make rdf:XMLLiteral optional and interpret it only under D-Entailment).

guus: first item on planning for 2nd LC for JSON-LD API

<davidwood> close ACTION-257

<trackbot> Closed ACTION-257 Add resolution of issue-107 to RDF Concepts.

<davidwood> close ACTION-258

<trackbot> Closed ACTION-258 Update RDF Concepts to reflect issue-109.

<davidwood> close ACTION-259

<trackbot> Closed ACTION-259 Modify RDF Concepts in respect to ISSUE-126, see http://lists.w3.org/Archives/Public/public-rdf-wg/2013Apr/0118.html.

manu: at this point, we're coming out of LC for JSON-LD syntax and API.

… group has addressed all issues, but needs to respond to commenters.

… there are a couple of things which will cause the API to do a 2nd LC

… We had to change the API to use a futures-based API, as will be used by browser implementers.

… question is, how to push the other document forward.

… There are two proposals: we publish a 2nd LC for the API and keep syntax in limbo until API again comes out of LC, then proceed directly to PR

… We already have the CR requirements covered.

… We'll have 5 interoperable implementations by the end of next week.

… The first proposal is that we take JSON-LD-API through 2nd LC.

… the second is to push JSON-LD syntax to CR phase, but go through 2nd LC for API, then have them both go straight to PR.

… question for group, what do they want to do?

… The benefit for the second proposal is that we would have one document at CR.

guus: I think 2nd LC can be quick.

ivan: I think the fact that the 2 documents belong together is also an important message.

… I would be in favor of keeping them in sync, which implies the 1st proposal.

manu: the other thing, does the group feel we need CR, given that criteria are already covered?

guus: I've personally never done that.

<gavinc> Yes, there should be more feedback from the community as a whole.

ivan: it's possible.

sandro: sparql did this, and it wasn't a problem.

ericp: you do this when you already have the implementation report before CR transition request.

sandro: and you don't think the community needs more outreach, before their told it's too late.

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

manu: we do have an implementation report.

<markus> wouldn't moving syntax to CR give a heads up to people!?

ericp: LC is "we think we're done, let us know". CR is "last chance for people to contribute practical implementation experience"

… If you don't feel the community will be disenfranchised, then go ahead to PR.

manu: Andys might be interested in doing an implementation.

… Does anyone in this group need more time.

sandro: JSON-LD won't be real until it's implemented in all major frameworks.

… If Jena doesn't do JSON-LD, then no one will take it seriously.

… To be a mainstream implementation, it needs to be implemented by all the major implementations.

manu: one of the editors wanted a CR anyway.

sandro: it would be nice if when going to REC it's been implemented by all the major systems.

guus: time-wise, it's not a problem.

… I have a slight preference for a short CR period.

markus: 2nd LC is just because the browser API changed, otherwise, we wouldn't need it.

… my question is if it wouldn't help to move syntax to CR, as this might signal to the community that it is more mature.

sandro: moving to CR requires a director's meeting, so I'm hesitant to do 2 different meetings for related documents.

<ivan> +1 to Sandro

manu: the proposal is then to take API to LC2, and do 3-week LC2, and after that, take both syntax and API into CR (around 6/4)

… short CR period (3 weeks), and go into PR.

manu: propose to publish LC2 on 5/14 with a 3-week LC period, bringing us out on 6/4.

<gavinc> 2013-06-04 :P

<manu> PROPOSAL: Publish JSON-LD 1.0 API as a Second Last Call document on May 14th 2013 with a 3 week Last Call period.

… that would be may-14 entry and June-3 exit.

<manu> +1

+1

<pfps> +1

<ericP> +1

<ivan> +1

<markus> +1

<Guus> +1

<gavinc> +1

<Souri_> +1

<PatH> +1

<markus> what about syntax? do we need to re-publish it as well?

RESOLUTION: Publish JSON-LD 1.0 API as a Second Last Call document on May 14th 2013 with a 3 week Last Call period.

<tbaker> +1

manu: still need to do formal responses.

guus: make sure that it's on record to have them agree or live with it.

<Arnaud> belated +1

… This is one the road to being REC very soon, good work.

LC of concepts and semantics.

<markus> what about syntax? do we need to re-publish it as well?

<markus> that was my question :-)

<manu> markus: Nope, we don't need to re-publish it.

… there were several small editorial things.

<manu> markus: It'll just stay in limbo until JSON-LD 1.0 API comes out of LC2.

<markus> so we leave it there with a text saying that the last call ends this week?

<manu> yep

path: I thought we had agreed to take out talk about datatype maps.

david: I didn't address 118, I'm in the middle of doing that now.

<markus> ok

… I'm fine with 118, but have a question about references for defining vocabularies.

… I looked back at other places where we use reference without defining it.

… If we only use "reference" in the definition of a vocabulary, then we have a meaningless definition in the document.

… It's just in relationship to a vocabulary that you want to take it out?

PatH: yes, just in that case.

david: I'll make changes and check in shortly.

<pfps> It is perfectly fine for me to create an RDF vocabulary that doesn't have clearly defined referents.

guus: second point, description of entailment regimes.

<pfps> The ter Horst "semantics" is a completely different kettle of fish, what is being discussed is to have a set of entailment rules.

PatH: I've been looking at how to include the entailment rules in a more elegant way; I think AZ's point is a good one, put the rules in a table when they're mentioned.

… I'm in the process of doing that now, major surgery on the text, but not on the content. that will take a few more days.

guus: what about ivan's point of including the ter Horst work?

<pfps> By the way, there has to be some new stuff in the rules because of datatypes.

PatH: you need the generalization to get it to work. You allow the rules to apply to a more general syntax, which allows literals in subject position, and BNodes in predicte position.

<pfps> You don't really need the ter Horst generalization to make a full set of rules - however, it would make the rules harder to state.

… The cases you miss without that are pretty obscure.

… We can then add a section at the end that uses the non-legal RDF bits separate.

… The actual statement of the rules when you remark that they apply to the same general syntax.

… It might be good to wait until I have it done so that people can read it.

… The proposal is that rules are stated in line as tables when introduced.

… A later section discusses completeness and necessary generalizations that are required.

pfps: I appreciate putting the rules inline has an appeal to it, but I'm not in favor of it, as they're non-normative, but in the middle of normative sections.

… putting the incomplete rules back in is just inviting back in a min-firestorm amongst the 5 people who care :)

<SteveH> leaving them out could be controversial too though…

PatH: I was going to suggest taking the ter Horst rules.

<AndyS> The rules are what many (other!) people go to first.

pfps: making them an appendix would be fine, as they're non-normative, and can be linked to.

… There are also going to more rules because of datatypes.

PatH: yes, and we have to be clear to not dis-claim completeness WRT datatypes.

pfps: we can change appendices later in the game, but normative stuff is more difficult.

guus: I'm happy to leave it to both of you to sort this out.

pfps: PatH's write that we should wait until there's something close to being too beeing before continuing.

sandro: I was unhappy with one of PatH's changes, but I think it's okay.

david: I have some uncommitted changes, and I've taken out the offending paragraph.

… I'm considering that a document of length zero might have some value :)

sandro: I think the document is great.

david: cygri did most of the heavy lifting.

<Zakim> davidwood, you wanted to ask PatH a question about datatype maps

david: WRT datatype map, I want to be sure I understand PatH's proposal.

… You're proposing to replace 5.4 with a new section on datatype IRIs.

… We have a bunch of places in the document where we refer back to datatype maps. I think we can replace most of those references with something like referenced to defined datatype IRIs when defined.

PatH: the datatype IRI then denotes the datatype.

guus: language tags, which started from a proposal of AndyS.

AndyS: the trouble with language tags is that there is a semi-canonical representation which RDF doesn't follow.

… This means that parsing with string tools can be tricky.

… It's an abstract concept, and there are many ways to deal with it.

… The odd thing is that they're hard-baked into RDF somewhat like XML Literals, rather than dealing with an abstract value space.

<Zakim> ericP, you wanted to say i'd like to encourage round-tripping

ericP: the current text (old) said they were lower case for the purposes of comparison.

… for UI resins, there's an argument for preserving case because the RFC says you should use the registered tags for regions and something else.

… I we lowercase them, then we're changing the recommended representation.

… I'd like to see something that does case-folding and preserves the representation.

pfps: I believe I agree with AndyS after having an argument with myself.

… I originally thought the old design was the best, but it seems to me that the discussion should be changed that language tags are equal if they're equal according to the language tag document.

<gavinc> There is less utility in not changing when implementations ignored the recommendation ;)

… We could say that implementations can lower-case everything and use string equality.

PatH: what about a language tag in RDF syntax that's completely legal, such as @27.1?

sandro: that should be a syntax error.

<ericP> "abcd"@1234

<gavinc> No.

PatH: this means that RDF parse needs to check the space?

<pfps> As far as semantics is concerned there is no issue.

… There'a an argument that the abstract syntax should not be sensitive.

<AndyS> I have come across ""@419es in freebase

sandro: if we changed this, then Turtle couldn't serialize every RDF graph.

<ericP> Turtle language tag constraints

<ericP> '@' [a-zA-Z]+ ('-' [a-zA-Z0-9]+)*

<AndyS> RFC3066 rule (old RFC) -- BCP47 is more complicated.

PatH: we can add some thing to indicate that a badly formed language tag is non-conforming.

sandro: the only issue is what defines "badly formed"? ericP's regexp is okay.

<AndyS> RFC5646 = BCP47

gavinc: the RFC says you can use the old rules, which is what Turtle uses.

<Guus> ACTION davidwood to add text to Concepts that bad language tag is a syntax error

<trackbot> Created ACTION-262 - Add text to Concepts that bad language tag is a syntax error [on David Wood - due 2013-05-15].

sandro: is it okay for people not to read BCP47?

gavinc: meh

<AndyS> RFC 3066 is 8*ALPHA (- 8*ALPHA)*

david: I proposed to include both the regexp and the reference.

<AndyS> not unlimited length

<PatH> I will have to leave the meeting early today, sorry.

<gavinc> AndyS, meh ;)

<ericP> and, unlike Turtle, prohibits [0-9]

<ericP> (which turtle permits on subtypes)

ericP: I'm not sure that I have consensus that we should down-case everything.

… We should say the comparison is case-insensitive, but we don't have to downcase everything.

… the commenter was okay with this.

<Zakim> AndyS, you wanted to ask (rhetorically) what rule system do.

AndyS: what do real systems do? If they're storing language tags that differ only in case as presented, then you'll get two terms, and we should reflect on that, as N-Triples has changed it's role somewhat.

… will users want what the put in to come out again. It's a fairly permanent meme

<gavinc> <http://example.org/> <http://example.org/> "cool"@en .

<gavinc> <http://example.org/> <http://example.org/> "cool"@EN .

<gavinc> rapper: Parsing returned 2 triples

<pfps> was that a disjointness claim?

<ericP> SWObjects: { <s> <p> "o"@en, "o"@EN } -> { <s> <p> "o"@en } by route of the first parsed winning

<PatH> I can imagine an applicaiton that stores tags in UC for its own reasons being very upset by forced normalization. Suggest we use principle of minimal intervention.

<gavinc> I don't care about RDF 2004 ;) I care about current implementations.

pfps: according to RDF 2004, literals which differ only in the case of the language tag are the same literal.

<gavinc> That DID change.

<AndyS> Jena stores two, so not equals, but tests sameValueAs

… If that changes, then many other things have to change

<gavinc> -1 to SHOULD lowercase

sandro: another path is to say you SHOULD put things in lowercase.

ericp: you're aware that BCP recommends just the opposite.

<SteveH> we can't guarantee to maintain the case, FWIW

sandro: us guaranteeing to maintain the case is a real implementation burden.

<PatH> x:a x:b "foo"@en . x:a x:b "foo"@EN . is one or two triples?

gavinc: in a look around, Jena, Rapper, and most others keep all the forms.

… they just store how it was entered.

sandro: so they can't just do a byte-compare.

… You can no longer have a hash of the triple. (you lower-case to hash it).

<SteveH> lower case when you hash it isn't sufficient

AndyS: you can compare two different types, when they come in and when queried.

<ericP> CR comments "Language Tag Case Conflict" from Hong Sun

pfps: looking at what systems do… If I stick two language tag triples into Jena, do I get back out 1 or 2 triples.

… This is a spec violation.

<gavinc> Yes, they are violating the spec ;)

<PatH> Please don't say "value"

sandro: the cleanest way is to treat it as with other values, difference between literal equality and value equality.

AndyS: we have to talk about the value space of RDFLangString anyway, so there's a place to talk about it.

PatH: If language tagged strings really were a datatype, then we could handle this neatly by creating a special datatype, but oh well...

AndyS: it's just about defining the value space.

<gavinc> Why not?

PatH: we're not allowed to do this.

<gavinc> Why can't we say that?

… I'll take a look, though.

ericP: would it just be easier to say that they're compared case-insensitively. It's ASCII, so it's pretty simple.

<SteveH> we can't guarantee to maintain the case, FWIW

<sandro> SteveH, if casefolding isn't enough, please speak up

<SteveH> I don't think we're the only ones

<PatH> I have to leave...

AndyS: some systems will choose to do that, and the first one wins.

<sandro> so changing the case is like skolemizing -- it's a fairly harmless bit of graph-changing.

… I don't think we can change what systems really do.

guus: leave further discussion to the list.

<gavinc> anyway, if you MEAN to do language comparing http://www.w3.org/TR/2013/REC-sparql11-query-20130321/#func-langMatches ;)

<SteveH> I also recognise that users might expect it to be preserved

… I'd like to see if we can get reviewers for concepts and semantics.

<AndyS> "… I don't think we will change what systems actually do."

<ericP> gavinc, langMatches includes subsumption reasoning

… We need reviews for both of them. I'm happy to review concepts.

pfps: I'll review concepts.

<gavinc> ericP, yes. That was my pont.

ivan: when are the reviews?

<ericP> e.g. langMatches("en-us", "en") => true (or maybe reversed parms, i can't remmeber)

<ericP> gotcha

<AndyS> All these use models are reasonable.

guus: reviews in two weeks?

pfps: version might be available in a week.

guus: by end of next week.

ivan: I can look at semantics the week after.

guus: we should ask AZ.
... it would be good to have an LC package, and I think it makes sense to include TriG. Then to have semantics, concepts and TriG.

<gavinc> Yay!

sandro: I'm anxious about TriG, and I think we'll have some feedback.

… I did a rough presentation on LDP, and trying to write up coherent feedback.

<sandro> (from LDP)

<gavinc> I guess that means I have to write how to parse it ;)

sandro: I think we can use the syntax as long as we don't change it, and we shouldn't need to.

<AndyS> bye all

guus: we're getting close to finalizing the work.

<Guus> trackbot, end meeting

This is scribe.perl Revision: 1.138  of Date: 2013-04-25 13:59:11  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/we a text/with a text/
Succeeded: s/???/ter Horst/
Succeeded: s/real/rule/
Succeeded: s/rule-systems/real systems/
Succeeded: s/differ only in/differ only in the case of the/
Succeeded: s/language tags/language tags that differ only in case/
Found Scribe: gkellogg
Inferring ScribeNick: gkellogg
Default Present: +1.408.992.aaaa, GavinC, Ivan, AndyS, gkellogg, ericP, Sandro, Guus, manu, +1.540.898.aabb, davidwood, SteveH, markus, Souri, Arnaud, TallTed, PatH
Present: +1.408.992.aaaa GavinC Ivan AndyS gkellogg ericP Sandro Guus manu +1.540.898.aabb davidwood SteveH markus Souri Arnaud TallTed PatH
Found Date: 08 May 2013
Guessing minutes URL: http://www.w3.org/2013/05/08-rdf-wg-minutes.html
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.