Chatlog 2012-10-30

See panel, original RRSAgent log or preview nicely formatted version.

Please justify/explain non-obvious edits to this page, in your "edit summary" text.

00:05:19 <MacTed> MacTed has joined #rdf-wg
01:29:17 <pchampin> pchampin has joined #rdf-wg
02:14:44 <swh> swh has joined #rdf-wg
05:25:12 <gkellogg> gkellogg has joined #rdf-wg
06:52:13 <manu1> manu1 has joined #rdf-wg
07:23:22 <cygri> cygri has joined #rdf-wg
07:24:37 <cygri_> cygri_ has joined #rdf-wg
07:29:58 <cygri_> cygri_ has joined #rdf-wg
07:30:21 <Zakim> Zakim has left #rdf-wg
07:45:45 <Arnaud> Arnaud has joined #rdf-wg
08:03:12 <davidwood> davidwood has joined #rdf-wg
08:11:55 <Arnaud> Arnaud has joined #rdf-wg
08:15:59 <Zakim> Zakim has joined #rdf-wg
08:16:12 <sandro> zakim, call Rhone_4
08:16:12 <Zakim> sorry, sandro, I don't know what conference this is
08:16:17 <sandro> zakim, this is rdf
08:16:17 <Zakim> sandro, I see SW_RDFWG(TPACF2F)2:00AM in the schedule but not yet started.  Perhaps you mean "this will be rdf".
08:16:19 <sandro> zakim, call Rhone_4
08:16:19 <Zakim> sorry, sandro, I don't know what conference this is
08:16:26 <sandro> zakim, this will be rdf
08:16:26 <Zakim> ok, sandro; I see SW_RDFWG(TPACF2F)2:00AM scheduled to start 136 minutes ago
08:16:29 <sandro> zakim, call Rhone_4
08:16:29 <Zakim> ok, sandro; the call is being made
08:16:29 <Zakim> SW_RDFWG(TPACF2F)2:00AM has now started
08:16:32 <Zakim> +Rhone_4
08:17:01 <sandro> zakim, drop rhone_4
08:17:01 <Zakim> Rhone_4 is being disconnected
08:17:02 <Zakim> SW_RDFWG(TPACF2F)2:00AM has ended
08:17:02 <Zakim> Attendees were Rhone_4
08:17:33 <SteveS> SteveS has joined #rdf-wg
08:17:39 <sandro> zakim, call Rhone_4
08:17:39 <Zakim> ok, sandro; the call is being made
08:17:40 <Zakim> SW_RDFWG(TPACF2F)2:00AM has now started
08:17:41 <Zakim> +Rhone_4
08:17:55 <pchampin> pchampin has joined #rdf-wg
08:18:02 <Guus> Guus has joined #rdf-wg
08:18:08 <sandro> RRSAgent, pointer?
08:18:08 <RRSAgent> See http://www.w3.org/2012/10/30-rdf-wg-irc#T08-18-08
08:18:13 <sandro> RRSAgent, make logs public
08:20:17 <cygri> cygri has joined #rdf-wg
08:21:00 <cygri> guest: Steve Speicher
08:22:10 <ivan> ivan has joined #rdf-wg
08:23:06 <FabGandon> FabGandon has joined #rdf-wg
08:23:17 <cygri> scribe: cygri
08:23:33 <cygri> topic: Issue review
08:24:14 <cygri> guus: Let's go through them in order. Goal is just to do a quick assessment, not necessarily to resolve them.
08:25:10 <cygri> subtopic: ISSUE-3
08:25:43 <cygri> ISSUE-3?
08:25:43 <trackbot> ISSUE-3 -- Between us, we need to study the feedback we got via http://lists.w3.org/Archives/Public/www-rdf-comments/ on the previous round of specs (and errata) -- open
08:25:43 <trackbot> http://www.w3.org/2011/rdf-wg/track/issues/3
08:25:46 <cygri> ACTION-102?
08:25:46 <trackbot> ACTION-102 -- David Wood to ask Guus to find a student to do the work of ISSUE-3 -- due 2011-10-20 -- CLOSED
08:25:46 <trackbot> http://www.w3.org/2011/rdf-wg/track/actions/102
08:26:14 <cygri> guus: I have to review how many comments there are
08:27:06 <cygri> ivan: The role of the errata document is that if there's consensus on the comments list that something is indeed an error, it gets put into the errata document.
08:27:20 <cygri> sandro: That may not have been done here as the staff contacts left etc
08:27:48 <cygri> sandro: This starts with February 2004
08:28:00 <cygri> davidwood: Looks like at least a couple hundred of emails
08:29:15 <cygri> guest: Larry Masinter
08:29:36 <cygri> [discussion of badge colors]
08:30:24 <cygri> topic: rdf:Seq and implications for XMP
08:30:37 <cygri> davidwood: We resolved yesterday to mark rdf:Seq as archaic
08:31:10 <cygri> ... there's wide implementation in particular from Adobe in XMP
08:31:36 <cygri> Larry Masinter: There are thousands of people in Adobe. That said...
08:31:56 <cygri> ... XMP has its own internal data model that is syntactically serialized as RDF/XML.
08:32:12 <cygri> ... It's also no longer an Adobe specification, it's now an ISO standard.
08:32:27 <Zakim> +Gavinc
08:32:58 <cygri> ivan: It's certainly true that the latest version of Photoshop uses rdf:Seq.
08:33:16 <davidwood> Good morning, GavinC.  We are speaking with Larry Masinger (TAG) about Adobe XMP and rdf:Seq.  We will turn onto TriG next.
08:33:17 <cygri> Larry Masinter: Why bother declaring something that is widely deployed as obsolete?
08:33:36 <cygri> ericP: The goal is to steer new deployments away from rdf:Seq.
08:33:48 <cygri> Larry Masinter: What are you trying to accomplish?
08:34:06 <cygri> sandro: RDF has multiple ways of expressing sequence, none of which is very well supported.
08:34:30 <cygri> ... There's some agreement that rdf:Seq is the least best one
08:35:01 <cygri> Larry Masinter: HTML has several ways of drawing things. It's not clear that there's a design pattern that there should only be one way of doing any particular thing.
08:35:28 <cygri> davidwood: This is a weak form of deprecation.
08:35:56 <cygri> Larry Masinter: There's a problem when standards committees try to constrain future standards committees.
08:36:10 <cygri> [crosstalk]
08:36:14 <gavinc> +q
08:36:29 <davidwood> ack gavinc
08:36:29 <tidoust> tidoust has joined #rdf-wg
08:36:47 <cygri> gavinc: I'm not sure I agree with sandro's characterization that we're not telling people what to do.
08:37:06 <cygri> ... I think we resolved that people should use rdf:List instead of containers
08:37:26 <cygri> davidwood: I believe we have a resolution that hasn't made it into our documents.
08:37:30 <sandro> I hope your memory is better than mine on that, Gavin.     I certainly agree with that resolution.
08:37:33 <AZ> AZ has joined #rdf-wg
08:38:05 <cygri> Larry Masinter: XMP is in the PDF standard. PDF is used in various governments, etc.
08:38:17 <cygri> ... I'm not sure what the improvement is that you're trying to gain.
08:38:38 <cygri> sandro: People in the know are aware they shouldn't use rdf:Seq
08:38:40 <ivan> q+
08:38:42 <cygri> q+
08:38:58 <cygri> Larry Masinter: I'm not in the know. Why?
08:39:13 <cygri> ericP: curried predicates, out of favour, etc.
08:39:15 <cygri> q?
08:39:42 <gavinc> The issue is rdf:_1, rdf_*
08:40:16 <cygri> [eric's WPM exceed scribe capabilities]
08:40:42 <davidwood> ack ivan
08:40:43 <sandro> q?
08:40:59 <sandro> I hear Larry saying we can and should support both.   :-(
08:41:38 <cygri> ivan: We sohuldn't repeat yesterday's discussion. We asked Larry what we wanted to ask.
08:41:50 <cygri> ericP: But he didn't say what we wanted to hear.
08:42:02 <cygri> Larry Masinter: I'm not speaking for Adobe obviously.
08:42:15 <cygri> ... I will ask the ISO committee on their opinion.
08:42:25 <sandro> s/will/would/
08:42:48 <davidwood> ack cygri
08:42:50 <cygri> Larry Masinter: It's ISO 16684 (?)
08:43:05 <Arnaud> scribe: Arnaud
08:44:03 <Arnaud> cygri: challenge the assertion that people in the know know we shouldn't use seq
08:44:21 <davidwood> q?
08:44:31 <cygri> scribe: cygri
08:44:43 <davidwood> http://www.w3.org/2011/rdf-wg/meeting/2012-10-29#resolution_2
08:44:47 <cygri> davidwood: Where does this leave our resolution from yesterday?
08:45:02 <cygri> sandro: I hear Larry's advise that we should fully support rdf:Seq.
08:45:16 <cygri> davidwood: Can you clarify whom you speak for?
08:45:36 <cygri> Larry Masinter: Personal opinion. Informed by design principles.
08:45:50 <ericP> q?
08:45:51 <cygri> ... Deprecating something that's used successfully seems foolish.
08:46:17 <cygri> ... The rationale for deprecating it is not clear.
08:46:57 <yvesr> q+
08:46:59 <cygri> ... Photoshop and Acrobat are more widely deployed than the RDF tools you're concerned about.
08:47:37 <cygri> ... The rationale you gave is that tools you're aware of have trouble with rdf:Seq. There are many other tools with more market share that use it.
08:48:07 <cygri> davidwood: Purpose of RDF is interoperability. Tools that use it only internally as configuration are different.
08:48:33 <cygri> ... The places where we see difficulties with rdf:Seq is in the possibly smaller market that is concerned with interoperability
08:49:11 <cygri> Larry Masinter: The current RDF specifications passed the exit criteria, so do they not have interoperable implementations?
08:49:43 <cygri> davidwood: R&D was done in the 2002-2004 WG. Widely criticized for that.
08:50:07 <cygri> sandro: I'd like to clarify. rdf:Seq was in the 1999 spec already.
08:50:28 <cygri> ... So couldn't be removed due to charter
08:50:33 <davidwood> ack yvesr
08:50:37 <cygri> Larry Masinter: How is now different from 2004?
08:50:41 <yvesr> https://developer.mozilla.org/en-US/docs/Extension_Versioning,_Update_and_Compatibility
08:50:48 <cygri> sandro: It was a wrong decision back then.
08:51:07 <cygri> yves: [?] uses rdf:Seq to describe sequences of updates.
08:51:07 <sandro> sandro: We've been *silently* deprecating Seq for 12 years now.     let's stop doing that, at least.
08:51:15 <davidwood> q?
08:51:17 <yvesr> s/[?]/Mozilla Gecko
08:51:19 <sandro> q+
08:51:34 <cygri> ericP: My guess is that we're not going to deprecate rdf:Seq.
08:51:42 <cygri> ... Give up and move on.
08:52:08 <cygri> sandro: I'm not comfortable with silently deprecating rdf:Seq. I want to be wholeheartedly in favour of everything in the specification. Not the case for rdf:Seq.
08:52:26 <cygri> ... If we could improve support...
08:52:27 <ivan> ack sandro
08:52:31 <gavinc> indeed, support the collection types in Turtle :\
08:52:32 <cygri> ... e.g., syntax in Turtle
08:52:42 <cygri> davidwood: We won't do that design work today.
08:52:57 <cygri> ... We have the answer from Larry that we needed. Thank you Larry!
08:53:06 <cygri> Larry Masinter: You have my personal opinion.
08:53:11 <cygri> davidwood: Yes.
08:53:32 <cygri> ivan: We have a resolution from yesterday. Do we want to revisit that resolution?
08:53:45 <davidwood> PROPOSAL: Hold the resolution at http://www.w3.org/2011/rdf-wg/meeting/2012-10-29#resolution_2 in abeyance pending further study.
08:53:52 <ivan> +1
08:54:16 <cygri> sandro: That means re-opening ISSUE-77.
08:54:28 <sandro> +1 sadly
08:54:33 <gavinc> +1
08:54:35 <yvesr> +1
08:54:37 <davidwood> +1
08:54:53 <cygri> Arnaud: Why change this now?
08:55:01 <cygri> ±0
08:55:15 <cygri> davidwood: New information, need to reopen the issue
08:55:35 <AZ> 0
08:55:48 <FabGandon> 0
08:55:49 <Arnaud> -0
08:56:05 <davidwood> RESOLVED: Hold the resolution at http://www.w3.org/2011/rdf-wg/meeting/2012-10-29#resolution_2 in abeyance pending further study.
08:56:11 <davidwood> ISSUE-77.
08:56:19 <cygri> davidwood: I will re-open ISSUE-77 with these comments.
08:56:22 <davidwood> ISSUE-77 reopened.
08:56:25 <sandro> gavinc, are you with us for the day, or only a little while?
08:56:36 <gavinc> 1.56 am :D
08:56:38 <cygri> topic: TriG
08:56:57 <sandro> that doesn't answer my question, actually, gavinc
08:56:59 <davidwood> q?
08:57:37 <cygri> gavinc: There is an editor's draft of TriG. It is old, doesn't reflect current "consensus" on graphs.
08:57:55 <cygri> ... Most of the document will have to change based on decisions made around graphs.
08:58:07 <cygri> ... Most edge cases change.
08:58:30 <cygri> subtopic: Renaming TriG?
08:58:39 <cygri> gavinc: Since almost all of the interesting design decisions change between TriG-as-deployed and the new standard, do we want to rename it?
08:58:40 <gavinc> http://dvcs.w3.org/hg/rdf/raw-file/default/trig/index.html#
08:58:47 <cygri> davidwood: I believe we have a resolution to keep the name.
08:59:23 <cygri> gavinc: Some of us supported the resolution on the condition that the language mostly stays like TriG-as-deployed. This doesn't seem to be the case.
08:59:34 <cygri> sandro: What's the biggest change?
09:00:03 <cygri> gavinc: When I repeat the graph label multiple times, it is not an error, but the union
09:00:24 <cygri> ericP: What does the old draft say?
09:00:30 <cygri> gavinc: It's an error.
09:00:38 <cygri> sandro: It doesn't invalidate old data.
09:00:57 <cygri> ... I'm pretty sure Anzo supports it already.
09:01:03 <cygri> [discussion of = sign]
09:01:20 <cygri> gavinc: Trailing periods are now removed.
09:01:23 <cygri> q+
09:01:34 <cygri> sandro: Strikes me as trivial.
09:01:50 <davidwood> ack cygri
09:02:12 <ericP> cygri: sandro says that the changes are trivial
09:02:27 <ericP> ... they may be trivial to human eyes, but not to parsers
09:02:32 <sandro> q?
09:02:35 <gavinc> +q
09:02:45 <ericP> ... the question is "does it break the language?"
09:02:49 <davidwood> RESOLVED We will call a recommended dataset syntax "TriG", but informally and in the media type, "trig".
09:02:51 <davidwood> http://www.w3.org/2011/rdf-wg/meeting/2012-10-03#resolution_5
09:03:05 <ericP> sandro: i think it doesn't break it in most cases, less than the ways in which we broke Turtle
09:03:29 <cygri> gavinc: All of the examples provided in the old spec are no longer TriG documents.
09:03:48 <ericP> -> http://www4.wiwiss.fu-berlin.de/bizer/TriG/Spec/ the DERI Trig spec of which we speak
09:04:12 <cygri> davidwood: We have a resolution on this.
09:04:26 <cygri> ... Many were not in favour, but the resolution passed.
09:04:42 <cygri> ... Gavin, issues related not to naming?
09:05:03 <cygri> q+
09:05:05 <cygri> subtopic: Document status
09:05:06 <ericP> i believe that all the examples in the fu-berlin spec are still Trig by our definition
09:05:10 <ivan> ack gavinc
09:05:11 <davidwood> ack gavinc
09:05:14 <cygri> gavinc: It is still unclear to me how to write the section that introduces named graphs.
09:05:28 <cygri> ... This makes it challenging to write what a graph label is.
09:05:30 <sandro> q?
09:05:38 <cygri> davidwood: Not sure I follow.
09:05:48 <davidwood> ack cygri
09:06:10 <ericP> cygri: I don't see this prob 'cause the Abstract Syntax defines an RDF Dataset
09:06:23 <sandro> +1 cygri    TriG just needs to say it's serializing a Dataset.
09:06:26 <ericP> ... all the Trig doc must do is say "we serialize one of those."
09:06:39 <ivan> +1 cygri
09:07:01 <ericP> ... there could be challenges in the motivating text (why you would want to use this), but that text is a minor point
09:07:18 <gavinc> "A graph statement pairs an IRI with a RDF Graph"
09:07:20 <cygri> gavinc: I guess then there's one sentence describing it that matches RDF Concepts.
09:07:31 <cygri> ... Makes for a short, not very helpful document. But maybe that's all we can do.
09:07:50 <cygri> ... I think the grammar is in reasonable shape as it's based on Turtle.
09:07:56 <AndyS> AndyS has joined #rdf-wg
09:08:19 <cygri> ... I assume the Turtle Feature-At-Risk for BASE/PREFIX applies.
09:08:53 <cygri> ... Do we need to repeat the stuff from Turtle or just refer to it?
09:08:57 <cygri> q+
09:08:58 <sandro> just reference turtle grammar
09:09:21 <cygri> ericP: I'm a big fan of being able to copy and paste stuff
09:09:23 <yvesr> q+ to ask about default graph (sorry)
09:09:35 <cygri> gavinc: Grammar will have to be repeated, but the rest maybe not.
09:09:44 <cygri> q-
09:09:58 <cygri> davidwood: It seems like some of the October resolutions are not yet fully reflected.
09:10:04 <cygri> ... in the grammar.
09:10:06 <cygri> gavinc: That's correct
09:10:33 <sandro> q+ to say please provide dates on editor's drafts
09:10:43 <cygri> [discussion of grammar minutiae]
09:11:14 <sandro> q+ sandro2 to ask why repeat grammar?     it's not you can actually cut/paste it.
09:11:50 <davidwood> ack yvesr
09:11:50 <Zakim> yvesr, you wanted to ask about default graph (sorry)
09:12:05 <ericP> q+ yvesr
09:12:08 <davidwood> ack sandro
09:12:08 <Zakim> sandro, you wanted to say please provide dates on editor's drafts
09:12:24 <cygri> q+
09:12:49 <gavinc> yeah, no not changing the date every time I edit the document
09:13:41 <davidwood> ack sandro2
09:13:41 <Zakim> sandro2, you wanted to ask why repeat grammar?     it's not you can actually cut/paste it.
09:14:08 <cygri> cygri: [doesn't want to spend time making sure the date on ED is correct]
09:14:21 <cygri> sandro: How about putting a clearly non-date there, January 99 or something
09:14:28 <Zakim> +[IPcaller]
09:14:31 <cygri> ... Regarding grammar, copy-paste doesn't work
09:14:39 <AndyS> zakim, IPCaller is me
09:14:39 <Zakim> +AndyS; got it
09:14:55 <davidwood> AndyS, we are speaking about TriG grammar.
09:15:00 <cygri> gavinc: I'll probably repeat them and make clear it's same as the Turtle grammar
09:15:07 <cygri> ivan: In my view, editor's pregorative
09:15:28 <cygri> ericP: I like to copy-and-paste
09:15:36 <cygri> ... I also like to click through in an HTML spec
09:15:44 <davidwood> q?
09:15:44 <cygri> sandro: It can click you over to the Turtle spec.
09:15:55 <cygri> ack me
09:16:11 <AndyS> AndyS has joined #rdf-wg
09:16:18 <davidwood> ack yvesr
09:16:23 <cygri> ericP: Special markings on productions imported from other specs are good
09:16:30 <cygri> subtopic: Default graph
09:16:42 <cygri> yvesr: I sent an email last week about the default graph in TriG.
09:16:53 <cygri> q+
09:17:03 <sandro> I rather like the idea of the TriG spec being 1 page.     :-)      (It can be if it just refs turtle)
09:17:10 <cygri> ... If you load a TriG file into a triple store and write it out again, you're not sure it comes out the same
09:17:29 <cygri> ... So what's the point of the default graph.
09:17:41 <davidwood> Yves' message regarding default graphs in Trig: http://lists.w3.org/Archives/Public/public-rdf-wg/2012Oct/0212.html
09:17:41 <AndyS> ?? it does in Jena.
09:18:34 <cygri> ivan: There are default graphs in SPARQL. Therefore, it should be in TriG. TriG does not introduce any new concept, and shouldn't be silent on any concept that's in the data model.
09:18:38 <pchampin> q+
09:18:55 <davidwood> ack cygri
09:19:19 <ericP> cygri: the data model of a SPARQL store is an RDF data set
09:19:36 <ericP> ... the data model of Trig is also an RDF data set
09:19:46 <pchampin> q-
09:20:04 <ericP> ... the Trig doc currently doesn't tell you how to load a Trig doc into the SPARQL store
09:20:34 <pchampin> q+
09:20:35 <ericP> ... there can be a middle step between ingesting Trig and writing to the SPARQL store where the impl can do what it wants
09:21:06 <ericP> ... the injestion is not a "restore from trig file", but more "add trig file to store"
09:21:19 <cygri> yvesr: I still think that's a confusing behaviour in TriG
09:21:30 <davidwood> ack pchampin
09:21:37 <ericP> yvesr: i think that [default graphs] are the most difficult feature of Trig
09:21:47 <cygri> ... Makes it hard to explain triple store behaviour, and explain how to use the default graph
09:22:15 <cygri> pchampin: Let me try to rephrase. A TriG file represents a dataset. There's a correct way to parse a TriG file into a dataset.
09:22:53 <cygri> ... But what's less well defined is how to integrate a dataset into a graph store.
09:23:13 <cygri> ... If we validate a TriG parser, it has to be clear what graphs we end up with
09:23:31 <cygri> ... But when a graph store digests a dataset, things can happen.
09:23:47 <cygri> ... Emphasizing this difference may make it less confusing
09:24:13 <cygri> AndyS: There was a comment that if you read something in and write it out again, you don't get the same thing.
09:24:17 <cygri> q+
09:24:43 <cygri> q-
09:24:54 <yvesr> q+
09:24:57 <cygri> ... We don't know what the right model of operation is for some of these things
09:25:15 <cygri> ... So banning some features because of store behaviour is risky.
09:25:58 <cygri> yvesr: I feel that the SPARQL definition of dataset came from implementations. We imported that as the general RDF dataset model.
09:26:07 <cygri> ... So it started with implementations
09:26:11 <davidwood> ack yvesr
09:26:50 <cygri> davidwood: Gavin, has your view changed based on this dicsussion?
09:26:55 <cygri> gavinc: No.
09:27:24 <cygri> ivan: We have little choice. TriG is just a syntax. If default graph in the model, it has to be in the syntax.
09:28:00 <cygri> subtopic: Towards FPWD and examples
09:28:11 <cygri> davidwood: Our primary concern is to get this document out the door. How will we turn this into an FPWD and start the process?
09:28:28 <cygri> gavinc: We should be ready for FPWD quite soon.
09:28:50 <cygri> ... My request to the WG: Examples for use of TriG would be helpful.
09:29:08 <cygri> ... Preferably small ones. Those from the old spec are not great, and all I have are 6GB.
09:30:02 <cygri> [discussion of grammar minutiae]
09:31:15 <cygri> [scribe is lost]
09:31:40 <cygri> [discussion of TriG examples]
09:31:52 <ivan> q+
09:31:52 <sandro> gavinc: The examples in the current ED aren't right.     We can no longer say G1 refers to a graph, etc
09:32:02 <cygri> q+
09:32:05 <sandro> sandro: That text isn't right any more, but the trig is okay
09:32:54 <ericP> cygri: one obvious example would be something which shows versioning
09:32:57 <AZ> examples of trig files: https://www.google.com/search?q=prefix+filetype%3Atrig
09:33:03 <ericP> ... a provenance example would be useful
09:33:20 <AZ> and a provenance example: http://dvcs.w3.org/hg/prov/file/tip/examples/eg-33-a-simpler-hasProvenanceIn/rdf/eg-33-a-simpler-hasProvenanceIn.trig
09:33:25 <ericP> ... the PROV WG has an examplw which shows how DC maps to PROV
09:33:36 <ericP> ... ask Tim Libo?
09:33:46 <ericP> ivan: there's also the PROV Primer
09:34:00 <ericP> ... should be easy to tweak to use named graphs
09:34:10 <gavinc> uh, az that isn't trig :(
09:34:23 <ericP> ... contact Paul Gross quickly; there's a PROV F2F at MIT in a week
09:34:43 <cygri> s/Gross/Groth/
09:35:27 <davidwood> ack ivan
09:35:29 <cygri> davidwood: I'll send a message to Paul
09:35:34 <davidwood> ack cygri
09:35:45 <cygri> ivan: I can translate an example to TriG
09:36:18 <cygri> davidwood: Assuming we can get an example out of ivan, when can you provide doc for review
09:36:23 <cygri> gavinc: November 15
09:36:46 <cygri> ivan: We should not publish this before next RDF Concepts
09:36:51 <davidwood> action: davidwood to contact Paul Groth re provenance example for TriG (before the prov wg ftf)
09:36:52 <trackbot> Created ACTION-200 - Contact Paul Groth re provenance example for TriG (before the prov wg ftf) [on David Wood - due 2012-11-06].
09:37:19 <cygri> davidwood: So we'll start the WG review on Nov 15
09:37:21 <davidwood> q?
09:37:43 <cygri> [nitpicking about examples]
09:38:25 <sandro> sandro: We need to tell Prov about our modified TriG so they can update their examples.
09:38:31 <cygri> ivan: So at the PROV F2F I can tell them that they can use TriG and refer to the upcoming FPWD
09:38:41 <ericP> q+ to clarify the changes from the old Trig
09:38:42 <cygri> ... they made every effort to remove anything that looks like TriG from the documents
09:38:47 <cygri> ... Now they can put it back.
09:39:03 <cygri> sandro: When is their next round of publications?
09:39:11 <cygri> ivan: Hope to vote for CR next week.
09:39:21 <cygri> sandro: Won't have FPWD by then
09:39:33 <cygri> ivan: Can they refer to an ED?
09:39:47 <cygri> sandro: No, not a stable URI.
09:40:22 <sandro> sandro: well, okay, I guess, sure.
09:40:24 <cygri> davidwood: It's a CR. We can put an ED reference there and make clear we'll update it.
09:40:30 <cygri> topic: —coffee—
09:40:36 <gavinc> 25 minutes?
09:40:42 <cygri> davidwood: break for 25 minutes
09:40:47 <davidwood> yes
09:45:58 <Zakim> -AndyS
09:47:33 <Zakim> -Gavinc
09:47:38 <gavinc> Extra heads removed from our hg
09:57:40 <cygri> RRSAgent, make logs public
10:03:14 <Zakim> +Gavinc
10:03:41 <gavinc> Shinny grammar http://dvcs.w3.org/hg/rdf/raw-file/default/trig/index.html#sec-grammar
10:09:40 <gavinc> did I make sandro happy? ;)
10:10:56 <gavinc> Please DON'T update it each time, makes resolving merges annoying :P
10:11:10 <gavinc> Yes.
10:11:34 <sandro> Well, you make me smile at least.  :-)
10:11:35 <gavinc> N-Quads and N-Triples!
10:11:38 <cygri> topic: N-Triples
10:11:44 <gavinc> since we didn't talk about N-Triples anywhere else
10:12:13 <pchampin> scribe: pchampin
10:12:38 <pchampin> davidwood: we first considered making N-Triples a part of Turtle, then we decided to split it
10:12:46 <tidoust> tidoust has joined #rdf-wg
10:13:23 <gavinc> dvcs.w3.org/hg/rdf/raw-file/default/rdf-turtle/n-triples.html
10:14:06 <pchampin> gavinc: current dratf shouldn't require much work
10:14:08 <Zakim> +[IPcaller]
10:14:12 <AndyS> zakim, IPCaller is me
10:14:12 <Zakim> +AndyS; got it
10:15:09 <pchampin> [discussing the language name]
10:15:46 <pchampin> davidwood: did we agree to make this document REC track?
10:15:50 <pchampin> gavinc: yes
10:16:43 <pchampin> sandro: are escape sequences allowed?
10:16:49 <pchampin> gavinc: in this version, yes
10:18:07 <pchampin> sandro: could get rid of ECHAR in theory (backslash-escaping)
10:18:35 <pchampin> gavinc: would be back to the 2004 version, whose goal was to have a single way to represent things
10:18:41 <pchampin> ... but this is not a requirement of this version
10:19:01 <pchampin> ... in this version, you don't require either encoding, as this is UTF-8
10:19:21 <pchampin> s/encoding/escaping/
10:19:44 <pchampin> ... although some cases require UCHAR anyway (scribe missed which case it was)
10:20:05 <cygri> q+
10:20:20 <sandro> queue=cygri
10:20:20 <AndyS> Does any N-triples-2004 parser implement the UCHAR can't be used for chars like TAB?
10:20:22 <gavinc> q- ericP
10:20:22 <davidwood> ack ericp
10:20:28 <davidwood> ack cygri
10:21:00 <cygri> subtopic: Canonical/normalized N-Triples
10:21:04 <pchampin> sandro: any canonical form?
10:21:10 <AndyS>  scribe: + Some escape is needed for newline
10:21:14 <AZ> you can only have one UCHAR in an IRIREF !?
10:21:24 <AZ> """[132s]		IRIREF		::= 	('<' ([^<>"{}|^`\]-[#x00-#x20])* | UCHAR '>')"""
10:21:40 <gavinc> errr...
10:21:55 <gavinc> should be [19] IRIREF ::=  '<' ([^#x00-#x20<>\"{}|^`\] | UCHAR)* '>'
10:21:58 <gavinc> will fix
10:22:06 <AndyS> AZ - C&P error from Turtle - no *
10:22:33 <pchampin> cygri: the nice thing about N-Triples/N-Quad is that they are easy to process with text tools
10:22:34 <AndyS> but it is a compression algorithm.
10:22:38 <sandro> cygri: I suggest we have a Normalized N-Triples, informative, one space between terms, etc.
10:22:58 <pchampin> ... its easier if you have some normalized/canonical form
10:23:16 <pchampin> ... though this is good practice, mostly; it does not need to be normatively defined
10:23:40 <davidwood> q?
10:24:01 <pchampin> ... making it non-normative would mainly minimize work
10:24:06 <ivan> q+
10:24:16 <davidwood> ack ivan
10:24:53 <pchampin> ivan: the first example has comments, but the grammar does not seem to define comments
10:26:25 <pchampin> sandro: comments are line-oriented, while the rest of the grammar is not
10:26:44 <pchampin> ... hence, the comments are not in the grammar
10:26:51 <sandro> gavin: comments are treated as whitespace
10:26:55 <pchampin> ... you can't copy-paste the grammar, you have to read the spec
10:27:19 <AndyS> Is "<s> <p> <o> . # comment" to be legal?  (hope not)
10:27:45 <davidwood> The first example says yes
10:27:49 <pchampin> gavinc: documents will be ready for working group review on the 15 of november
10:28:24 <pchampin> gavinc: to AndyS question: yes it is possible in this version of N-Triples
10:28:45 <pchampin> AndyS: normalized N-Triples should say that comments must have their own line
10:28:51 <pchampin> gavinc: yes
10:29:16 <davidwood> gavinc: Normalized n-triples should allow end-of-line comments, but canonicalized n-triples should have line-oriented comments.
10:29:20 <cygri> subtopic: Line breaks
10:29:30 <pchampin> gavinc: newlines inside triples are quite probably allowed
10:29:43 <pchampin> (many people in the room): hummmm
10:30:23 <sandro> wondering about calling N-Triple something like "line-mode turtle".
10:30:26 <davidwood> gavinc: Expects to have n-triples spec ready for review by WG on 15 Nov with the intention to ask for FPWD shortly thereafter.
10:30:31 <pchampin> gavinc: again, you shouldn't do that in noramlized N-Triples
10:30:33 <pchampin> q+
10:30:45 <davidwood> ack pchampin
10:31:21 <sandro> pchampin: Maybe we shouldn't make Normalized N-Triples just informative.  If N-Triples is so permissive, there may be more need for Normalized N-Triples.
10:31:49 <cygri> q+
10:32:43 <AndyS> If gavinc shrugs, shall we make it one line per triple, no trailing comments c.f. nt-2004.
10:32:45 <sandro> ivan: I'm fine with N-Triples including these Normalization rules.
10:32:49 <AndyS> q+
10:32:56 <sandro> ack cygri
10:33:09 <pchampin> pchampin: what is the motivation for making it so more permissive?
10:33:31 <pchampin> s/pchampin/cygri/
10:33:51 <pchampin> gavinc: the motivation was to reuse as much as possible the rules from Turtle
10:33:58 <Guus> Guus has left #rdf-wg
10:34:02 <pchampin> ... remember that it was originally a subset of Turtle
10:34:19 <Guus> Guus has joined #rdf-wg
10:34:21 <pchampin> ... we can easily make it more restrictive
10:34:43 <pchampin> ... by removing turtly bits from it
10:35:56 <pchampin> cygri: I think it more important to make it close to the old N-triples than to make it "turtlier"
10:36:58 <pchampin> gavinc: the older spec was very pedantic, and noone implemented it strictly
10:37:16 <cygri> http://www.w3.org/TR/rdf-testcases/#eoln
10:37:19 <davidwood> ack AndyS
10:37:28 <gavinc> line 	::= 	ws* ( comment | triple )? eoln
10:37:35 <gavinc> tailing newline
10:37:49 <pchampin> andys: I think the expectation is that N-Triples is one line per triple
10:37:50 <cygri> what's a newline?
10:38:41 <pchampin> ... reusing turtle should not be a design constraint
10:39:17 <pchampin> davidwood: also recall that Oracle didn't want anything to break their existing N-Triples parser
10:40:08 <gavinc> http://dvcs.w3.org/hg/rdf/raw-file/default/rdf-turtle/n-triples.html#n-triple-changes
10:41:31 <cygri> gavin, this one has a newline: http://www.w3.org/2000/10/rdf-tests/rdfcore/xmlbase/test008.nt
10:42:45 <AndyS> The test cases have a final newlines in the copy I'm looking at.
10:42:56 <gavinc> huh
10:43:02 <AndyS> and copyright statement.
10:43:12 <gavinc> ... I wonder if it depends on where you got them from
10:43:24 <davidwood> PROPOSED: The RDF 1.1 n-triples grammar will not allow line breaks within triples
10:43:38 <ivan> +1
10:43:39 <cygri> +1.1
10:43:40 <AndyS> +1
10:43:40 <ericP> +1
10:43:41 <gavinc> +1
10:43:42 <pchampin> +1
10:43:47 <Arnaud> +1
10:43:54 <ericP> +0.9
10:44:02 <AZ> +1
10:44:07 <davidwood> +1
10:44:08 <yvesr> +1
10:44:44 <pchampin> RESOLVED: The RDF 1.1 n-triples grammar will not allow line breaks within triples
10:45:23 <gavinc> http://dvcs.w3.org/hg/rdf/raw-file/default/rdf-turtle/n-triples.html#n-triple-changes
10:45:27 <davidwood> The editors will be gavinc and ericp
10:45:47 <pchampin> davidwood: Eric, your appear as an editor of N-Triples, are you happy with that?
10:45:57 <pchampin> ericp: I'm happy eitherway
10:46:16 <pchampin> davidwood: anyway we'll have you as contact for the IETF registration
10:46:29 <pchampin> topic: N-Quads
10:47:04 <pchampin> cygri: I think it would be nice to have an N-Quads syntax
10:47:11 <AndyS> +1 to NQuads spec.  NQ exists!  (don't care about empty graph but easy to add something)
10:47:23 <ericP> q+ to demonstrate ignorance by asking what use case is addressed by N-Quads which is not addressed by Trig
10:47:26 <pchampin> sandro: what about the default graph?
10:47:34 <gavinc> <> <> <> . <> <> <> <> .
10:48:29 <davidwood> ack ericp
10:48:29 <Zakim> ericP, you wanted to demonstrate ignorance by asking what use case is addressed by N-Quads which is not addressed by Trig
10:48:41 <AndyS> q+
10:49:00 <pchampin> ericp: what can we accomplish with N-Quads that we can't with Trig?
10:49:52 <pchampin> ... seems that you don't end up with faster process for N-Quads than with Trig?
10:50:12 <pchampin>  ivan: same argument as N-Triples: you can use line-oriented tools
10:50:42 <gavinc> Too late, N-Quads exist
10:50:43 <pchampin> ... and it is already used like that out there
10:50:49 <cygri> q+
10:51:26 <pchampin> sandro: N-Triples is a subset of Turtle, you never need an N-Triple parser if you have a Turtle parser.
10:51:35 <pchampin> ... this is not the same between N-Quads and Trig
10:51:39 <davidwood> ack AndyS
10:52:16 <pchampin> andys: it's already out there, and people use it
10:52:38 <pchampin> ... re. N-Triples, people use specific parsers that happen to be faster than Turtle parsers
10:52:38 <davidwood> ack cygri
10:53:30 <pchampin> cygri: agreed it is a de facto standard
10:53:43 <pchampin> ... sure, we could work out a subset of Trig for that purpose
10:53:58 <pchampin> ... cons: it's not what is currently being used
10:54:21 <AndyS> newlines again?
10:54:27 <Arnaud> q+
10:54:34 <davidwood> ack Arnaud
10:54:41 <pchampin> ... pros: it could be a profile of N-Quads
10:55:33 <pchampin> arnaud: still feel uncomfortable about the proliferation of syntaxes
10:55:43 <pchampin> ... we are moving from 1 normative syntax to 7
10:56:15 <pchampin> ... I understand that having multiple syntaxes makes it clear that what matters is the data model
10:56:17 <davidwood> q?
10:56:32 <pchampin> ericp: but for this, we only need 2, not 7
10:56:53 <pchampin> arnaud: I agree that we should endorse existing syntax
10:57:03 <pchampin> ... but not try to define a new one to replace the old one,
10:57:11 <pchampin> ... because the old one will not disappear
10:58:26 <ivan> q+
10:58:31 <davidwood> ack ivan
10:58:42 <pchampin> davidwood: multiples syntax make it clearer that the data model is what matters
10:59:15 <pchampin> ivan: I would propose that the current N-Triples document include N-Quads (as it is used in the wild)
10:59:44 <ericP> to convert from N-Quads to N-Trig: awk '{print $4 " { " $1 " " $2 " " $3 "}"}'
11:00:01 <pchampin> arnaud: how would it be acceptable for N-Triples/N-Quad when it was not for Turtle/Trig?
11:00:15 <pchampin> ivan: I just want to limit the proliferation of documents
11:00:24 <pchampin> q+
11:00:49 <sandro> PROPOSED: We'll do N-Quads on the REC Track, as another Dataset serialization syntax, in line with existing, in-the-wild N-Quads.
11:01:01 <gavinc> +1
11:01:04 <pchampin> ivan: we define a notation for dumps, defining what's already out there, and that's all
11:01:06 <sandro> +1
11:01:12 <cygri> sandro, can we say "in the same doc as N-Triples"?
11:01:20 <ericP> -0.9
11:01:30 <AZ> +1
11:01:30 <ivan> +1
11:01:37 <pchampin> +1
11:01:43 <ericP> -0.9 due to proliferation of parsers
11:01:43 <davidwood> +1
11:01:47 <Arnaud> +1
11:02:04 <AZ> q+
11:02:05 <cygri> +1
11:02:13 <cygri> q+
11:02:22 <gavinc> "Line Oriented RDF Syntaxes"
11:02:22 <pchampin> q-
11:02:42 <yvesr> +0.1
11:03:03 <gavinc> The parsers already exist
11:03:30 <gavinc> Just about any SPARQL store has to deal with N-Quads already
11:03:36 <sandro> sandro: line-trig would be yet another language (in people's heads).   n-quads already exists.
11:04:08 <pchampin> eric: I was more concerned in limiting the number of parsers, not the number of languages
11:04:27 <pchampin> ... anyway, converting N-Quads to line-oriented Trig is quite trivial
11:04:36 <pchampin> s/trivial/easy/
11:04:48 <davidwood> ack AZ
11:04:48 <ivan> ack AZ
11:04:52 <sandro> sandro: How about in the spec we provide the informative unix command to convert n-quads to trig.  :-)
11:04:56 <pchampin> ... making it easy to parse N-Quads with an (instrumented) Trig parser
11:05:07 <mlnt> mlnt has joined #rdf-wg
11:05:12 <ivan> ack cygri
11:05:36 <sandro> sandro: nquads syntax would be restricted to datasets (no literals or bnodes in fourth column)
11:05:46 <pchampin> az: we should remove from N-Quads the fact that bnodes are allowed in the graph name position
11:06:01 <Arnaud> q+
11:06:05 <sandro> cyg: the fact that an RDF syntax exists because not every RDF toolkit has to implement it.    they are for particular user bases.
11:06:05 <pchampin> cygri: N-Quads will not lead to a proliferation of parsers, because the parsers are already there
11:06:41 <davidwood> ack Arnaud
11:07:08 <pchampin> s/az: we should/az: should we/
11:07:12 <gavinc> Introduction to RDF Syntaxes?
11:07:17 <gavinc> as part of the primer?
11:08:09 <pchampin> sandro: OWL had an Overview document, to help people with a large number of documents
11:08:15 <cygri> q+
11:08:19 <pchampin> ivan: I think this is a good idea
11:08:35 <sandro> http://www.w3.org/TR/owl2-overview/
11:08:54 <pchampin> guus: in OWL1, this was the first section in all the documents
11:09:03 <davidwood> ack cygri
11:09:07 <pchampin> ivan: I think a separate document is better
11:09:11 <sandro> http://www.w3.org/TR/sparql11-overview/
11:09:52 <pchampin> cygri: I'm not sure about the targeted reader of such an overview document
11:10:33 <pchampin> ... the need for such an overview exist, but then it should not stop at the boundaries of this particular WG
11:11:41 <davidwood> For an example of a useful overview document, see the CSS WG's current work page: http://www.w3.org/Style/CSS/current-work
11:11:44 <davidwood> q?
11:11:51 <pchampin> ... the reader would also want to know about SPARQL or RDFa
11:11:58 <sandro> RESOLVED: We'll do N-Quads on the REC Track, as another Dataset serialization syntax, in line with existing, in-the-wild N-Quads.
11:12:01 <yvesr> so what should the primer 'syntax' section cover, then?
11:12:04 <pchampin> ivan: I disagree, but that's ok
11:12:09 <cygri> davidwood, that's a nice page
11:12:15 <gavinc> No.
11:13:42 <gavinc> "Line Oriented RDF Syntaxes"
11:13:54 <gavinc> I'd like to avoid the word "Dump"
11:13:55 <sandro> "RDF Dump Formats"
11:14:07 <gavinc> "Line Oriented RDF Syntaxes"?
11:14:18 <AndyS> "Line oriented" -- the MapReduce case
11:14:37 <sandro> PROPOSED: We're do N-Triples and N-Quads in one REC-track documents, title to be decided
11:14:49 <Arnaud> +1
11:14:50 <ivan> +1
11:14:50 <sandro> +1
11:14:53 <gavinc> +1
11:14:53 <AndyS> +1
11:14:53 <cygri> +1
11:14:55 <pchampin> +1
11:14:56 <AZ> +1
11:14:59 <davidwood> +1
11:15:10 <yvesr> +1
11:15:13 <davidwood> Richard and Gavin to edit.
11:15:13 <sandro> RESOLVED: We'll do N-Triples and N-Quads in one REC-track documents, title to be decided
11:15:16 <ericP> abstain
11:15:17 <davidwood> q?
11:15:52 <pchampin> topic: Issue Review
11:16:22 <tbaker> tbaker has joined #rdf-wg
11:17:49 <pchampin> guus: I made a scan of the www-rdf-comments archive
11:18:13 <Zakim> -AndyS
11:18:33 <pchampin> http://www.w3.org/mid/508FACB7.7080103@vu.nl
11:18:48 <AndyS1> AndyS1 has joined #rdf-wg
11:19:05 <AndyS> AndyS has left #rdf-wg
11:19:05 <pchampin> guus: we can paste it in a wiki page
11:19:34 <pchampin> ... there could be duplications with the errata
11:20:13 <FabGandon> concerning errata I did this for RDF-XML http://www.w3.org/2011/rdf-wg/wiki/TF-RDF-XML
11:20:59 <pchampin> ivan: there is no formal process with the errata
11:22:07 <sandro> gavinc, we're looking at http://www.w3.org/2011/rdf-wg/track/issues/open
11:22:19 <sandro> :-)
11:23:24 <sandro> re ISSUE-23 -- does JSON-LD need a different media type when it contains multiple graphs???!?!   (everyone sighs)
11:25:11 <cygri> Resolution to close ISSUE-35 and ISSUE-38 from yesterday: http://www.w3.org/2011/rdf-wg/meeting/2012-10-29#resolution_10
11:25:38 <davidwood> Close ISSUE-35 We will not use an rdf:Graph construct.
11:27:02 <davidwood> Close ISSUE-38 We will create dataset serialization formats (TriG and n-quads).
11:27:10 <sandro> trackbot, hello?
11:27:10 <trackbot> Sorry, sandro, I don't understand 'trackbot, hello?'. Please refer to http://www.w3.org/2005/06/tracker/irc for help
11:27:17 <sandro> issue-35?
11:27:17 <trackbot> ISSUE-35 -- Should there be an rdf:Graph construct, or something like that? -- open
11:27:17 <trackbot> http://www.w3.org/2011/rdf-wg/track/issues/35
11:28:41 <davidwood> close ISSUE-35
11:28:41 <trackbot> ISSUE-35 Should there be an rdf:Graph construct, or something like that? closed
11:28:47 <davidwood> close ISSUE-38
11:28:47 <trackbot> ISSUE-38 What new vocabulary should be added to RDF to talk about graphs? closed
11:28:48 <sandro>  agreed: close ISSUE-78 and make it an action on Guus
11:31:04 <pchampin> cygri: re issue-80 it is hard to get the document updated, as the WG is no longer active
11:31:54 <pchampin> sandro: we agreed yesterday that we didn't need to update them, as they are referring to an older version of RDF
11:31:55 <sandro> sandro: I don't think we need to do anything here....
11:32:52 <pchampin> cygri: the problem is that rdf:PlainLiteral is in the rdf: namespace, and it should not be there anymore
11:33:34 <pchampin> ... OWL should now manage with xsd:String and rdf:LangString
11:33:57 <pchampin> ivan: they can not make this kind of change now, only editorial changes
11:34:33 <pchampin> sandro: the only thing to do is to send an email to the owl-comments list
11:35:03 <pchampin> ACTION cygri to send a message about rdf:PlainLiteral to the owl-comments mailing list
11:35:03 <trackbot> Created ACTION-201 - Send a message about rdf:PlainLiteral to the owl-comments mailing list [on Richard Cyganiak - due 2012-11-06].
11:35:06 <sandro> +1 cygri ask OWL WG to redo rdf:PlainLiteral as using xs:string and xs:LangString.
11:35:17 <gavinc> ISSUE-99 is a No.
11:35:43 <pchampin> close issue-80
11:35:44 <trackbot> ISSUE-80 Ask OWL and RIF WGs to update the rdf:PlainLiteral spec closed
11:36:17 <gavinc> ISSUE-99 is a No!
11:36:25 <gavinc> and there is a bigger reason ;)
11:36:36 <gavinc> in that we likely shouldn't have the HTML datatype either
11:36:56 <pchampin> fabgandon: re issue-99 we discussed that yesterday,
11:37:12 <pchampin> ... and I recorded for the XML syntax that it should include an example of HTML literal using CDATA
11:37:22 <cygri> ISSUE-99?
11:37:22 <trackbot> ISSUE-99 -- Does RDF/XML get a special syntax for HTML Literals? -- open
11:37:22 <trackbot> http://www.w3.org/2011/rdf-wg/track/issues/99
11:37:38 <pchampin> close issue-99
11:37:38 <trackbot> ISSUE-99 Does RDF/XML get a special syntax for HTML Literals? closed
11:37:39 <gavinc> FabGandon, I wouldn't do that yet ;)
11:38:00 <cygri> topic: —lunch—
11:40:48 <FabGandon> FabGandon has left #rdf-wg
11:41:19 <Zakim> -Gavinc
11:47:56 <manu1> manu1 has joined #rdf-wg
11:50:36 <gkellogg> gkellogg has joined #rdf-wg
11:52:59 <Zakim> +??P0
11:53:05 <gkellogg> zakim, I am ??P0
11:53:05 <Zakim> +gkellogg; got it
12:20:06 <markus> Zakim, what's the code?
12:20:06 <Zakim> the conference code is 73394 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), markus
12:22:25 <Zakim> +??P1
12:22:36 <markus> Zakim, ??P1 is me
12:22:36 <Zakim> +markus; got it
12:22:56 <Guus> zakim, who is here?
12:22:56 <Zakim> On the phone I see Rhone_4, gkellogg, markus
12:22:57 <Zakim> On IRC I see gkellogg, manu1, AndyS1, tbaker, markus, Guus, cygri, pchampin, Zakim, Arnaud, davidwood, trackbot, manu, gavinc, RRSAgent, yvesr, sandro, ericP
12:24:11 <Zakim> +Tony
12:25:30 <ScottB> ScottB has joined #rdf-wg
12:25:52 <ScottB> Zakim, Tony is temporarily me
12:25:52 <Zakim> +ScottB; got it
12:25:58 <Zakim> +??P4
12:26:06 <manu1> zakim, I am ??P4
12:26:06 <Zakim> +manu1; got it
12:26:36 <Zakim> +Gavinc
12:40:11 <ericP> AndyS1, perl -pe 's/([^ ]+) ([^ ]+) (.*?) ([^ ]+) \./$4 { $1 $2 $3 }/'
12:42:26 <SteveS> SteveS has joined #rdf-wg
12:42:39 <tidoust> tidoust has joined #rdf-wg
12:43:58 <Guus> Guus has joined #rdf-wg
12:44:14 <yvesr> scribe: yvesr
12:45:44 <ivan> ivan has joined #rdf-wg
12:46:15 <Guus> zakim, who is here?
12:46:15 <Zakim> On the phone I see Rhone_4, gkellogg, markus, ScottB, manu1, Gavinc
12:46:17 <Zakim> On IRC I see ivan, Guus, tidoust, SteveS, ScottB, gkellogg, manu1, AndyS1, tbaker, markus, cygri, pchampin, Zakim, Arnaud, davidwood, trackbot, manu, gavinc, RRSAgent, yvesr,
12:46:17 <Zakim> ... sandro, ericP
12:46:56 <FabGandon> FabGandon has joined #rdf-wg
12:47:36 <yvesr> Francis Daoust (Joshfire) introducing himself
12:47:54 <yvesr> s/Francis/Francois
12:48:37 <AZ> AZ has joined #rdf-wg
12:48:48 <manu1> Manu Sporny, Digital Bazaar/PaySwarm and W3C Web Payments, RDFa, JSON-LD
12:49:00 <tidoust> [ I don't know what you call "Guest", but note I'm a regular participant of the RDF WG: http://www.w3.org/2000/09/dbwg/details?group=46168&public=1 ]
12:49:10 <yvesr> topic: JSON-LD Syntax document
12:49:25 <gkellogg> http://json-ld.org/spec/latest/json-ld-syntax/
12:49:38 <sandro> ahh, sorry, tidoust, I didn't realize that.
12:49:44 <yvesr> manu1: the document is in fairly good shape
12:49:55 <yvesr> ... most changes at this time are editorial
12:50:14 <yvesr> ... we had a number of issues in the past, e.g. language maps, and alignment of json-ld data model and rdf model
12:50:23 <yvesr> ... we had a number of discussions, that settled down
12:50:35 <yvesr> ... and the draft is getting into a stable form
12:50:45 <yvesr> ... we could have a quick run through the issues
12:51:15 <yvesr> Guus: can I search the document for issues?
12:51:21 <markus> JSON-LD syntax issue list: https://github.com/json-ld/json-ld.org/issues?milestone=2&page=1&sort=created&state=open
12:51:33 <yvesr> manu1: the major ones were cleared out when we took care of them, the main place for them is the issue tracker
12:51:45 <yvesr> ivan: in the document itself, I found only one
12:52:04 <yvesr> davidwood: is that not linked from the json-ld homepage?
12:52:14 <yvesr> manu1: probably not, it is a fairly new way for us of handling issues
12:52:32 <yvesr> manu1: we have a link to the issue tracker from the document
12:52:44 <yvesr> manu1: we can put a link on the json-ld page
12:52:46 <markus> the link it's just filtering syntax/API related issues
12:52:51 <yvesr> Guus: we will go through the issues
12:52:53 <manu1> ACTION: Manu put a link to the JSON-LD issue tracker on json-ld.org
12:52:54 <trackbot> Created ACTION-202 - Put a link to the JSON-LD issue tracker on json-ld.org [on Manu Sporny - due 2012-11-06].
12:52:57 <markus> s/it's just/is just/
12:53:28 <yvesr> manu1: we are not going through the issues that are resolved
12:54:00 <cygri> subtopic: Explicit mapping of RDF terminology to JSON-LD terminology
12:54:12 <yvesr> manu1: first issue, explicit mapping - https://github.com/json-ld/json-ld.org/issues/157
12:54:31 <cygri> davidwood, guus, can we get the issues on the big screen?
12:54:38 <yvesr> manu1: explicit mapping of rdf terminology to json-ld terminology
12:54:56 <cygri> q+
12:54:58 <yvesr> manu1: and mapping from the rdf data model to the json ld datamodel
12:55:12 <cygri> http://www.w3.org/2011/rdf-wg/wiki/JSON-LD_Data_Model
12:55:20 <yvesr> cygri: I have some work in progress on the wiki
12:55:39 <yvesr> ... I am working out what the json-ld data model actually is
12:55:48 <yvesr> ... I made an effort to spell those out
12:55:58 <davidwood> cygri, done
12:56:16 <yvesr> ... There are a couple of things that I haven't quite worked out yet
12:56:34 <yvesr> ... The JSON-LD community should look at it to check I have got it right
12:56:52 <yvesr> ... There are a number of differences there, but that's not news
12:57:18 <yvesr> ... What I have written could be an input to that mapping process
12:57:28 <yvesr> ... It is going to go in that appendix that lists the differences
12:57:36 <yvesr> ... And thereby states how the two map to each other
12:57:46 <yvesr> Guus: What is the nature of the mapping?
12:58:15 <yvesr> cygri: There is a distinction made in the JSON-LD data model that wouldn't survive in RDF
12:58:37 <yvesr> Guus: It is an important thing for people to read
12:58:48 <yvesr> cygri: It is going to be part of that appendix
12:58:54 <Guus> q?
12:59:01 <Guus> ack xygri
12:59:11 <Guus> ack cygri
12:59:20 <yvesr> sandro: Is there any use on highlighting those issues?
12:59:30 <yvesr> manu1: That's still up in the air
12:59:34 <ericP> maybe we should address "Language tags are not normalized to lower case." by removing that from RDF (I'm not sure it's widely implemented)
12:59:53 <yvesr> ... We want to do it in a way that makes the RDF WG happy with the document
12:59:56 <Guus> q+
13:00:00 <yvesr> ... It depends on the review comments we get
13:00:20 <yvesr> ... If it is not clear enough we'll find out a way to make it clear
13:00:36 <yvesr> Guus: A warning would be good, so that people are aware
13:00:45 <davidwood> ack Guus
13:01:22 <yvesr> manu1: We wanted to concentrate all those differences in one area, so that there is only one document to read to check all the differences
13:01:26 <yvesr> sandro: I have a problem with that
13:01:55 <gkellogg> q+
13:01:58 <yvesr> sandro: I am not happy about there being differences, but they are tolerable if people know they are operating outside of the RDF stack
13:02:01 <davidwood> q+
13:02:15 <yvesr> Guus: That's exactly why I would like to see an RDF note
13:02:34 <yvesr> sandro: JSON-LD claims to be Linked Data, but timbl's definition points to RDF
13:03:03 <yvesr> q?
13:03:05 <Guus> ack gkellog
13:03:07 <yvesr> ack gkellogg
13:03:34 <yvesr> gkellogg: Properties as bnodes comes from the fact we're using JSON
13:03:44 <yvesr> ... it is not intended to target a specific use-case
13:03:48 <sandro> q+ to say then just rule it out, as in Turtle
13:03:49 <pchampin> q+
13:04:01 <sandro> q-
13:04:14 <yvesr> ... Graph can be bnodes as well, for the same reason - it is a consequence of using JSON as a basis
13:04:20 <manu1> We absolutely should not go down the rabbit hole on this issue - let Richard finish his work, then we can review it.
13:04:22 <yvesr> ... We're not advocating using it
13:04:37 <Guus> ack davidwood
13:04:58 <yvesr> davidwood: I'd like to see, in the introduction, a reference to RDF
13:05:16 <yvesr> ... I'd like to see a statement saying that JSON-LD is based on the RDF model
13:05:31 <yvesr> ... I'd not like to see a mapping between two data models
13:05:57 <yvesr> ... Even though JSON allows you to make syntactic statement using blank nodes in various places, don't do that
13:06:07 <tidoust> q+
13:06:07 <sandro> It's just like in Turtle -- where you can say:   <a> _:x <b>    --- except the spec says DONT.
13:06:13 <Arnaud> +1 to david's proposal
13:06:21 <yvesr> ... In Mulgara, it was possible to have literals as predicates, but we never exposed it, never said it was a good idea
13:06:26 <yvesr> ... So nobody ever did it
13:06:29 <manu1> q+ to state that we're open to adding that to the spec.
13:06:33 <Guus> ack pchampin
13:07:04 <sandro> Agenda: http://www.w3.org/2011/rdf-wg/wiki/FTF3#Day_2
13:07:09 <yvesr> pchampin: Two remarks, the SPARQL data model superseeds RDF by allowing literals as subjects, so I don't see why it would be annoying for JSON-LD
13:07:57 <yvesr> ... Also, could there be a way around that? Could we assume that there is no mapping if a blank node appears in the predicate position?
13:08:05 <Guus> ack tidoust
13:08:31 <yvesr> tidoust: We will have to find the right level of enforcement in the spec
13:09:00 <Guus> ack manu1
13:09:01 <Zakim> manu1, you wanted to state that we're open to adding that to the spec.
13:09:01 <yvesr> ... I would suggest we just wait until it is phrased out in the spec so that we can see what works and what doesn't
13:09:24 <sandro> tidoust: MAY vs SHOULD vs MUST on JSON-LJ going beyond RDF data model.
13:09:35 <yvesr> manu1: We are open to putting something like that in the spe
13:09:36 <sandro> -1
13:09:41 <sandro> -.9
13:09:55 <yvesr> s/spe/spec
13:10:13 <yvesr> sandro: We should agree on the way the JSON-LD talks about RDF
13:10:27 <yvesr> ... Before more editorial work happens on those things in the JSON-LD spec
13:10:35 <yvesr> manu1: Most of these issues have been talked about before
13:10:39 <yvesr> sandro: But not addressed
13:10:55 <yvesr> manu1: That's why I would wait for these comments to be addressed in the spec text
13:11:15 <yvesr> Guus: I have heard three actions: 1) the appendix
13:11:34 <yvesr> ... 2) Explicit mention in the introduction
13:12:04 <yvesr> ... 3) Marking in the text where the differences are
13:12:15 <sandro> (as  "RDF Note:" or something)
13:12:42 <yvesr> davidwood: According to the JSON-LD tracker, cygri was blocked by the data model clarification
13:12:58 <yvesr> cygri: I clarified that already
13:13:06 <gkellogg> q+
13:13:08 <manu1> q+ to make a proposal
13:13:10 <manu1> q-
13:13:17 <yvesr> ... I don't think it needs any more details at that point
13:14:03 <sandro> q+ to comment on consensus
13:14:26 <Guus> q+
13:14:26 <mischat> mischat has joined #rdf-wg
13:14:30 <gkellogg> q-
13:14:32 <Guus> q-
13:14:35 <yvesr> Guus: I'd like to get to a rationale
13:14:42 <yvesr> manu1: We have a concensus among the editors
13:14:46 <davidwood> ack sandro
13:14:46 <Zakim> sandro, you wanted to comment on consensus
13:15:09 <yvesr> sandro: I am concerned that the discussion stops now that the editors are in consensus
13:15:24 <yvesr> manu1: We are going to make sure the RDF WG is happy with our proposed solution
13:15:30 <cygri> subtopic: Language containers
13:15:33 <yvesr> manu1: The next issue is issue 159
13:15:43 <yvesr> ... Adding language containers to JSON-LD
13:15:49 <yvesr> ... Asked for by the Drupal community
13:15:50 <sandro> sandro: sorry, I midunderstood.
13:16:00 <yvesr> ... That allows them to easily access language mapped values
13:16:23 <markus> example "title": { "en": "JSON-LD Syntax", "ru": "JSON-LD Синтаксис" }
13:16:31 <gkellogg> {"title": {"en": "Foo"}}
13:16:32 <yvesr> ... The idea is that you could express multiple languages in the JSON documents
13:16:41 <yvesr> ... And could be easily accessed
13:16:59 <Guus> q?
13:17:05 <yvesr> ... There is a question whether that is a difference with the RDF data model
13:17:11 <yvesr> ... But gkellogg has come up with a solution
13:17:11 <ericP> q+ to ask if this leads to more equivalences
13:17:19 <cygri> q+
13:17:23 <gavinc> +1 to awesome language maps
13:17:27 <yvesr> ivan: It is a little bit abstract for my taste
13:17:28 <cygri> q+ to ask if this is a pure syntax feature
13:17:36 <markus> http://json-ld.org/spec/latest/json-ld-syntax/#language-tagged-strings
13:17:41 <yvesr> ... Can you show in the document the kind of format we would end up with?
13:17:58 <markus> Example 28
13:18:06 <gavinc> Example 28: Language map expressing a property in three languages
13:18:14 <manu1> 4.3 Language-tagged Strings
13:18:33 <yvesr> ... It is in section 4.3 in the JSON-LD spec, Example 28
13:18:44 <gkellogg> http://json-ld.org/spec/latest/json-ld-syntax/#referencing-contexts-from-json-documents
13:18:53 <Guus> q?
13:19:21 <yvesr> davidwood: What's the RDF that's equivalent to that?
13:19:22 <gavinc> object.title.en == "JSON-LD Syntax"; object.title.ru == "JSON-LD Синтаксис";
13:19:47 <yvesr> ivan: It generates three triples, same subject, predicate dc:title, and three literal objects with three different languages
13:19:52 <gavinc> <> dc:title "JSON-LD Syntax"@en, "JSON-LD Синтаксис"@ru
13:20:02 <Guus> ack eripP
13:20:13 <Guus> ack aericP
13:20:24 <ivan> ack ericP
13:20:24 <Zakim> ericP, you wanted to ask if this leads to more equivalences
13:20:24 <Guus> ack ericP
13:20:26 <yvesr> ericP: There are two different ways of representing the same thing (language tags), is there a cost?
13:21:09 <yvesr> manu1: That's a consequence of the language @container
13:21:17 <gavinc> the magic is "@container": "@language"
13:21:24 <yvesr> ... That's just a way for developers to make it easier to use
13:21:31 <Guus> ack cygri
13:21:31 <Zakim> cygri, you wanted to ask if this is a pure syntax feature
13:21:51 <yvesr> cygri: I take it that this is purely a syntactical feature
13:22:06 <MacTed> MacTed has joined #rdf-wg
13:22:07 <yvesr> ... If you access it through the API, all you see is that there are three values with three languages
13:22:26 <yvesr> gkellogg: If you turn it into RDF, you get to the same representation
13:22:49 <gavinc> http://json-ld.org/spec/latest/json-ld-api/#expansion-1
13:23:02 <gavinc> "Expansion is the process of taking a JSON-LD document and applying a context such that all IRI, datatypes, and literal values are expanded so that the context is no longer necessary. JSON-LD document expansion is typically used as a part of other JSON-LD API methods."
13:23:43 <yvesr> manu1: Expansion gets rid of the context and expands the document according to it
13:23:57 <manu1> s/manu1/gkellogg/
13:24:00 <cygri> subtopic: Does JSON-LD address developers who don't know RDF?
13:24:17 <yvesr> cygri: There is a stated goal that JSON-LD can be used by JSON developers without having to know how it maps to RDF
13:24:21 <markus> Expansion of example 28 in my playground: http://bitly.com/Rmjmsk
13:24:29 <gavinc> +q
13:24:39 <yvesr> ... If developers are confronted to the same model but serialized in different ways
13:24:52 <yvesr> ... Then it defeats that goal, because it implies an underlying data model
13:24:57 <ivan> q+
13:25:06 <yvesr> ... They're not using JSON anymore, but they're using JSON-LD
13:25:07 <manu1> q+ to point out framing()
13:25:52 <sandro> cygri: Is there a non-expanded form, a form where people don't have to know it's JSON-LD?
13:25:54 <yvesr> manu1: I don't think the goal of JSON-LD is for the developers to not know they're doing JSON-LD
13:26:12 <davidwood> ack gavinc
13:26:23 <sandro> gavinc: Sure -- it's just whatever the API (eg twitter) provides.
13:26:23 <yvesr> gavinc: If you're treating as just JSON, I need to know the serialization is not going to change
13:27:09 <pchampin> @cygri: it's only "equivalent" from an RDF perspective, so the JSON-only dev is not impacted
13:28:06 <Guus> q?
13:28:07 <yvesr> cygri: Maybe I am getting this wrong, but part of the design rationale is that you can treat it as JSON and you'll be fine
13:28:21 <markus> q+ to point to flattening and framing (experimental)
13:28:24 <gavinc> Just as JSON, means that it's not self describing while I'm pretending it's just JSON
13:29:07 <yvesr> ... I am serializing two facts for two languages. If a JSON developer wants to access those two facts, then there needs to be a predictable way of accessing them
13:29:34 <yvesr> ... My concern is that we create something that is inconvenient to JSON developers
13:30:01 <gavinc> There is! Framing and expansion, but you DON'T have to use them
13:30:01 <yvesr> ... The claim that only JSON tools are necessary to deal with JSON-LD is not quite true
13:30:06 <pchampin> isn't what Framing is about?
13:30:39 <gavinc> pchampin, yep
13:30:41 <yvesr> manu1: Twitter authors their JSON in a specific way, they could provide JSON-LD and not changing the way they publish the data
13:30:46 <markus> yes, that's what framing is about.. there's also a flattening method which returns a predictable structure
13:30:59 <manu1> s/manu1/gavinc/
13:31:00 <manu1> There are lots and lots of different ways you can use JSON-LD... there are some ways that you can use it that will shoot your developers in the foot .
13:31:10 <Zakim> +OpenLink_Software
13:31:20 <MacTed> Zakim, OpenLink_Software is temporarily me
13:31:20 <Zakim> +MacTed; got it
13:31:23 <MacTed> Zakim, mute me
13:31:23 <Zakim> MacTed should now be muted
13:31:38 <Guus> ack ivan
13:31:39 <ivan> q-
13:31:50 <davidwood> …so by "work with" you really mean "read and access", not "write".  Is that correct?
13:31:52 <manu1> q-
13:31:59 <markus> q-
13:32:03 <cygri> Sorry, but this is RDF/XML all over again.
13:32:06 <cygri> subtopic: Issue overview
13:32:09 <yvesr> Guus: can we have a meta-view on the other issues? Which ones are relevant?
13:32:17 <sandro> yes, cygri, it is.  :-]
13:32:29 <sandro> there are reasons RDF/XML is as it is.  :-)
13:32:56 <yvesr> manu1: cygri is dealing with 158 and 169
13:33:11 <yvesr> ... 170 was brought up by peter
13:33:30 <yvesr> ... We need to discuss more with him to identify what the issue was
13:33:46 <sandro> q+ to ask in list and set what triples those map to (or really if you know)
13:33:56 <markus> s/cygri is dealing with 158/ygri is dealing with 157/
13:33:59 <yvesr> ... 174 is about aligning the two data models in the spec
13:34:22 <gavinc> Yep! It's RDF/XML all over again only this time for javascript and not the only serialization, and not adding freaking namespaces to XML, and not including the word RDF in the name, and not using a document markup language for data :P
13:34:40 <yvesr> manu1: mhausenblas said his concerns are subsumed by peter's concerns
13:35:02 <sandro> q-
13:35:32 <yvesr> Guus: We would like to have documents in LC state by the end of January
13:35:55 <yvesr> manu1: The only thing that would hold it up is if we keep going back and forth on the data model
13:36:12 <yvesr> ... Especially if people keep saying that it is RDF/XML all over again without being more specific
13:36:25 <trackbot> trackbot has joined #rdf-wg
13:36:38 <yvesr> Guus: At the moment I am confident these issues will be resolved
13:36:47 <sandro> q+
13:37:00 <yvesr> manu1: The most controversial thing is the data model alignment
13:37:02 <Guus> ack sandro
13:37:10 <cygri> subtopic: Sets and lists
13:37:18 <yvesr> sandro: Do you have a plan for how JSON sets and lists appear in RDF triples?
13:37:34 <yvesr> gkellogg: The reason lists were added was to have a way to serialize RDF lists
13:37:44 <yvesr> ... The data model for JSON LD lists is the RDF data model for lists
13:37:50 <yvesr> ivan: and for sets?
13:38:01 <yvesr> ... Why do we need a separate keyword for that?
13:38:06 <Guus> q?
13:38:23 <cygri> q+ to say JSON-LD lists are not RDF lists
13:38:37 <yvesr> gkellogg: It is possible to add a context keyword for lists and sets
13:39:10 <yvesr> tidoust: For JSON developers if it useful to have something you can parse in the same way for lists and sets
13:39:17 <yvesr> ... For symmetry it's good to have it
13:39:19 <cygri> q-
13:39:44 <gavinc> "this"
13:39:49 <yvesr> sandro: This has the potential to be a showstopper
13:40:00 <yvesr> manu1: Why are sets and lists a showstopper?
13:40:09 <yvesr> ... We are not deviating from the RDF data model
13:40:14 <gavinc> @set and @list define how to convert a javascript arrary into RDF
13:40:14 <cygri> gkellog, a list in RDF is a blank node with two properties rdf:first and rdf:rest; in JSON-LD a list is actually a part of the data model.
13:40:54 <yvesr> cygri: gkellogg said that lists in JSON-LD are the same as in RDF, which I think is not quite true - there are no lists in the RDF data model
13:41:00 <markus> q+ to ask whether that's true for Turtle as well
13:41:15 <gavinc> markus, yes it is
13:41:30 <yvesr> ... In JSON-LD a list stays a list unless you convert it to RDF, and then it disappears in triples
13:41:53 <yvesr> ... and blank nodes
13:42:28 <yvesr> ... In the JSON-LD data model there is a list construct, but there is no list construct in the RDF data model
13:42:31 <gavinc> Yes, JSON-LD gets it right :P
13:43:06 <yvesr> ivan: I don't want it to be a show stopper
13:43:18 <yvesr> ... But I feel uneasy about having a separate JSON-LD data model
13:43:33 <yvesr> ... But I understand it's a way to sell the spec to people who don't want to hear about RDF
13:43:41 <yvesr> ... We need to make it very clear
13:43:50 <markus> +1 to what ivan just said
13:43:53 <yvesr> ... We're not trying to sell Turtle to people who are not RDF people
13:44:02 <gavinc> @set is syntax
13:44:08 <gavinc> not really modelish
13:44:17 <Guus> q?
13:44:19 <markus> q-
13:44:23 <yvesr> sandro: I think I agree, but the semantics of sets are not the same as the semantics of lists of values, but perhaps not in a way that matters
13:44:39 <yvesr> ivan: If we didn't have to sell it to people outside of RDF, we wouldn't have these issues
13:44:44 <sandro> s/lists of values/multi-values/
13:44:54 <gkellogg> http://json-ld.org/spec/latest/json-ld-api/
13:44:56 <markus> https://github.com/json-ld/json-ld.org/issues?milestone=1&page=1&sort=created&state=open
13:45:24 <yvesr> manu1: cygri has captured the differences pretty clearly, should we go through those differences?
13:45:31 <cygri> http://www.w3.org/2011/rdf-wg/wiki/JSON-LD_Data_Model
13:45:40 <yvesr> subtopic: Differences between JSON-LD Data Model and RDF
13:45:46 <cygri> q+
13:45:48 <yvesr> manu1: Reviewing what the differences are might be helpful
13:46:24 <manu1> http://www.w3.org/2011/rdf-wg/wiki/JSON-LD_Data_Model
13:46:35 <yvesr> Guus: let's focus on issues you'd like feedback on
13:46:50 <yvesr> manu1: The differences with the RDF data model are at the bottom of that document
13:47:07 <cygri> q-
13:47:18 <yvesr> ... We're fine with putting spec text saying that authors SHOULD NOT use blank nodes as graph names
13:47:22 <Guus> q?
13:47:33 <yvesr> ... Unconnected nodes will result in no RDF data being produced
13:47:49 <yvesr> ... I don't see lists as not part of the data model
13:47:57 <cygri> q+
13:48:04 <gavinc> JSON-LD does lists nicely ;)
13:48:18 <yvesr> cygri: If lists are not part of the data model, how do you encode them?
13:48:34 <yvesr> ... The rdf:first stuff happens only in the conversion to RDFD
13:48:38 <yvesr> s/RDFD/RDF
13:49:09 <yvesr> manu1: We have two different view-points, I think it is just syntax
13:49:21 <yvesr> ... I don't think this discussion on the data model has an impact on developers
13:49:28 <yvesr> ... It doesn't change what JSON LD is
13:49:43 <yvesr> ... I feel it is important to agree on this point
13:49:46 <Guus> q?
13:49:53 <Guus> ack cygri
13:50:10 <yvesr> cygri: Even though I think it is different that what RDF is doing, I think it is a good way of doing it
13:50:24 <yvesr> ... I wonder whether it is worth documenting this pattern of a 'well formed list'
13:50:48 <yvesr> ... And ways of putting it straight in the data modle
13:50:53 <yvesr> s/modle/model
13:51:24 <yvesr> manu1: We support JSON-native types, numbers, booleans, strings
13:51:27 <sandro> +1 cygri:  JSON-LD approach to lists is a somewhat stronger version of RDF "well-formed lists" and I like that.
13:51:41 <yvesr> ... We might put spec text to make language tags lower case
13:52:12 <ScottB> +1 to well formed lists
13:52:19 <gavinc> I assume it's similar the text needed in TriG http://dvcs.w3.org/hg/rdf/raw-file/default/trig/index.html#terms-blanks-nodes
13:52:25 <Guus> q?
13:52:30 <yvesr> Zakim, who is speaking?
13:52:42 <Zakim> yvesr, listening for 12 seconds I heard sound from the following: Rhone_4 (41%)
13:52:48 <trackbot> trackbot has joined #rdf-wg
13:53:16 <markus> yvesr, it was me
13:53:37 <gavinc> Okay, THAT is an issue :(
13:54:03 <yvesr> cygri: There might be an issue around bnode scoping
13:54:22 <yvesr> gavinc: I think we solved it already within the WG, but I am not sure JSON-LD followed that model
13:54:38 <yvesr> gkellogg: In TriG, the two same bnode identifiers in two different graphs do not identify the same resource
13:54:57 <yvesr> (mixed views from the room whether it is correct or incorrect)
13:55:01 <sandro> issue-22?
13:55:06 <trackbot> ISSUE-22 -- Does multigraph syntax need to support empty graphs? -- closed
13:55:06 <trackbot> http://www.w3.org/2011/rdf-wg/track/issues/22
13:55:06 <cygri> ISSUE-22?
13:55:07 <trackbot> ISSUE-22 -- Does multigraph syntax need to support empty graphs? -- closed
13:55:07 <trackbot> http://www.w3.org/2011/rdf-wg/track/issues/22
13:55:12 <sandro> issue-21?
13:55:12 <trackbot> ISSUE-21 -- Can Node-IDs be shared between parts of a quad/multigraph format? -- closed
13:55:12 <trackbot> http://www.w3.org/2011/rdf-wg/track/issues/21
13:55:18 <yvesr> manu1: bnode identifiers are scoped to the document, and it is the same in JSON-LD
13:56:05 <markus> so, http://dvcs.w3.org/hg/rdf/raw-file/default/trig/index.html#terms-blanks-nodes is wrong on this?
13:56:23 <manu1> this is the resolution on file -  Close ISSUE-21 saying Yes, Node IDs are document scope in the multi-graph syntax (TriG, etc)
13:56:31 <Guus> q?
13:56:39 <yvesr> Guus: Let's move on
13:56:47 <cygri> markus, yes, that's wrong.
13:56:54 <markus> good!
13:57:01 <ivan> q+
13:57:18 <manu1> http://json-ld.org/spec/latest/json-ld-api/
13:57:19 <yvesr> topic: JSON-LD API document
13:57:32 <yvesr> manu1: The API document is a little less controversial
13:57:36 <markus> issues -- https://github.com/json-ld/json-ld.org/issues?milestone=1&page=1&sort=created&state=open
13:57:42 <yvesr> ... It is just a matter of implementing how the syntax plays out
13:57:48 <sandro> sandro: Gavin, Pat says there is a clear meaning in RDF-Semantics for a blank node being shared between graphs.   (For myself -- I just imagine there's a large graph they are both subgraphs of.)
13:58:03 <yvesr> ... Writing the API document was relatively easy, and it has less issues on it
13:58:43 <yvesr> ... Defines operations, like compact, expand, and to rdf
13:58:51 <markus> supported methods: http://json-ld.org/spec/latest/json-ld-api/#jsonldprocessor
13:58:53 <yvesr> ... Compact tries to minimise a JSON-LD document
13:59:12 <yvesr> ... Expand does the opposite, expands everything to full IRIs for examples
13:59:15 <sandro> concerned a little about the hedging around 'compact'.     is it not proven/complete?
13:59:27 <yvesr> ... It removes the context entirely
13:59:42 <yvesr> ... Flatten takes a deeply nested JSON object and will coalesce everything that has the same id
14:00:32 <yvesr> ... To and From RDF take a JSON-LD document and output quads
14:00:59 <yvesr> ... Or inflate a JSON-LD document from quads
14:01:01 <markus> link to my playground which shows how the various methods work: http://bit.ly/JsonLDplay (official playground has no flattening functionality yet)
14:01:11 <yvesr> ... We will not include graph normalization
14:01:13 <gavinc> ah ha, there we go " needs a new semantics"
14:01:17 <sandro> what is RDF graph normalization?    canonicalization?
14:01:19 <Guus> q?
14:01:21 <yvesr> ... Although there are a couple of implementations
14:01:26 <gavinc> okay, so yes, we changed the semantics of blank nodes
14:01:28 <gavinc> excellent
14:01:45 <Guus> manu.pls
14:01:52 <yvesr> ... Instead, developers should use the framing API call
14:01:53 <sandro> I don't think so, gavinc.    shared blank nodes are fine in 2004 rdf-mt
14:02:02 <gavinc> PatH said " needs a new semantics"
14:02:12 <AndyS1> AndyS1 has joined #rdf-wg
14:02:18 <sandro> link, gavinc?    (I'm confident that was about something else)
14:02:23 <gavinc> http://www.w3.org/2011/rdf-wg/meeting/2012-09-12#resolution_2
14:02:30 <cygri> subtopic: API vs. Algorithms
14:02:41 <yvesr> ivan: From the RDF WG point of view, what's absolutely necessary is the RDF conversion algorithm
14:03:00 <yvesr> ... The way it is described rely on other algorithms described there e.g. expand
14:03:14 <yvesr> ... So it means the whole section needs to be standardized as a whole
14:03:36 <yvesr> ... However the API document goes beyond what the RDF WG is doing, not even sure it is in our charter
14:04:01 <yvesr> ... Aside from that, it is a different piece of work - how JSON developers would interact with a JSON-LD API
14:04:23 <yvesr> ... I would have prefered to have conversion algorithms to be part of the JSON-LD rec published by this group and stop there
14:04:25 <manu1> q+ to respond to toRDF/fromRDF proposal.
14:04:35 <yvesr> ... (i.e. not include the rest of the API document)
14:04:53 <yvesr> Guus: We could publish the API as a note
14:04:55 <cygri> q+
14:04:59 <sandro> gavinc, I think that's about something else, but ... I agree that's not how it appears from the record.   I guess we need to clarify with Pat.
14:05:14 <yvesr> ... What do the editors think?
14:05:19 <gavinc> meh, someone else can complain later ;)
14:05:21 <yvesr> manu1: I don't think that's a good idea
14:05:48 <yvesr> ... I believe any W3C group should generate specifications that make sure technologies can be adopted rapidly by the web development community
14:05:59 <sandro> q+ to ask about CR exit criteria
14:06:12 <sandro> q+ to ask about CR exit criteria (as a way to clarify compaction, expansion, etc)
14:06:17 <Guus> ack ivan
14:06:24 <Guus> ack manu1
14:06:24 <Zakim> manu1, you wanted to respond to toRDF/fromRDF proposal.
14:07:09 <yvesr> gkellogg: The disagreement is about the rest of the document, not the expand/to/from algorithms
14:07:19 <sandro> q-
14:07:45 <yvesr> ... The issue with that is if one of our goal is to ensure interoperability is how to demonstrate it
14:08:11 <yvesr> cygri: I kind of see three different parts to this technology presented in those two documents
14:08:37 <yvesr> ... Much of the syntax document is putting a friendly face to the algorithms
14:08:46 <yvesr> ... The algorithms actually explain what is happening
14:09:48 <yvesr> ... Finally part of the work is on APIs
14:10:02 <manu1> q+
14:10:11 <yvesr> cygri: maybe this separation is useful to structure the conversation
14:10:20 <manu1> q-
14:10:40 <davidwood> ack cygri
14:10:47 <markus> q+
14:10:50 <yvesr> cygri: Most of section 4 is similar to the data model explanation
14:11:10 <yvesr> ivan: Algorithms are absolutely necessary
14:11:20 <manu1> q+ to discuss reorganization.
14:11:20 <yvesr> Guus: Is reorganisation of the document useful?
14:11:21 <tidoust> q+
14:11:36 <yvesr> sandro: Parts of the algorithms are ancillary
14:12:07 <yvesr> ... We need to put at risks those parts
14:12:12 <yvesr> ... e.g. compaction
14:12:24 <yvesr> manu1: We have more than two implementations that pass the compaction tesst
14:12:41 <yvesr> sandro: If it's inside the group, not much of a test
14:12:41 <gavinc> ?
14:12:44 <yvesr> (room disagrees)
14:13:00 <markus> q-
14:13:12 <yvesr> Guus: it's always possible to consider that some features are at risk
14:13:42 <yvesr> manu1: We've already eliminated the number of API features - we eliminated graphify, framing, canonicalisation
14:13:54 <yvesr> ... What remains is what we believe is most useful to developers
14:14:04 <manu1> q-
14:14:07 <yvesr> ... From a personal stand-point I would be opposed to removing anything else
14:14:19 <yvesr> ivan: We're having terminological issues, it would be good to separate that
14:14:39 <yvesr> ... In mine, what's in section 4 is algorithms, section 3 are APIs
14:14:47 <yvesr> ... They are two different things
14:14:55 <yvesr> ... I do not dispute algorithms
14:15:06 <yvesr> ... I dispute APIs
14:15:11 <manu1> q+ to talk about WebIDL
14:15:16 <tidoust> q-
14:15:22 <yvesr> ... As this is a kind of work we have not done
14:15:45 <Guus> ack manu1
14:15:45 <Zakim> manu1, you wanted to talk about WebIDL
14:15:50 <tidoust> q+
14:16:00 <yvesr> manu1: The reason we have WebIDL in there is that we feel that without it people wouldn't use it
14:16:03 <Guus> ack todoust
14:16:10 <Guus> ack tidoust
14:16:20 <yvesr> tidoust: sandro's proposition to put it at risk with high out-of-CR criteria is good
14:16:49 <sandro> q?
14:16:56 <yvesr> ... At risk might be a good way to convey those concerns
14:17:25 <yvesr> Guus: Can we get some consensus on the different in scope between section 3 and 4
14:17:27 <cygri> q+ to ask about Rec/Note status
14:17:33 <sandro> +1 manu "JSON-LD Core Processing"
14:17:51 <yvesr> manu1: We could rename the document and put the API section at risk
14:17:56 <yvesr> Guus: the API could become a note
14:18:18 <yvesr> ... Then we can keep the algorithms as part of the rec
14:18:33 <yvesr> manu1: Did the web app WG publish notes for their API
14:18:57 <yvesr> sandro: They are publishing APIs that are implemented in the browser
14:19:53 <cygri> q?
14:19:56 <yvesr> ivan: JSON-LD APIs can be used outside of browsers, so very different from the Web App WG
14:20:04 <sandro> +1 ivan: I might use JSON-LD outside of a browser, and far away from JavaScript
14:20:20 <yvesr> Guus: We don't have to decide now
14:20:25 <Guus> q?
14:20:30 <Guus> ack cygri
14:20:30 <Zakim> cygri, you wanted to ask about Rec/Note status
14:21:08 <yvesr> cygri: I wanted to agree with sandro - we don't have the right people to publish certain kind of things
14:21:18 <yvesr> ... We don't have the technical expertise for this kind of things
14:21:29 <markus> q+
14:21:32 <yvesr> ... For example around defining APIs
14:21:51 <yvesr> ... There is a bit of a lack of confidence that we have the expertise to do it well
14:21:58 <sandro> cygri: The compisition of the RDF WG is an issue here.  I'm not confident about this WG publishing certain kinds of things, since we don't have the deep technical expertise.   Eg normatively defining APIs.    Some people here know a lot about that, but it's not why we joined the WG.    So that might push us towards not being as normative.
14:21:59 <Guus> ack markus
14:22:20 <yvesr> markus: What about the conformance section?
14:22:41 <yvesr> tidoust: In the conformance section there are JSON-LD documents and JSON-LD processes
14:23:12 <yvesr> ... The output needs to be defined somehow
14:23:22 <tidoust> s/JSON-LD processes/JSON-LD processors/
14:23:27 <yvesr> markus: Can we talk about JSON-LD processors? Do we just talk about algorithms?
14:23:45 <gavinc> Example from Turtle "A conforming Turtle parser is a system capable of reading Turtle documents on behalf of an application. It makes the serialized RDF graph, as defined in section 7 Parsing, available to the application, usually through some form of API."
14:23:57 <gavinc> make a nice shiny link to the note for the API
14:24:09 <FabGandon> FabGandon has joined #rdf-wg
14:24:15 <gavinc> since webIDL can't be implemented in every language
14:24:16 <yvesr> ivan: The same thing could be done for a JSON-LD processor
14:24:41 <Guus> q?
14:24:45 <yvesr> ... I should be able to implement a JSON-LD processor without having to conform to WebIDL
14:24:55 <yvesr> tidoust: WebIDL actually isn't specific to the Web
14:25:08 <gavinc> I should be able to implement a JSON-LD processor in hardware ;)
14:25:27 <ivan> +1 to gavin
14:25:49 <sandro> looking at the Java binding for WebIDL
14:25:55 <yvesr> manu1: Just a quick chat about the timeline - we should be able to hit the January deadline
14:26:07 <sandro> http://www.w3.org/TR/WebIDL-Java/
14:26:14 <yvesr> ... But it all depends on the discussions with the RDF WG
14:26:27 <sandro> should we do WebIDL for Turtle?  L-)
14:26:38 <yvesr> manu1: We have conforming implementations, we have a test suite
14:27:05 <yvesr> ... Does there need to be a discussion about implementations needing to be out of the group for passing CR?
14:28:05 <yvesr> davidwood: We need to discuss notes
14:28:14 <yvesr> topic: Possible WG Notes
14:28:44 <ScottB> I'll have to drop off shortly regardless
14:30:18 <davidwood> Notes
14:30:18 <davidwood> - RDF 1.1 Primer
14:30:18 <davidwood> - RDF 1.1 New Features and Migration
14:30:18 <davidwood> 
14:30:18 <davidwood> Possible Notes
14:30:18 <davidwood> - Show how g-boxes and g-snaps may be identified by defining predicates.
14:30:18 <davidwood> - JSON-LD Recipes
14:30:19 <davidwood> - RDF-JSON
14:30:19 <davidwood> - Intro on MT in RDF semantics
14:30:19 <davidwood> - Should there be an rdf:Graph construct, or something like that? What new vocabulary should be added to RDF to talk about graphs? (formerly ISSUEs 35, 38)
14:30:20 <davidwood> - JSON-LD / RDF data model differences
14:30:20 <davidwood> 
14:30:40 <Zakim> -ScottB
14:30:46 <Zakim> -MacTed
14:30:51 <Zakim> -Gavinc
14:30:56 <gkellogg> zakim, mute me
14:30:56 <Zakim> gkellogg should now be muted
14:32:02 <manu1> -1 to JSON-LD Recipes (no editors / not enough time) ... -1 to JSON-LD / RDF Data Model differences - it would be a very small document and it probably needs to be in the RDF appendix that Richard is writing.
14:32:11 <Zakim> -manu1
14:44:55 <LeeF> LeeF has joined #rdf-wg
14:47:32 <AndyS1> AndyS1 has left #rdf-wg
14:50:08 <FabGandon> FabGandon has joined #rdf-wg
15:04:09 <SteveS> SteveS has joined #rdf-wg
15:05:14 <gkellogg> zakim, unmute me
15:05:14 <Zakim> gkellogg should no longer be muted
15:06:45 <gkellogg> zakim, mute me
15:06:45 <Zakim> gkellogg should now be muted
15:11:35 <tidoust> scribe: Francois
15:11:38 <tidoust> scribenick: tidoust
15:11:51 <ivan> zakim, who is here?
15:11:51 <Zakim> On the phone I see Rhone_4, gkellogg (muted), markus
15:11:52 <Zakim> On IRC I see SteveS, FabGandon, LeeF, trackbot, MacTed, mischat, AZ, ivan, Guus, tidoust, gkellogg, manu1, AndyS, tbaker, markus, cygri, pchampin, Zakim, Arnaud, davidwood, manu,
15:11:52 <Zakim> ... gavinc, RRSAgent, yvesr, sandro, ericP
15:12:14 <tidoust> davidwood: we'll be spending the rest of the time discussing notes.
15:12:52 <tidoust> … Primer and New Features and Migration will both be notes as agreed yesterday. We have editors.
15:13:08 <tidoust> … The rest of the documents (shown on screen) were taken from minutes over the last two days.
15:13:22 <tidoust> … We don't have editors and so on. It's probably time to decide.
15:13:30 <cygri> subtopic: Possible Note on Practical Use Cases of RDF Datasets
15:13:56 <tidoust> davidwood: The first one is "show how g-boxes and g-snaps may be identified by defining predicates".
15:14:19 <tidoust> Ivan: same as the one before the last one?
15:14:52 <tidoust> davidwood: "Should there an ref:Graph construct, or something like that?"
15:15:07 <tidoust> … [merging both proposals into one]
15:15:28 <tidoust> cygri: That could be "Addressing practical use cases of RDF datasets"
15:15:35 <tidoust> … Sandro was the main driver behind that.
15:15:59 <tidoust> Ivan: we should ask him.
15:16:27 <tidoust> davidwood: who's the logical person? Sandro? He might well be too busy. That said, he's provided some examples already.
15:16:46 <tidoust> Ivan: You know how it is. Making a formal note is much more work.
15:17:15 <tidoust> EricP: I suspect Sandro and I will geek on that anyway. Why not action me to discuss that with Sandro?
15:17:26 <tidoust> davidwood: should we action you to find an editor for the spec?
15:17:33 <tidoust> EricP: fair enough.
15:18:05 <davidwood> ACTION: ericp to identify an editor for a NOTE: Practical Use Cases of RDF Datasets
15:18:05 <trackbot> Created ACTION-203 - Identify an editor for a NOTE: Practical Use Cases of RDF Datasets [on Eric Prud'hommeaux - due 2012-11-06].
15:18:09 <tidoust> Antoine: Just a note that we cannot define formally that a URI identifies a g-box because we don't have a proper g-box.
15:18:20 <tidoust> … That cannot go beyond a regular English sentence.
15:18:27 <tidoust> cygri: It could be in theory.
15:18:48 <tidoust> Pierre-Antoine: How is that different from saying that foaf:person is not a person?
15:19:08 <tidoust> Antoine: [scribe missed answer]
15:19:54 <tidoust> … People use foaf:person for Persons. They refer to the English definition in a dictionary to know that a "person" has to be used with a real person, and that's enough in most cases.
15:20:35 <tidoust> ISSUE-32?
15:20:35 <trackbot> ISSUE-32 -- Can we identify both g-boxes and g-snaps? -- closed
15:20:35 <trackbot> http://www.w3.org/2011/rdf-wg/track/issues/32
15:20:36 <davidwood> PROPOSED: The WG will produce a NOTE: Practical Use Cases of RDF Datasets.  This Note will include information from ISSUEs 32, 35 and 38.
15:20:43 <tidoust> ISSUE-35?
15:20:43 <trackbot> ISSUE-35 -- Should there be an rdf:Graph construct, or something like that? -- closed
15:20:43 <trackbot> http://www.w3.org/2011/rdf-wg/track/issues/35
15:20:46 <tidoust> ISSUE-38?
15:20:46 <trackbot> ISSUE-38 -- What new vocabulary should be added to RDF to talk about graphs? -- closed
15:20:46 <trackbot> http://www.w3.org/2011/rdf-wg/track/issues/38
15:21:10 <tidoust> davidwood: see proposal. How do people feel about that?
15:21:21 <davidwood> ISSUE-32
15:21:27 <davidwood> ISSUE-32?
15:21:27 <trackbot> ISSUE-32 -- Can we identify both g-boxes and g-snaps? -- closed
15:21:27 <trackbot> http://www.w3.org/2011/rdf-wg/track/issues/32
15:21:36 <AZ> AZ: it's not different from foaf:Person, formally speaking, foaf:Person does not necessarily identify persons
15:21:49 <davidwood> PROPOSED: The WG will produce a NOTE: Practical Use Cases of RDF Datasets.  This Note may include information from ISSUEs 32, 35 and 38.
15:22:05 <ericP> +1
15:22:14 <tidoust> cygri: move from "should" to "may" as there are things we said we shouldn't do anything about.
15:23:06 <davidwood> PROPOSED: The WG intends to produce a NOTE: Practical Use Cases of RDF Datasets.  This Note may include information from ISSUEs 32, 35 and 38.
15:23:17 <cygri> +1
15:23:18 <AZ> +1
15:23:19 <tbaker> +1 - would welcome this (on the basis of what I'm reading in irc...)
15:23:21 <tidoust> … For some of the things that are listed there, we want to produce things but that may not happen for various reasons and there are other priorities that shouldn't be delayed as a consequence.
15:23:21 <ericP> +1
15:23:22 <gkellogg> +1
15:23:29 <yvesr> +1
15:23:37 <davidwood> +1
15:24:06 <markus> +1
15:24:09 <davidwood> RESOLVED: The WG intends to produce a NOTE: Practical Use Cases of RDF Datasets.  This Note may include information from ISSUEs 32, 35 and 38.
15:24:39 <davidwood> Subtopic: Possible JSON Notes
15:24:47 <davidwood> - JSON-LD Recipes
15:24:58 <davidwood> - RDF-JSON
15:25:34 <tidoust> davidwood: possibilities include JSON-LD Recipes which are in the air for some time now.
15:25:44 <tidoust> … JSON-LD / RDF data model differences
15:25:55 <tidoust> cygri: shouldn't be there, as it's going to be in the Syntax spec.
15:26:01 <tidoust> … That needs to be normative.
15:26:11 <tidoust> davidwood: right, we have agreement. Let's drop it from the list of Notes.
15:26:40 <tidoust> … JSON-LD Recipes, I think this is overcome by events and that we shouldn't be doing recipes at this time.
15:26:53 <gkellogg> Would be nice, but limited bandwidth to do this.
15:26:59 <gkellogg> zakim, unmute me
15:26:59 <Zakim> gkellogg should no longer be muted
15:27:02 <tidoust> Guus: My proposal is not to do anything unless someone from JSON-LD task force really wants to do this.
15:27:17 <ivan> q+
15:27:18 <tidoust> Markus: I don't think there's a real need for this. The spec already has lots of examples.
15:27:37 <davidwood> JSON-LD editors: JSON-LD specs have adequate examples.  No recipies Note needed.
15:27:37 <tidoust> Guus: and you have more than enough on your hands. I would suggest this is low priority.
15:27:41 <davidwood> q?
15:27:44 <davidwood> ack ivan
15:27:56 <Arnaud> q+
15:28:34 <cygri> q+
15:28:36 <tidoust> Ivan: It's not exactly "recipe" but, yesterday, when we discussed the Primer, having a section with different serializations could be a good idea so examples in Turtle and JSON-LD at a minimum would be good?
15:28:48 <tidoust> Guus: It's on my list, yes.
15:28:50 <davidwood> ack Arnaud
15:28:56 <ivan> ack Arnaud
15:28:57 <gkellogg> happy to help.
15:29:32 <tidoust> Arnaud: meta-question here. We're listing notes that we'd like to produce. Do we expect to do all of those by the end of January (end of charter)? Or do we simply assume we will be re-chartered?
15:29:54 <tidoust> Guus: By that time, hopefully, we'll ask for extension as specs will be in advanced phases.
15:30:16 <davidwood> ack cygri
15:30:22 <tidoust> davidwood: If for some reason, we end up not being extended, then yes, we'll drop these notes on the way.
15:30:24 <cygri> Quoting from F2F1 minutes: RESOLVED: (1) Incubate on something like JSON-LD, (2) make a REC on something like Talis RDF/JSON, and (3) make a Note on current practice stuff like Linked Data API. http://www.w3.org/2011/rdf-wg/meeting/2011-04-13#resolution_4
15:30:46 <tidoust> cygri: On the topic of JSON-related documents, I'd like to remind the group of a resolution we made previously.
15:31:22 <Zakim> +LeeF
15:31:31 <tidoust> … 3 docs were mentioned. I think that this resolution no longer reflects what we want to do. Resolve that we're not going to do numbers 2 and 3 from that?
15:33:00 <tidoust> Guus: There was a very clean separation at first. Different roles for these serializations. We could still consider whether that's something we want to publish as a Note. Useful for the community or nobody will care? That's still a decision we have to make, because the document is there.
15:33:09 <tidoust> davidwood: I agree. How do you feel about it?
15:33:30 <tidoust> Guus: I haven't been an active user. I'd like to have more data on the data.
15:33:49 <tidoust> davidwood: Do I recall that you use the RDF/JSON serialization?
15:34:01 <tidoust> LeeF: I don't think so, but it is similar.
15:34:19 <tidoust> … We're using it somehow in other areas.
15:34:27 <tidoust> davidwood: Would you support a Note on this?
15:34:31 <markus> I'm a bit worried that publishing a note will cause more confusion than it helps
15:34:33 <tidoust> LeeF: Sure.
15:34:43 <gkellogg> +1 to markus
15:35:00 <tidoust> davidwood: you represent a company that uses something that is similar. Would a W3C Note help you on any way?
15:35:13 <ivan> +1 to markus
15:35:14 <tidoust> LeeF: no, I don't think so. It is mainly internal.
15:35:51 <tidoust> … I don't see a big need for it.
15:36:11 <davidwood> PROPOSED: The RDF WG will not publish a Note like RDF/JSON.
15:36:17 <ivan> =1
15:36:18 <tidoust> davidwood: I hear you don't need it. I hear Markus saying that it would cause confusion among the public, supported by others in the group
15:36:20 <ivan> +1
15:36:20 <Arnaud> +1
15:36:20 <gkellogg> +1
15:36:21 <tidoust> +1
15:36:21 <pchampin> +1
15:36:22 <markus> +1
15:36:24 <yvesr> +1
15:36:24 <AZ> +1
15:36:25 <LeeF> +1
15:36:27 <davidwood> +1
15:36:29 <Guus> +0
15:36:31 <cygri> ±0
15:36:33 <tbaker> +0
15:36:37 <tidoust> davidwood: I'm proposing not to publish the spec as a note.
15:36:41 <Guus> +0
15:36:57 <davidwood> RESOLVED: The RDF WG will not publish a Note like RDF/JSON.
15:37:05 <davidwood> Subtopic: Possible Semantics Notes
15:37:16 <ericP> +ø
15:37:26 <AZ> q+
15:37:35 <Zakim> -gkellogg
15:37:40 <tidoust> davidwood: In the list of semantics notes, we have an intro on Model Theory in RDF semantics which I think was overcome by then.
15:37:45 <davidwood> ack AZ
15:37:50 <tidoust> Ivan: right.
15:38:08 <tidoust> Antoine: Is it our role to do a kind of tutorial on something as generic as model theory?
15:38:13 <davidwood> Recalls that an introduction to MT will remain in the Semantics spec.
15:38:46 <tidoust> cygri: we discussed that yesterday. The answer is No, but the part is already there, and there's no real need to drop that away. Pat agreed to separate things away between a normative part and an informative part.
15:38:52 <tidoust> … It's part of the RDF Semantics document.
15:39:12 <tidoust> … Pat wants to separate those aspects cleanly but keep them in the same document.
15:39:43 <tidoust> Ivan: He also plans to separate the derivation rules that are currently in the Semantics docs and publish them somewhere else.
15:40:22 <tidoust> Antoine: I would rather have an informal section that describes the semantics of RDF than what we have in the spec right now.
15:40:30 <tidoust> Ivan: I think we should leave it to Pat.
15:40:34 <tidoust> Antoine: ok
15:41:00 <tidoust> cygri: As mentioned by Ivan, the other thing is to separate the rules part and publish them as a Note.
15:41:09 <tidoust> Ivan: we agreed on that yesterday
15:41:26 <tidoust> cygri: Pat said he agreed with that, and I'm very keen on that.
15:41:38 <tidoust> … I'm just saying the Note should be on the list.
15:41:58 <tidoust> davidwood: ok, but it's up to Pat. Already resolved.
15:42:19 <davidwood> Last possible Note: Semantics of datasets
15:42:46 <AZ> q+
15:42:48 <cygri> cygri: I think it's important to produce the Note that contains the informative entailment rules
15:42:52 <davidwood> ack AZ
15:42:55 <tidoust> davidwood: The last possible note is the semantics of datasets which is probably the most contentious one.
15:43:03 <tidoust> Antoine: I volunteer to write something.
15:43:07 <AZ> AZ: I volunteer to write a Note
15:43:10 <tidoust> davidwood: great
15:43:21 <tidoust> Ivan: I actually don't think it's contentious.
15:43:32 <AZ> AZ: a note on dataset semantics
15:44:09 <cygri> q+ to ask about Test Cases note
15:44:26 <tidoust> … [going through a bit of history]. We agreed both views have pros and cons. This Note would describe those two things and say "These are possible alternatives".
15:44:40 <tidoust> … That's what the Note is, so that shouldn't be controversial.
15:44:59 <tidoust> … Now, when it comes to semantics in that group, you never know ;)
15:45:19 <tidoust> AZ: I fully agree. The Note as a comparison of alternatives is not contentious.
15:45:28 <davidwood> PROPOSED: The RDF WG intends to produce a NOTE on the semantics of datasets.
15:45:34 <cygri> +1
15:45:36 <AZ> +1
15:45:37 <yvesr> +1
15:45:37 <ivan> +1
15:45:39 <davidwood> +1
15:46:12 <gavinc> +1 and reference it informationally from TriG ;)
15:46:19 <davidwood> RESOLVED: The RDF WG intends to produce a NOTE on the semantics of datasets.
15:46:31 <davidwood> Subtopic: Test Cases Note
15:46:34 <davidwood> ack cygri
15:46:34 <Zakim> cygri, you wanted to ask about Test Cases note
15:46:46 <Arnaud> belated +1
15:47:11 <tidoust> cygri: As part of the 2004 collection of spec, there's the Test spec. I'm not familiar with them. I think our charter says we may do something with it.
15:47:21 <tbaker> another belated +1 re: note on the semantics of datasets
15:47:35 <tidoust> … Given that we're going to have new test cases, there's the question of what happens to that.
15:47:42 <tidoust> davidwood: It's definitely on topic.
15:47:48 <ivan> q+
15:47:53 <tidoust> ack ivan
15:47:55 <davidwood> ack ivan
15:48:23 <tidoust> Ivan: I think this is something that we should not decide now. There will be a moment where we will have to discuss how we organize ourselves to pass CR.
15:48:36 <tidoust> … Whether it's a Note, a wiki, something else, we'll see when we get there.
15:48:51 <tidoust> … One more thing, that being said: I think I would not like to see Test Cases Recommendation.
15:49:30 <tidoust> cygri: I agree that making test cases a Recommendation is strange. It would make me feel good if it was clear that we have the intention of somehow doing something with the Test Cases document.
15:49:38 <tidoust> Ivan: which document?
15:49:42 <tidoust> cygri: The old one.
15:49:58 <Arnaud> http://www.w3.org/TR/rdf-testcases
15:50:06 <tidoust> … The Entailment test cases, there will be a few things that probably won't be covered in there.
15:50:27 <tidoust> Ivan: It is a Rec, that's why I disagree it should be a Rec.
15:50:55 <tidoust> … If we do not produce a Test cases document, which may happen, then we need to rescind the old version of the document. Something has to be done with it.
15:51:04 <davidwood> q?
15:51:06 <tidoust> Arnaud: It's odd to have it as a Rec.
15:51:22 <tidoust> EricP: It seems to me a waste of effort, but not a real concern.
15:51:31 <tidoust> Ivan: It carries some sort of value that it doesn't have.
15:51:51 <tidoust> Arnaud: It dilutes the value of a Recommendation.
15:52:04 <markus> What happens to N-Triples then (is defined in rdf-testcases)?
15:52:10 <tidoust> EricP: Right. It's kind of the same with Recommendation against reference implementation.
15:52:22 <tidoust> davidwood: I think that's it for this topic.
15:52:22 <cygri> markus, that becomes its own spec
15:52:45 <markus> good
15:52:57 <markus> thanks
15:53:00 <cygri> topic: Next F2F, Charter Extension
15:53:36 <tidoust> Guus: We may want to reflect on the meeting, and also wonder about planning one last F2F as we haven't be so good at planning F2Fs
15:53:44 <tidoust> davidwood: Where would that be?
15:54:02 <gavinc> WEST COAST
15:54:04 <davidwood> q?
15:54:05 <tidoust> Guus: First, some remarks on where people think we are?
15:54:41 <tidoust> Ivan: I think that we are in much better shape than initially.
15:55:01 <Guus> zaki, who is here?
15:55:20 <tidoust> … If everything goes well and we can go to Last Call or CR by end of January, I think that we're in a good shape, and we may get an extension up until end of 2013.
15:55:40 <tidoust> … If things are going well, I'm not really sure that we need another F2F.
15:55:40 <tbaker> zakim, who is here?
15:55:40 <Zakim> On the phone I see Rhone_4, markus, LeeF
15:55:41 <Zakim> On IRC I see SteveS, FabGandon, LeeF, trackbot, MacTed, mischat, AZ, ivan, Guus, tidoust, gkellogg, manu1, tbaker, markus, cygri, pchampin, Zakim, Arnaud, davidwood, manu, gavinc,
15:55:41 <Zakim> ... RRSAgent, yvesr, sandro, ericP
15:56:06 <tidoust> … During Last Call we may of course receive comments from the public willing something completely different, but hard to plan.
15:56:30 <tidoust> … The extensions, these days, tend to be shorter than before.
15:56:47 <davidwood> s/all of Ivan's comments//
15:57:21 <tidoust> … Our CEO will ask us to provide a timeline and proofs that we can meet these deadlines.
15:57:28 <tidoust> davidwood: 6 months? 1 year?
15:58:10 <tidoust> Ivan: Whatever we can justify and believe is needed. The reply could be "I give you 4 more months but don't try to come back for another extension"
15:58:20 <Arnaud> q+
15:58:28 <tidoust> … I think asking for an extension up until the end of 2013 should be enough.
15:58:42 <tidoust> … with an internal plan that we plan to finish everything by summer time.
15:59:00 <davidwood> q?
15:59:03 <tidoust> … Hofdstater's law needs to be accounted for.
15:59:24 <tidoust> … We need a long discussion on test cases.
15:59:45 <tidoust> … Finding implementations of RDF 1.1. Small additions need to be found out in the wild.
15:59:52 <ericP> q+
16:00:07 <davidwood> ack Arnaud
16:00:49 <davidwood> ack ericp
16:00:59 <tidoust> Arnaud: Clearly, you can recharter for different reasons. Changing the scope is a buggy. Asking for an extension for lack of time with a convincing arguments is easier and reasonable.
16:01:18 <tidoust> … I think we're in a good position from that point of view. A few months ago, it would have been a much harder sell.
16:01:35 <tidoust> davidwood: Exactly. That's why we need documents out.
16:01:46 <Guus> q+
16:02:05 <tidoust> EricP: The most substantial would be eradicating simple literals.
16:02:24 <tidoust> Ivan: Agreed.
16:02:39 <tidoust> EricP: The one I'm slightly concerned about is tension with SPARQL.
16:02:59 <tidoust> … I don't think that's a major issue. I believe SPARQL 1.1 changes the notion of datatype.
16:03:31 <LeeF> But yes, we tried to do that
16:04:10 <davidwood> ack Guus
16:04:13 <tidoust> cygri: [going through changes made about simple literals and other untyped values]
16:04:45 <tidoust> Guus: Sandro had a point that it is a bit weak to only produce implementations within the group.
16:04:58 <tidoust> EricP: "Always leave a critical party outside of the group"
16:05:08 <ivan> q+
16:06:02 <davidwood> ack ivan
16:06:56 <tidoust> Ivan: In the RDFa Working Group, we had at least 3 implementations who were done during the development of the spec, people that had never met before. That was perfectly fine.
16:07:28 <tidoust> … In that case, we had someone coming in at the last minute, but different implementations in different languages from different people is good enough.
16:07:38 <ericP> i think it's important that implementors not only not speak to each other, but have sworn antipathy stemming from childhood rivalries
16:07:46 <tidoust> Guus: diversity more important than what is inside or outside, ok.
16:08:56 <Zakim> -markus
16:11:50 <yvesr> http://en.wikipedia.org/wiki/Aldabra_giant_tortoise
16:12:26 <Steve Speicher> A group of turtles is called a bale.
16:13:09 <tidoust> davidwood: I had invited Doug to talk about WebPlatform.org as I was concerned that semantic Web would be left aside. However, I discovered last night that they use Semantic MediaWiki and plan to include all technologies.
16:13:54 <tidoust> … I wanted to see how to provide content to the project as probably no one is going to do that for us
16:14:09 <tidoust> Guus: Suggest we invite him to a next telecon
16:14:15 <davidwood> action: davidwood to invite Doug Schepers (shepazu on irc) to a future telecon to discuss SemWeb stack on webplatform.org.
16:14:15 <trackbot> Created ACTION-204 - Invite Doug Schepers (shepazu on irc) to a future telecon to discuss SemWeb stack on webplatform.org. [on David Wood - due 2012-11-06].
16:15:44 <tidoust> Ivan: [raising possible issue with lack of "donator" for pages contributions to WebPlatform.org and getting references to other places such as universities]. To be clarified with Doug.
16:16:12 <tidoust> i/davidwood: I had invited Doug/Topic: Webplatform.org and semantic Web technologies
16:18:05 <tidoust> [Fruitful meeting adjourned]
16:18:35 <pchampin> pchampin has left #rdf-wg
16:19:18 <tidoust> tidoust has joined #rdf-wg
# SPECIAL MARKER FOR CHATSYNC.  DO NOT EDIT THIS LINE OR BELOW.  SRCLINESUSED=00001453