Warning:
This wiki has been archived and is now read-only.
Chatlog 2010-04-01
From RDFa Working Group Wiki
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