Chatlog 2010-04-01

See CommonScribe Control Panel, original RRSAgent log and preview nicely formatted version.

13:29:08 <RRSAgent> RRSAgent has joined #rdfa
13:29:08 <RRSAgent> logging to http://www.w3.org/2010/04/01-rdfa-irc
13:43:59 <markbirbeck> markbirbeck has joined #rdfa
13:46:01 <manu> trackbot, start meeting
13:46:03 <trackbot> RRSAgent, make logs world
13:46:05 <trackbot> Zakim, this will be 7332
13:46:05 <Zakim> ok, trackbot; I see SW_RDFa()10:00AM scheduled to start in 14 minutes
13:46:06 <trackbot> Meeting: RDFa Working Group Teleconference
13:46:06 <trackbot> Date: 01 April 2010
13:46:23 <manu> Regrets: Ivan, Ben Adida
13:46:33 <manu> Chair: Manu
13:47:27 <manu> Present: Shane, Benjamin, Steven, Mark Birbeck, Markus, Manu, Knud, Rob, Toby, Jeff
13:47:42 <manu> Agenda: http://lists.w3.org/Archives/Public/public-rdfa-wg/2010Mar/0262.html
13:53:14 <manu> trackbot, action-16 comment Shane has prepared the RDFa Core 1.1 document for FPWD and only need to make edits from now on: http://www.w3.org/2010/02/rdfa/drafts/2010/ED-rdfa-core-20100330
13:53:14 <trackbot> Sorry, manu, I don't understand 'trackbot, action-16 comment Shane has prepared the RDFa Core 1.1 document for FPWD and only need to make edits from now on: http://www.w3.org/2010/02/rdfa/drafts/2010/ED-rdfa-core-20100330'. Please refer to http://www.w3.org/2005/06/tracker/irc for help
13:53:46 <manu> trackbot, comment action-16 Shane has prepared the RDFa Core 1.1 document for FPWD and only need to make edits from now on: http://www.w3.org/2010/02/rdfa/drafts/2010/ED-rdfa-core-20100330
13:53:46 <trackbot> ACTION-16 Prepare RDFa Core 1.1 document for FPWD notes added
13:54:42 <manu> trackbot, comment action-18 Shane has prepared the XHTML+RDFa 1.1 document for FPWD and only needs to make edits before publication: http://www.w3.org/2010/02/rdfa/drafts/2010/ED-xhtml-rdfa-20100330
13:54:42 <trackbot> ACTION-18 Prepare XHTML+RDFa 1.1 document for FPWD. notes added
13:55:35 <manu> trackbot, comment action-19 Benjamin has prepared the RDFa DOM API document and only needs to make edits before publication: http://www.w3.org/2010/02/rdfa/drafts/2010/ED-rdfa-dom-api-20100331
13:55:35 <trackbot> ACTION-19 Prepare RDFa API document for FPWD notes added
13:55:52 <manu> trackbot, close action-16
13:55:52 <trackbot> ACTION-16 Prepare RDFa Core 1.1 document for FPWD closed
13:55:55 <manu> trackbot, close action-18
13:55:55 <trackbot> ACTION-18 Prepare XHTML+RDFa 1.1 document for FPWD. closed
13:55:58 <manu> trackbot, close action-19
13:55:58 <trackbot> ACTION-19 Prepare RDFa API document for FPWD closed
13:58:20 <Zakim> SW_RDFa()10:00AM has now started
13:58:27 <Zakim> +Benjamin
13:58:57 <Zakim> +??P12
13:59:02 <manu> zakim, I am ??P12
13:59:03 <Zakim> +manu; got it
13:59:43 <RobW> RobW has joined #rdfa
13:59:44 <Zakim> +ShaneM
14:00:01 <ShaneM> ShaneM has joined #rdfa
14:00:53 <Zakim> + +04670602aaaa
14:01:00 <Steven> zakim, dial steven-617
14:01:00 <Zakim> ok, Steven; the call is being made
14:01:02 <Zakim> +Steven
14:01:06 <Zakim> +RobW
14:01:37 <Zakim> +[IPcaller]
14:01:38 <mgylling> Zakim, aaaa is me
14:01:38 <Zakim> +mgylling; got it
14:01:56 <jeffs> jeffs has joined #rdfa
14:02:06 <markbirbeck> zakim, code?
14:02:06 <Zakim> the conference code is 7332 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), markbirbeck
14:02:26 <tinkster> tinkster has joined #rdfa
14:02:31 <Zakim> + +0785583aabb
14:02:46 <Steven> zakim, mute me
14:02:46 <Zakim> Steven should now be muted
14:02:52 <manu> scribenick: tinkster
14:03:00 <Zakim> +jeffs
14:03:02 <tinkster> zakim, aabb is me
14:03:02 <Zakim> +tinkster; got it
14:04:00 <manu> zakim, code?
14:04:00 <Zakim> the conference code is 7332 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), manu
14:04:51 <Zakim> + +0208761aacc
14:05:02 <markbirbeck> zakim, I am aacc
14:05:02 <Zakim> +markbirbeck; got it
14:05:50 <Steven> Topic: RDFa Core 1.1 Review
14:06:09 <tinkster> Manu: skipping ahead to FPWD review. Excellent work done on these documents. We're in good shape to stick to our schedule.
14:06:35 <ShaneM> zakim, who is noisy?
14:06:38 <tinkster> ... looking to get Core, RDFa+XHTML and RDFa API ready.
14:06:46 <Zakim> ShaneM, listening for 10 seconds I heard sound from the following: manu (49%), mgylling (47%), markbirbeck (80%)
14:06:59 <tinkster> ... Need to make sure these are consistent with each other.
14:07:05 <markbirbeck> zakim, mute me
14:07:09 <Zakim> markbirbeck should now be muted
14:07:26 <tinkster> ... We don't all necessarily need to agree on every detail of the documents - just that the general direction is correct.
14:07:27 <Steven> zakim, mute mgylling temperarily
14:07:27 <Zakim> I don't understand 'mute mgylling temperarily', Steven
14:07:33 <Steven> zakim, mute mgylling temporarily
14:07:33 <Zakim> mgylling should now be muted
14:07:46 <manu> http://www.w3.org/2010/02/rdfa/drafts/
14:07:49 <Zakim> mgylling should now be unmuted again
14:08:00 <Steven> zakim, mute mgylling
14:08:00 <Zakim> mgylling should now be muted
14:09:35 <tinkster> ShaneM: RDFa core is reasonably solid. Ivan has raised a few editorial issues and technical issues that I intend to answer by email.
14:09:44 <manu> We're supposed to be discussing ISSUE-13 and ISSUE-14 today.
14:10:30 <tinkster> ... There are a few issues noted in the document itself. One of these is regarding datatypes. We have a lot of attributes - most can take CURIEs or URIs. @about and @resource are special, in that they need to take relative URIs.
14:10:34 <Knud> Knud has joined #rdfa
14:11:21 <Steven> <a about="prev" rel="next" resource="next">
14:11:38 <Steven> ack me
14:11:38 <tinkster> ... Relative URIs are indistinguishable from keywords in RDFa vocabs. So we need some way of making sure that these attributes don't take keywords (except perhaps via safe-curie syntax).
14:12:17 <Steven> zakim, who is on the phone?
14:12:17 <Zakim> On the phone I see Benjamin, manu, ShaneM, mgylling (muted), Steven, RobW, [IPcaller], tinkster, jeffs, markbirbeck (muted)
14:12:19 <tinkster> ... Steven's posted a good example. Another one is about="me" where me is a relative URI.
14:13:24 <tinkster> ... @rel, etc it's fine to have keywords, full URIs and CURIEs. For @about and @resource we need to be able to take relative URIs though.
14:13:52 <manu> q+
14:14:02 <manu> ack manu
14:14:10 <Steven> zakim, mute me
14:14:10 <Zakim> Steven should now be muted
14:14:17 <tinkster> Jeff: even for the attributes which expect absolute URIs, authors may try to jam relative URIs into them.
14:14:39 <Zakim> +knud
14:14:46 <Knud> zakim, mute  me
14:14:46 <Zakim> knud should now be muted
14:15:07 <tinkster> Manu: there are different ways to do this - a new type, or modify CURIE processing so that the CURIE processor knows what attribute is being used.
14:15:27 <markbirbeck> Only use-cae I can think of for relative paths being used as predicates, is when creating an OWL ontology that makes use of some of the predicates that it itself defines. (I.e., very rare.)
14:16:24 <tinkster> ShaneM: Another possibility is to require safe CURIEs all over the place.
14:17:27 <tinkster> ShaneM: CURIEs are/will be referenced by other specs, so we can't embed too much RDFa attribute-specific logic into CURIE expansion.
14:17:36 <markbirbeck> Not saying we need them. :)
14:18:00 <markbirbeck> Simply meant that the problem is less likely to occur with @rel/@rev.
14:18:01 <manu> q+
14:18:12 <markbirbeck> But the problem Shane has identified is very real for @about.
14:18:25 <tinkster> ... A term (i.e. keyword) must match NMTOKEN, so that disambiguates *sometimes*.
14:18:51 <tinkster> manu: Can we keep this as it is for now?
14:19:12 <tinkster> ShaneM: the document as-is doesn't work, so we need to resolve it somehow.
14:19:17 <jeffs> for the time being +1
14:19:17 <markbirbeck> zakim, unmute me
14:19:17 <Zakim> markbirbeck should no longer be muted
14:19:24 <tinkster> manu: Any objections to adding a new datatype for this?
14:20:07 <tinkster> markbirbeck: Is the crux of the problem that keywords/tokens are part of the CURIE spec?
14:20:29 <manu> q+
14:20:48 <tinkster> ... If keywords/tokens were processed before CURIEs would that work?
14:21:49 <ShaneM> ( term | URIor CURIE) +
14:21:59 <ShaneM> (term | URIorCURIE) +
14:22:10 <manu> ack manu
14:22:10 <tinkster> ShaneM: Is this the problem? Yes.
14:22:22 <manu> +1 for that approach (term | URIorCURIE)
14:22:35 <tinkster> ... The production (term | URIorCURIE) + works everywhere except @about/@resource.
14:23:09 <ShaneM> about="foo"
14:23:42 <ShaneM> q?
14:23:57 <tinkster> ... That "term" is ambiguous with relative URIs. If we've learnt a list of terms from @vocab, then we can disambiguate, but if we're using a default prefix, that doesn't work.
14:24:14 <tinkster> ... One possibility is to disallow terms in @about/@resource.
14:24:24 <jeffs> would demanding "./" & "../" & etc as how relative URIs must be written be useful here? 
14:25:00 <manu> q+ to discuss one attribute for creating prefix/token
14:25:53 <tinkster> markbirbeck: Then is seems we should keep terms and CURIE prefixes separate. When would you want a relative URI in @rel/@rev/@property? Perhaps when defining an OWL ontology.
14:26:29 <manu> ack manu
14:26:31 <Zakim> manu, you wanted to discuss one attribute for creating prefix/token
14:27:55 <tinkster> manu: There was one aspect of the token proposal which didn't get support was using them to define profiles. What people did seem to have more support for was combining prefixes and tokens into the same list of mappings. The token proposal is not completely dead.
14:28:08 <Benjamin> What about jeffs proposal? Sounds good, doesn't it?
14:29:15 <tinkster> ShaneM: Requiring authors to use relative URIs which don't look like NMTOKENs is kinda hacky.
14:29:28 <tinkster> ... Semi-resolved for now?
14:29:33 <manu> +1
14:30:00 <tinkster> ... Another thing: separating Core from RDFa+XHTML. What goes where?
14:30:47 <tinkster> ... Anything that's not in core creates more work for host language specs.
14:32:09 <tinkster> ... There are a whole bunch of attributes which could be defined by the host language or the core (e.g. @href). The approach for many attributes is for Core to say that the host language may define an attribute like @href, and just says how RDFa uses that attribute.
14:33:19 <tinkster> manu: this means that people creating host languages need a pretty deep understanding of the thought process behind Core's design. We need to provide clear guidance for how host languages can use RDFa.
14:33:42 <tinkster> ShaneM: I think that's everything I needed resolved for FPWD.
14:33:56 <manu> zakim, who is making noise?
14:34:06 <mgylling> zakim, mute me
14:34:06 <Zakim> mgylling was already muted, mgylling
14:34:08 <Zakim> manu, listening for 10 seconds I could not identify any sounds
14:34:09 <Steven> zakim, who is noisy?
14:34:20 <Zakim> Steven, listening for 10 seconds I heard sound from the following: ShaneM (2%)
14:34:36 <tinkster> Markbirbeck: We got a lot of input in RDFa 1.0 - people liked the intro to RDF, and the clear algorithm for parsers.
14:34:49 <manu> +1 to what mark just said
14:35:08 <jeffs> +1 
14:35:40 <tinkster> manu: Can someone do a full review of documents for FPWD?
14:35:48 <tinkster> ... other than the authors.
14:36:02 <tinkster> ... by Thursday.
14:36:18 <manu> ACTION: Mark to review RDFa Core 1.1
14:36:19 <trackbot> Created ACTION-20 - Review RDFa Core 1.1 [on Mark Birbeck - due 2010-04-08].
14:36:28 <manu> ACTION: Manu to review RDFa Core 1.1
14:36:28 <trackbot> Created ACTION-21 - Review RDFa Core 1.1 [on Manu Sporny - due 2010-04-08].
14:36:34 <tinkster> ... Now on to the RDFa DOM API.
14:37:07 <manu> Topic: RDFa DOM API FPWD Review
14:37:11 <Benjamin> http://www.w3.org/2010/02/rdfa/sources/rdfa-dom-api/
14:37:40 <ShaneM> zakim, who is noisy?
14:37:51 <Zakim> ShaneM, listening for 10 seconds I heard sound from the following: Benjamin (70%), markbirbeck (28%)
14:38:08 <markbirbeck> zakim, unmute me
14:38:08 <Zakim> markbirbeck was not muted, markbirbeck
14:38:26 <tinkster> Benjamin: key features are the triple filter and node filter.
14:38:49 <markbirbeck> zakim, mute me
14:38:49 <Zakim> markbirbeck should now be muted
14:39:02 <tinkster> ... I created a heirarchy containing resources, URIs, bnodes, literals, etc. I don't think it's necessary to further subclass literals.
14:40:02 <ShaneM> this specification is REALLY pretty!  nice job.
14:40:29 <ShaneM> zakim, mute me
14:40:29 <Zakim> ShaneM should now be muted
14:40:55 <manu> q+ to positively rave about filters
14:40:56 <tinkster> ... there's an RDFa triple iterator which can be given a filter.
14:41:44 <tinkster> ... there are a number of predefined triple filters.
14:42:13 <markbirbeck> q+
14:42:39 <markbirbeck> exactly. :)
14:42:43 <tinkster> ... If we subclass literals, where would we stop?
14:42:47 <markbirbeck> zakim, unmute me
14:42:47 <Zakim> markbirbeck should no longer be muted
14:43:50 <manu> ack me
14:43:50 <Zakim> manu, you wanted to positively rave about filters
14:43:51 <ShaneM> have you considered using something simple like CSS selectors for filtering?
14:43:56 <tinkster> Manu: this is a powerful mechanism that should arm us against people demanding full SPARQL in the API.
14:44:30 <tinkster> markbirbeck: not really a big fan of this. I was supposed to be helping with this draft, but haven't had time.
14:45:00 <jeffs> +1 to anything we can do to make life easier for ECMAScript/JavaScript authors
14:45:11 <tinkster> ... We should use less RDF-specific terminology. We should be able to return JSON-ish objects.
14:45:49 <manu> q+ to comment about JSON-ish objects
14:45:55 <manu> ack markbirbeck
14:46:12 <ShaneM> q+ to disagree with Mark a little
14:46:57 <tinkster> Benjamin: Maybe we could flatten it a bit using associative arrays?
14:46:58 <markbirbeck> http://code.google.com/p/backplanejs/wiki/Rdfj
14:48:18 <tinkster> markbirbeck: the linked data API people are using something along the lines of Rdfj. We ought to be using something similar.
14:48:59 <tinkster> ... If it was the same, then code could switch between linked data API and RDFa API very easily.
14:49:37 <manu> ack me
14:49:40 <Zakim> manu, you wanted to comment about JSON-ish objects
14:49:41 <ShaneM> +1 to not being tied too tightly too javascript.  WebIDL is the right way to specify interfaces.  We need JS but we need to support Ruby / Perl / whatever
14:50:45 <manu> { "subject": "http://example.org" }
14:50:53 <tinkster> manu: You're not saying that this current proposal *can't* be serialised to JSON, just that it doesn't serialise nicely.
14:51:25 <manu> { "subject": ["http://example.org/predicate" "object"]}
14:51:28 <tinkster> markbirbeck: Don't use { predicate: x; object: y; }, but use { x: y }.
14:51:48 <manu> { "http://example.org/predicate": "object" }
14:53:01 <manu> ack shanem
14:53:02 <Zakim> ShaneM, you wanted to disagree with Mark a little
14:53:04 <tinkster> markbirbeck: we should be aiming this API mostly at Javascript coders.
14:53:06 <ShaneM> zakim, unmute me
14:53:06 <Zakim> ShaneM was not muted, ShaneM
14:53:13 <Steven> zakim, who is noisy?
14:53:24 <Zakim> Steven, listening for 10 seconds I heard sound from the following: manu (24%), ShaneM (74%), markbirbeck (53%)
14:54:10 <Benjamin> +q to add toJSON() method to RDFTriple interface
14:54:19 <tinkster> ShaneM: I disagree a bit. It's not that nice JS structures are evil. And putting "RDF" in the name of every function and class name doesn't seem necessary.
14:54:37 <manu> q+ to disagree with Shane
14:54:46 <markbirbeck> q+
14:54:48 <manu> ack Benjamin
14:54:48 <Zakim> Benjamin, you wanted to add toJSON() method to RDFTriple interface
14:54:50 <tinkster> ... But this API is not just for the browser.
14:55:16 <tinkster> Benjamin: what about adding a toJSON method to the RDFTriple interface?
14:55:23 <ShaneM> +1 to using toJSON - that's pretty standard
14:55:31 <ShaneM> zakim, mute me
14:55:31 <Zakim> ShaneM should now be muted
14:55:47 <jeffs> +1 to using toJSON for FWD
14:56:26 <Steven> zakim, mute mark temporarily
14:56:26 <Zakim> markbirbeck should now be muted
14:56:29 <ShaneM> I didn't want to imply we shouldnt support it.  I just think the number of authors who need this API is vanishingly small.
14:56:41 <Zakim> markbirbeck should now be unmuted again
14:56:49 <manu> ack markbirbeck
14:56:55 <manu> ack manu
14:56:57 <Zakim> manu, you wanted to disagree with Shane
14:57:46 <tinkster> manu: the browser is certainly the target. Browser vendors were very excited by the Microdata API, we want the same excitement from them over RDFa.
14:58:16 <tinkster> markbirbeck: other programming languages don't need the API as much - they can use whatever APIs they like.
14:58:52 <manu> q+ to end the telecon
14:59:11 <Zakim> -jeffs
14:59:12 <tinkster> ... my browser allows data to be extracted from RDFa and then modifies the page based on Fresnel views of the data,
14:59:39 <manu> ack manu
14:59:39 <Zakim> manu, you wanted to end the telecon
15:00:52 <tinkster> manu: markbirbeck, would you be able to write up your ideas on the API instead of reviewing the Core document?
15:00:55 <tinkster> markbirbeck: yes.
15:01:03 <tinkster> manu: I'll change the action then.
15:01:10 <ShaneM> I will get an update for the RDFa Core out today
15:01:11 <Steven> Possible regrets for next week
15:01:15 <Zakim> -mgylling
15:01:16 <Zakim> -RobW
15:01:16 <Zakim> -markbirbeck
15:01:18 <Zakim> -Steven
15:01:19 <tinkster> ... We'll need to focus on edits, but we're in good shape.
15:01:20 <Zakim> -ShaneM
15:01:21 <Zakim> -[IPcaller]
15:01:21 <Zakim> -Benjamin
15:01:30 <Zakim> -knud
15:01:36 <Zakim> -tinkster
15:02:07 <manu> zakim, who is on the call?
15:02:13 <Zakim> On the phone I see manu
15:02:39 <Benjamin> You mihght have a look at one existing RDF/JSON format: http://www.w3.org/TR/rdf-sparql-json-res/
# SPECIAL MARKER FOR CHATSYNC.  DO NOT EDIT THIS LINE OR BELOW.  SRCLINESUSED=00000265