14:59:21 <RRSAgent> RRSAgent has joined #rdf-wg
14:59:21 <RRSAgent> logging to http://www.w3.org/2013/05/08-rdf-wg-irc
14:59:23 <trackbot> RRSAgent, make logs world
14:59:24 <Zakim> Zakim has joined #rdf-wg
14:59:25 <trackbot> Zakim, this will be 73394
14:59:25 <Zakim> ok, trackbot; I see SW_RDFWG()11:00AM scheduled to start in 1 minute
14:59:26 <trackbot> Meeting: RDF Working Group Teleconference
14:59:27 <trackbot> Date: 08 May 2013
15:00:26 <AndyS> zakim, who is on the phone?
15:00:26 <Zakim> SW_RDFWG()11:00AM has not yet started, AndyS
15:00:28 <Zakim> On IRC I see RRSAgent, gavinc, gkellogg, tbaker, Guus, pfps, AndyS, markus, TallTed, SteveH, ivan, davidwood, cygri, manu1, sandro, trackbot, yvesr, manu, ericP, mischat
15:00:46 <AndyS> zakim, who is on the phone?
15:00:46 <Zakim> SW_RDFWG()11:00AM has not yet started, AndyS
15:00:48 <Zakim> On IRC I see RRSAgent, gavinc, gkellogg, tbaker, Guus, pfps, AndyS, markus, TallTed, SteveH, ivan, davidwood, cygri, manu1, sandro, trackbot, yvesr, manu, ericP, mischat
15:01:10 <AndyS> zakim, this is 73394
15:01:10 <Zakim> ok, AndyS; that matches SW_RDFWG()11:00AM
15:01:18 <AndyS> zakim, who is on the phone?
15:01:18 <Zakim> On the phone I see ??P0, +1.408.992.aaaa, GavinC, [IPcaller], [GVoice]
15:01:22 <Zakim> +??P8
15:01:28 <AndyS> zakim, IPCaller is me
15:01:28 <Zakim> +Ivan
15:01:28 <Zakim> +AndyS; got it
15:01:31 <gkellogg> zakim, I am ??P8
15:01:31 <Zakim> +gkellogg; got it
15:01:45 <ericP> Zakim, [GVoice] is me
15:01:45 <Zakim> +ericP; got it
15:01:45 <Guus> zakim, ?P0 is me
15:01:46 <Zakim> sorry, Guus, I do not recognize a party named '?P0'
15:02:09 <Zakim> +Sandro
15:02:14 <Guus> zakim, ??P0 is me
15:02:14 <Zakim> +Guus; got it
15:03:00 <gkellogg> scribe: gkellogg
15:03:08 <Zakim> +??P10
15:03:11 <manu> zakim, I am ??p10
15:03:11 <Zakim> +manu; got it
15:03:33 <Zakim> + +1.540.898.aabb
15:03:41 <Guus> chair: Guus
15:03:44 <davidwood> Zakim, aabb is me
15:03:44 <Zakim> +davidwood; got it
15:03:56 <markus> zakim, code?
15:03:56 <Zakim> the conference code is 73394 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), markus
15:04:23 <Zakim> +??P16
15:04:30 <SteveH> Zakim, ??P16 is me
15:04:32 <Zakim> +SteveH; got it
15:04:33 <Zakim> +??P18
15:04:36 <markus> zakim, ??P18 is me
15:04:36 <Zakim> +markus; got it
15:04:39 <gkellogg> guus: propose to resolve the minutes
15:04:59 <Arnaud> Arnaud has joined #rdf-wg
15:04:59 <gkellogg> RESOLVED accept minutes
15:05:13 <Zakim> +Souri
15:05:31 <gkellogg> topic: Action items
15:05:34 <Souri> Souri has joined #rdf-wg
15:05:35 <Zakim> +Arnaud
15:05:55 <gkellogg> guus: david and path claim completion of 3 open action items.
15:06:04 <pfps> I went through some of the old action items on Semantics and noted that they were done during the editing process.
15:06:29 <Zakim> +OpenLink_Software
15:06:34 <pfps> I think that there may be a couple more actions that are actually done, but that can be handled next week
15:06:37 <gkellogg> topic: JSON-LD
15:06:42 <TallTed> Zakim, OpenLink_Software is temporarily me
15:06:42 <Zakim> +TallTed; got it
15:06:45 <TallTed> Zakim, mute me
15:06:45 <Zakim> TallTed should now be muted
15:06:47 <davidwood> close ACTION-166
15:06:48 <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).
15:06:54 <davidwood> close ACTION-170
15:06:54 <trackbot> Closed ACTION-170 Implement ISSUE-13 resolution (make rdf:XMLLiteral optional and interpret it only under D-Entailment).
15:07:00 <gkellogg> guus: first item on planning for 2nd LC for JSON-LD API
15:07:05 <davidwood> close ACTION-257
15:07:05 <trackbot> Closed ACTION-257 Add resolution of issue-107 to RDF Concepts.
15:07:09 <davidwood> close ACTION-258
15:07:09 <trackbot> Closed ACTION-258 Update RDF Concepts to reflect issue-109.
15:07:12 <davidwood> close ACTION-259
15:07:12 <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.
15:07:23 <gkellogg> manu: at this point, we're coming out of LC for JSON-LD syntax and API.
15:07:38 <gkellogg> … group has addressed all issues, but needs to respond to commenters.
15:07:46 <PatH> PatH has joined #rdf-wg
15:07:51 <gkellogg> … there are a couple of things which will cause the API to do a 2nd LC
15:08:13 <gkellogg> … We had to change the API to use a futures-based API, as will be used by browser implementers.
15:08:27 <gkellogg> … question is, how to push the other document forward.
15:08:35 <Zakim> +PatH
15:09:02 <gkellogg> … 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
15:09:14 <gkellogg> … We already have the CR requirements covered.
15:09:27 <gkellogg> … We'll have 5 interoperable implementations by the end of next week.
15:09:42 <gkellogg> … The first proposal is that we take JSON-LD-API through 2nd LC.
15:10:17 <gkellogg> … 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.
15:10:27 <gkellogg> … question for group, what do they want to do?
15:10:39 <gkellogg> … The benefit for the second proposal is that we would have one document at CR.
15:10:51 <gkellogg> guus: I think 2nd LC can be quick.
15:11:06 <gkellogg> ivan: I think the fact that the 2 documents belong together is also an important message.
15:11:23 <gkellogg> … I would be in favor of keeping them in sync, which implies the 1st proposal.
15:11:39 <gkellogg> manu: the other thing, does the group feel we need CR, given that criteria are already covered?
15:11:47 <gkellogg> guus: I've personally never done that.
15:11:57 <gavinc> Yes, there should be more feedback from the community as a whole.
15:12:04 <gkellogg> ivan: it's possible.
15:12:12 <gkellogg> sandro: sparql did this, and it wasn't a problem.
15:12:21 <Souri_> Souri_ has joined #rdf-wg
15:12:30 <gkellogg> ericp: you do this when you already have the implementation report before CR transition request.
15:12:57 <gkellogg> sandro: and you don't think the community needs more outreach, before their told it's too late.
15:12:59 <manu> http://json-ld.org/test-suite/reports/
15:13:05 <gkellogg> manu: we do have an implementation report.
15:13:19 <markus> wouldn't moving syntax to CR give a heads up to people!?
15:13:32 <gkellogg> ericp: LC is "we think we're done, let us know". CR is "last chance for people to contribute practical implementation experience"
15:13:47 <gkellogg> … If you don't feel the community will be disenfranchised, then go ahead to PR.
15:14:11 <gkellogg> manu: Andys might be interested in doing an implementation.
15:14:19 <gkellogg> … Does anyone in this group need more time.
15:14:40 <gkellogg> sandro: JSON-LD won't be real until it's implemented in all major frameworks.
15:14:52 <gkellogg> … If Jena doesn't do JSON-LD, then no one will take it seriously.
15:15:13 <gkellogg> … To be a mainstream implementation, it needs to be implemented by all the major implementations.
15:15:22 <gkellogg> manu: one of the editors wanted a CR anyway.
15:15:41 <markus> q+
15:15:41 <gkellogg> sandro: it would be nice if when going to REC it's been implemented by all the major systems.
15:15:49 <gkellogg> guus: time-wise, it's not a problem.
15:15:59 <gkellogg> … I have a slight preference for a short CR period.
15:16:17 <gkellogg> markus: 2nd LC is just because the browser API changed, otherwise, we wouldn't need it.
15:16:18 <Guus> ack markus
15:16:44 <gkellogg> … 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.
15:17:01 <gkellogg> sandro: moving to CR requires a director's meeting, so I'm hesitant to do 2 different meetings for related documents.
15:17:03 <ivan> +1 to Sandro
15:17:51 <gkellogg> 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)
15:18:02 <gkellogg> … short CR period (3 weeks), and go into PR.
15:18:55 <gkellogg> manu: propose to publish LC2 on 5/14 with a 3-week LC period, bringing us out on 6/4.
15:19:40 <gavinc> 2013-06-04 :P
15:19:48 <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.
15:19:52 <gkellogg> … that would be may-14 entry and June-3 exit.
15:20:06 <manu> +1
15:20:07 <gkellogg> +1
15:20:08 <pfps> +1
15:20:10 <ericP> +1
15:20:11 <ivan> +1
15:20:11 <markus> +1
15:20:16 <Guus> +1
15:20:18 <gavinc> +1
15:20:18 <Souri_> +1
15:20:25 <PatH> +1
15:20:28 <markus> what about syntax? do we need to re-publish it as well?
15:20:39 <gkellogg> RESOLVED: Publish JSON-LD 1.0 API as a Second Last Call document on May 14th 2013 with a 3 week Last Call period.
15:20:44 <tbaker> +1
15:20:51 <gkellogg> manu: still need to do formal responses.
15:21:07 <gkellogg> guus: make sure that it's on record to have them agree or live with it.
15:21:29 <Arnaud> belated +1
15:21:40 <gkellogg> … This is one the road to being REC very soon, good work.
15:22:01 <gkellogg> topic: LC of concepts and semantics.
15:22:02 <markus> what about syntax? do we need to re-publish it as well?
15:22:08 <markus> that was my question :-)
15:22:12 <manu> markus: Nope, we don't need to re-publish it.
15:22:15 <gkellogg> … there were several small editorial things.
15:22:25 <manu> markus: It'll just stay in limbo until JSON-LD 1.0 API comes out of LC2.
15:22:29 <markus> so we leave it there we a text saying that the last call ends this week?
15:22:35 <manu> yep
15:22:39 <gkellogg> path: I thought we had agreed to take out talk about datatype maps.
15:22:44 <markus> s/we a text/with a text/
15:22:54 <gkellogg> david: I didn't address 118, I'm in the middle of doing that now.
15:23:00 <markus> ok
15:23:29 <gkellogg> … I'm fine with 118, but have a question about references for defining vocabularies.
15:23:44 <gkellogg> … I looked back at other places where we use reference without defining it.
15:24:06 <gkellogg> … If we only use "reference" in the definition of a vocabulary, then we have a meaningless definition in the document.
15:24:19 <gkellogg> … It's just in relationship to a vocabulary that you want to take it out?
15:24:26 <gkellogg> PatH: yes, just in that case.
15:24:41 <sandro> q+
15:24:44 <Zakim> -manu
15:24:54 <gkellogg> david: I'll make changes and check in shortly.
15:24:55 <pfps> It is perfectly fine for me to create an RDF vocabulary that doesn't have clearly defined referents.
15:25:09 <gkellogg> guus: second point, description of entailment regimes.
15:25:51 <pfps> The ter Horst "semantics" is a completely different kettle of fish, what is being discussed is to have a set of entailment rules.
15:25:53 <pfps> q+
15:25:54 <gkellogg> 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.
15:26:11 <gkellogg> … 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.
15:26:28 <gkellogg> guus: what about ivan's point of including the ??? work?
15:26:33 <pfps> By the way, there has to be some new stuff in the rules because of datatypes.
15:26:38 <ivan> s/???/ter Horst/
15:27:08 <gkellogg> 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.
15:27:15 <sandro> q+ sandro2 to ask about copyright on terHorst
15:27:17 <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.
15:27:21 <gkellogg> … The cases you miss without that are pretty obscure.
15:27:38 <sandro> q- sandro2
15:27:44 <gkellogg> … We can then add a section at the end that uses the non-legal RDF bits separate.
15:28:02 <davidwood> q+ to ask PatH a question about datatype maps
15:28:03 <gkellogg> … The actual statement of the rules when you remark that they apply to the same general syntax.
15:28:37 <gkellogg> … It might be good to wait until I have it done so that people can read it.
15:29:00 <gkellogg> … The proposal is that rules are stated in line as tables when introduced.
15:29:16 <Guus> ack sandro
15:29:18 <gkellogg> … A later section discusses completeness and necessary generalizations that are required.
15:29:36 <Guus> ack pfps
15:29:53 <gkellogg> 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.
15:30:22 <gkellogg> … putting the incomplete rules back in is just inviting back in a min-firestorm amongst the 5 people who care :)
15:30:34 <SteveH> leaving them out could be controversial too though…
15:30:49 <gkellogg> PatH: I was going to suggest taking the ter Horst rules.
15:30:59 <AndyS> The rules are what many (other!) people go to first.
15:31:04 <gkellogg> pfps: making them an appendix would be fine, as they're non-normative, and can be linked to.
15:31:22 <gkellogg> … There are also going to more rules because of datatypes.
15:31:37 <gkellogg> PatH: yes, and we have to be clear to not dis-claim completeness WRT datatypes.
15:31:58 <gkellogg> pfps: we can change appendices later in the game, but normative stuff is more difficult.
15:32:07 <gkellogg> guus: I'm happy to leave it to both of you to sort this out.
15:32:42 <gkellogg> pfps: PatH's write that we should wait until there's something close to being too beeing before continuing.
15:33:09 <gkellogg> sandro: I was unhappy with one of PatH's changes, but I think it's okay.
15:33:29 <gkellogg> david: I have some uncommitted changes, and I've taken out the offending paragraph.
15:33:41 <gkellogg> … I'm considering that a document of length zero might have some value :)
15:33:57 <gkellogg> sandro: I think the document is great.
15:34:07 <gkellogg> david: cygri did most of the heavy lifting.
15:34:29 <Guus> ack davidwood
15:34:29 <Zakim> davidwood, you wanted to ask PatH a question about datatype maps
15:34:42 <gkellogg> david: WRT datatype map, I want to be sure I understand PatH's proposal.
15:34:55 <gkellogg> … You're proposing to replace 5.4 with a new section on datatype IRIs.
15:35:27 <gkellogg> … 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.
15:35:40 <gkellogg> PatH: the datatype IRI then denotes the datatype.
15:36:10 <gkellogg> guus: language tags, which started from a proposal of AndyS.
15:36:39 <gkellogg> AndyS: the trouble with language tags is that there is a semi-canonical representation which RDF doesn't follow.
15:36:49 <gkellogg> … This means that parsing with string tools can be tricky.
15:37:03 <gkellogg> … It's an abstract concept, and there are many ways to deal with it.
15:37:28 <gkellogg> … The odd thing is that they're hard-baked into RDF somewhat like XML Literals, rather than dealing with an abstract value space.
15:37:39 <ericP> q+ to say i'd like to encourage round-tripping
15:37:42 <pfps> q+
15:37:54 <Guus> ack ericP
15:37:54 <Zakim> ericP, you wanted to say i'd like to encourage round-tripping
15:38:09 <gkellogg> ericP: the current text (old) said they were lower case for the purposes of comparison.
15:38:31 <PatH> q+
15:38:51 <gkellogg> … 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.
15:39:13 <gkellogg> … I we lowercase them, then we're changing the recommended representation.
15:39:32 <gkellogg> … I'd like to see something that does case-folding and preserves the representation.
15:39:32 <Guus> ack pfps
15:39:52 <gkellogg> pfps: I believe I agree with AndyS after having an argument with myself.
15:40:26 <gkellogg> … 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.
15:40:27 <gavinc> There is less utility in not changing when implementations ignored the recommendation ;)
15:40:29 <AndyS> q+ to ask (rhetorically) what real system do.
15:40:34 <Guus> ack PatH
15:40:41 <gkellogg> … We could say that implementations can lower-case everything and use string equality.
15:41:06 <gkellogg> PatH: what about a language tag in RDF syntax that's completely legal, such as @27.1?
15:41:23 <gkellogg> sandro: that should be a syntax error.
15:41:26 <ericP> "abcd"@1234
15:41:27 <gavinc> No.
15:41:37 <gkellogg> PatH: this means that RDF parse needs to check the space?
15:41:40 <pfps> As far as semantics is concerned there is no issue.
15:42:00 <gkellogg> … There'a an argument that the abstract syntax should not be sensitive.
15:42:08 <AndyS> I have come across ""@419es in freebase
15:42:15 <gkellogg> sandro: if we changed this, then Turtle couldn't serialize every RDF graph.
15:42:21 <ericP> -> http://www.w3.org/TR/turtle/#grammar-production-LANGTAG Turtle language tag constraints
15:42:28 <ericP> '@' [a-zA-Z]+ ('-' [a-zA-Z0-9]+)*
15:42:55 <AndyS> RFC3066 rule (old RFC) -- BCP47 is more complicated.
15:43:01 <gkellogg> PatH: we can add some thing to indicate that a badly formed language tag is non-conforming.
15:43:22 <gkellogg> sandro: the only issue is what defines "badly formed"? ericP's regexp is okay.
15:43:26 <AndyS> RFC5646  = BCP47
15:43:39 <gkellogg> gavinc: the RFC says you can use the old rules, which is what Turtle uses.
15:43:49 <Guus> ACTION davidwood to add text to Concepts that bad language tag is a syntax error
15:43:49 <trackbot> Created ACTION-262 - Add text to Concepts that bad language tag is a syntax error [on David Wood - due 2013-05-15].
15:44:08 <gkellogg> sandro: is it okay for people not to read BCP47?
15:44:15 <gkellogg> gavinc: meh
15:44:19 <AndyS> RFC 3066 is 8*ALPHA (- 8*ALPHA)*
15:44:32 <gkellogg> david: I proposed to include both the regexp and the reference.
15:44:34 <AndyS> not unlimited length
15:44:48 <PatH> I will have to leave the meeting early today, sorry.
15:44:58 <gavinc> AndyS, meh ;)
15:45:00 <ericP> and, unlike Turtle, prohibits [0-9]
15:45:21 <ericP> (which turtle permits on subtypes)
15:45:42 <gkellogg> ericP: I'm not sure that I have consensus that we should down-case everything.
15:46:01 <gkellogg> … We should say the comparison is case-insensitive, but we don't have to downcase everything.
15:46:02 <pfps> q+
15:46:07 <gkellogg> … the commenter was okay with this.
15:46:15 <AndyS> ack me
15:46:15 <Zakim> AndyS, you wanted to ask (rhetorically) what real system do.
15:46:28 <Guus> ack AndyS
15:46:57 <gkellogg> AndyS: what do rule-systems do? If they're storing language tags as presented, then you'll get two terms, and we should reflect on that, as N-Triples has changed it's role somewhat.
15:47:21 <gkellogg> … will users want what the put in to come out again. It's a fairly permanent meme
15:47:25 <gavinc> <http://example.org/> <http://example.org/> "cool"@en .
15:47:26 <gkellogg> s/real/rule/
15:47:26 <gavinc> <http://example.org/> <http://example.org/> "cool"@EN .
15:47:28 <gavinc> rapper: Parsing returned 2 triples
15:47:34 <pfps> was that a disjointness claim?
15:47:42 <Guus> ack pfps
15:47:43 <ericP> SWObjects: { <s> <p> "o"@en, "o"@EN } -> { <s> <p> "o"@en } by route of the first parsed winning
15:47:52 <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.
15:48:15 <gavinc> I don't care about RDF 2004 ;) I care about current implementations.
15:48:19 <gkellogg> pfps: according to RDF 2004, literals which differ only in language tag are the same literal.
15:48:21 <ivan> s/rule-systems/real systems/
15:48:22 <gavinc> That DID change.
15:48:30 <AndyS> Jena stores two, so not equals, but tests sameValueAs
15:48:32 <gkellogg> … If that changes, then many other things have to change
15:48:46 <gavinc> -1 to SHOULD lowercase
15:48:51 <gkellogg> sandro: another path is to say you SHOULD put things in lowercase.
15:49:00 <pfps> s/differ only in/differ only in the case of the/
15:49:07 <gkellogg> ericp: you're aware that BCP recommends just the opposite.
15:49:22 <SteveH> we can't guarantee to maintain the case, FWIW
15:49:25 <gkellogg> sandro: us guaranteeing to maintain the case is a real implementation burden.
15:49:29 <PatH> x:a x:b "foo"@en . x:a x:b "foo"@EN . is one or two triples?
15:49:46 <gkellogg> gavinc: in a look around, Jena, Rapper, and most others keep all the forms.
15:50:05 <gkellogg> … they just store how it was entered.
15:50:18 <gkellogg> sandro: so they can't just do a byte-compare.
15:50:24 <pfps> q+
15:50:30 <pfps> q+
15:50:36 <gkellogg> … You can no longer have a hash of the triple. (you lower-case to hash it).
15:50:54 <SteveH> lower case when you hash it isn't sufficient
15:50:56 <gkellogg> AndyS: you can compare two different types, when they come in and when queried.
15:51:03 <ericP> -> http://lists.w3.org/Archives/Public/public-rdf-comments/2013Mar/0039 CR comments "Language Tag Case Conflict" from Hong Sun
15:51:08 <Guus> ack pfps
15:51:25 <gkellogg> pfps: looking at what systems do… If I stick two language tag triples into Jena, do I get back out 1 or 2 triples.
15:51:33 <gkellogg> … This is a spec violation.
15:51:39 <gavinc> Yes, they are violating the spec ;)
15:52:00 <PatH> Please don't say "value"
15:52:01 <pfps> s/language tags/language tags that differ only in case/
15:52:07 <gkellogg> sandro: the cleanest way is to treat it as with other values, difference between literal equality and value equality.
15:52:32 <PatH> q+
15:52:36 <gkellogg> AndyS: we have to talk about the value space of RDFLangString anyway, so there's a place to talk about it.
15:52:41 <Guus> ack PatH
15:53:12 <gkellogg> PatH: If language tagged strings really were a datatype, then we could handle this neatly by creating a special datatype, but oh well...
15:53:38 <gkellogg> AndyS: it's just about defining the value space.
15:53:40 <gavinc> Why not?
15:53:50 <gkellogg> PatH: we're not allowed to do this.
15:53:53 <gavinc> Why can't we say that?
15:53:58 <gkellogg> … I'll take a look, though.
15:54:24 <gkellogg> ericP: would it just be easier to say that they're compared case-insensitively. It's ASCII, so it's pretty simple.
15:54:26 <SteveH> we can't guarantee to maintain the case, FWIW
15:54:27 <sandro> SteveH, if casefolding isn't enough, please speak up
15:54:53 <SteveH> I don't think we're the only ones
15:54:55 <PatH> I have to leave...
15:55:06 <gkellogg> AndyS: some systems will choose to do that, and the first one wins.
15:55:12 <Zakim> -PatH
15:55:20 <sandro> so changing the case is like skolemizing -- it's a fairly harmless bit of graph-changing.
15:55:21 <gkellogg> … I don't think we can change what systems really do.
15:55:29 <gkellogg> guus: leave further discussion to the list.
15:55:32 <gavinc> anyway, if you MEAN to do language comparing http://www.w3.org/TR/2013/REC-sparql11-query-20130321/#func-langMatches ;)
15:55:47 <SteveH> I also recognise that users might expect it to be preserved
15:55:55 <gkellogg> … I'd like to see if we can get reviewers for concepts and semantics.
15:55:56 <AndyS> "… I don't think we will change what systems actually do."
15:56:13 <ericP> gavinc, langMatches includes subsumption reasoning
15:56:19 <gkellogg> … We need reviews for both of them. I'm happy to review concepts.
15:56:25 <gkellogg> pfps: I'll review concepts.
15:56:39 <gavinc> ericP, yes. That was my pont.
15:56:41 <gkellogg> ivan: when are the reviews?
15:56:42 <ericP> e.g. langMatches("en-us", "en") => true (or maybe reversed parms, i can't remmeber)
15:56:45 <ericP> gotcha
15:56:46 <AndyS> All these use models are reasonable.
15:56:54 <gkellogg> guus: reviews in two weeks?
15:57:06 <gkellogg> pfps: version might be available in a week.
15:57:15 <gkellogg> guus: by end of next week.
15:57:37 <gkellogg> ivan: I can look at semantics the week after.
15:57:53 <gkellogg> guus: we should ask AZ.
15:58:35 <gkellogg> guus: 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.
15:58:41 <gavinc> Yay!
15:58:50 <gkellogg> sandro: I'm anxious about TriG, and I think we'll have some feedback.
15:59:14 <gkellogg> … I did a rough presentation on LDP, and trying to write up coherent feedback.
15:59:15 <sandro> (from LDP)
15:59:24 <gavinc> I guess that means I have to write how to parse it ;)
15:59:44 <gkellogg> sandro: I think we can use the syntax as long as we don't change it, and we shouldn't need to.
16:00:11 <Zakim> -Souri
16:00:12 <Zakim> -GavinC
16:00:13 <AndyS> bye all
16:00:13 <gkellogg> guus: we're getting close to finalizing the work.
16:00:15 <Zakim> -SteveH
16:00:17 <Zakim> -Ivan
16:00:18 <Zakim> -TallTed
16:00:18 <Zakim> -Arnaud
16:00:19 <Zakim> -Sandro
16:00:19 <Zakim> - +1.408.992.aaaa
16:00:21 <Zakim> -gkellogg
16:00:22 <Zakim> -markus
16:00:22 <Zakim> -davidwood
16:00:23 <Zakim> -AndyS
16:00:23 <Zakim> -ericP
16:00:25 <Zakim> -Guus
16:00:25 <Zakim> SW_RDFWG()11:00AM has ended
16:00:25 <Zakim> Attendees were +1.408.992.aaaa, GavinC, Ivan, AndyS, gkellogg, ericP, Sandro, Guus, manu, +1.540.898.aabb, davidwood, SteveH, markus, Souri, Arnaud, TallTed, PatH
16:00:45 <Guus>  trackbot, end meeting
16:00:45 <trackbot> Zakim, list attendees
16:00:45 <Zakim> sorry, trackbot, I don't know what conference this is
16:00:53 <trackbot> RRSAgent, please draft minutes
16:00:53 <RRSAgent> I have made the request to generate http://www.w3.org/2013/05/08-rdf-wg-minutes.html trackbot
16:00:54 <trackbot> RRSAgent, bye
16:00:54 <RRSAgent> I see no action items