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
13:46:33 <manu> Chair: Manu
13:47:27 <manu> Present: Shane, Benjamin, Steven, Mark, Markus, Manu
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:44 <tinkster> OK, I can scribe.
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:03:21 <markbirbeck> UK number not accepting calls! What does that mean?
14:03:36 <tinkster> markbirbeck: I called the UK number.
14:03:53 <jeffs>  UK: +44.117.370.6152  ??
14:03:54 <Steven> try again Mark
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:25 <tinkster> s/markbirbeck:/markbirbeck,/
14:04:51 <Zakim> + +0208761aacc
14:05:02 <markbirbeck> zakim, I am aacc
14:05:02 <Zakim> +markbirbeck; got it
14:05:10 <manu> http://lists.w3.org/Archives/Public/public-rdfa-wg/2010Mar/0262.html
14:05:50 <Steven> Topic: FPWD 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:01 <markbirbeck> traffic :(
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:07:50 <markbirbeck> ah...not crackling now
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:05 <manu> Present+ Knud
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:11:53 <Knud> (sorry, the conference is full)
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> Steven?: 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:15:31 <jeffs> s/Steven?:/jeffs
14:16:24 <tinkster> jeffs?: Another possibility is to require safe CURIEs all over the place.
14:16:35 <manu> s/jeffs?/Shane/
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:22:46 <tinkster> s/The/... The/
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 though 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> Steven?: We got a lot of input in RDFa 1.0 - people liked the intro to RDF, and the clear algorithm for parsers.
14:34:46 <Steven> s/Steven?/Markbirbeck/
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:44:41 <manu> s/manu?/Manu/
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/
15:03:58 <markbirbeck> @Benjamin: :) Been through all of those.
15:04:12 <markbirbeck> See discussion here: http://webbackplane.com/mark-birbeck/blog/2009/04/20/rdfj-semantic-objects-in-json
15:04:35 <markbirbeck> (Where I describe why I don't think that SPARQL/JSON format is any good.)
15:05:16 <Benjamin> I think so too
15:05:47 <markbirbeck> I just remembered the other point I wanted to make...
15:05:57 <Benjamin> It's possible in WebIDL to define one API a bit different for cterain target languages. I think we should do that.
15:06:00 <markbirbeck> Toby is exactly right that we should be dealing in built-in datatypes.
15:06:20 <ShaneM> when there are such datatypes
15:06:23 <markbirbeck> So if a property is ^^xsd:dateTime, then we should return a Date().
15:06:32 <Zakim> disconnecting the lone participant, manu, in SW_RDFa()10:00AM
15:06:34 <ShaneM> in Javascript
15:06:38 <Zakim> SW_RDFa()10:00AM has ended
15:06:42 <Zakim> Attendees were Benjamin, manu, ShaneM, +04670602aaaa, Steven, RobW, [IPcaller], mgylling, +0785583aabb, jeffs, tinkster, +0208761aacc, markbirbeck, knud
15:06:46 <markbirbeck> There aren't that many types, so we might as well support them.
15:06:56 <Benjamin> yes this makes live easier
15:07:00 <markbirbeck> (Boolean, string, date, number, etc.)
15:07:14 <manu> We should be careful to not make it unimplementable in other DOMs, though - for example... ODF's DOM or SVG's DOM.
15:07:15 <Steven> rrsagent, make minutes
15:07:15 <RRSAgent> I have made the request to generate http://www.w3.org/2010/04/01-rdfa-minutes.html Steven
15:07:17 <ShaneM> native implementations of the webidl should support the native datatypes for the abstract XSD type
15:07:25 <manu> neither of those have a Date() datatype, IIRC.
15:07:26 <ShaneM> so in Perl it would be DateTime
15:07:29 <markbirbeck> Oh, and one other thing. If you want to keep it language independent in the way that Shane says, I guess you could just return 'object'.
15:08:03 <markbirbeck> The IDL only defines the methods (and events, we shouldn't forget).
15:08:07 <ShaneM> manu, +1
15:08:19 <markbirbeck> But the returned items are just 'objects'.
15:08:23 <ShaneM> IDL can also define attributes
15:08:27 <markbirbeck> Shane/Manu, yes, but it doesn't matter.
15:09:20 <manu> what doesn't matter?
15:09:25 <markbirbeck> The point is to return objects that are of the correct format for the language being used.
15:09:29 <markbirbeck> The datatype stuff.
15:09:39 <ShaneM> agreed
15:09:51 <markbirbeck> If the functions return 'objects', then that's it.
15:09:52 <manu> right... I just want to make sure we're not talking about putting Javascript-specific stuff as normative content.
15:10:23 <manu> I think everyone agrees... I just want to be certain that we don't accidentally tie the DOM API to Javascript.
15:10:25 <markbirbeck> I was... :) But I can see what you and Shane are getting at, and realise that it can also be accommodated.
15:10:26 <ShaneM> For example, an appendix that showed the JS implementation strategy informatively would be appropriate
15:10:36 <markbirbeck> Yes, agreed.
15:11:02 <markbirbeck> It's a change to what I was thinking of, but improves it.
15:11:15 <markbirbeck> The API can be language-agnostic.
15:11:20 <manu> exactly
15:11:36 <Benjamin> +1 with ShaneM s proposal
15:11:37 <markbirbeck> And as Shane says, the only language-specific stuff is the definition of the returned objects.
15:11:40 <manu> but we communicate that it's expected that the native language datatypes are used when possible.
15:12:31 <ShaneM> definitely
15:12:32 <markbirbeck> In my blog post I talk about using the query engine as a "dynamic JSON object creation mechanism".
15:12:39 <markbirbeck> But that can apply to other languages.
15:13:01 <ShaneM> also.... I think it would be super cool of there were a way to use sort of CSS selector style syntax for the filters.... if that makes sense at all
15:13:07 <markbirbeck> The key thing is that you are taking 10 triples that have the same subject and creating a language-specific object from them.
15:13:42 <markbirbeck> @ShaneM: Mmm...
15:13:45 <ShaneM> or at least that is one use case.  another is 'give me every triple on the page'.  then you have an array of objects?
15:13:55 <markbirbeck> I shall think about that.
15:14:11 <markbirbeck> Exactly...an array of objects. :)
15:14:43 <ShaneM> I have this fantasy of var foo = RDFfilter('.foaf') or something
15:14:45 <markbirbeck> What could be easier.
15:14:54 <markbirbeck> You need to get out more.
15:15:02 <ShaneM> roger that
15:15:06 <markbirbeck> Does that replace your Chrissie Hynde fantasy?
15:15:12 <ShaneM> hell no
15:15:19 <ShaneM> chick is still smikin
15:15:21 <ShaneM> smokin
15:15:40 <markbirbeck> I have this idea for 'query by template', but haven't tried it yet.
15:15:59 <ShaneM> okay - I am off to fix rdfa core
15:16:08 <markbirbeck> Create a JSON object, such as { "blah": "foo" }
15:16:24 <markbirbeck> and you get back all objects with a predicate of "blah" and value of "foo".
15:16:34 <Benjamin> The bets thing is thta you guys write pieces of sample javascript for your ideas and send it to the mailing list.
15:16:54 <ShaneM> Benjamin: fair enough
15:17:39 <Benjamin> fine :) I wish you happy Easter!
15:18:26 <Benjamin> bye
15:19:50 <ShaneM> I think XHTML+RDFa is fine.  that's why I didn't discuss it btw.
15:21:51 <ShaneM> question: if I have a 'term' can that 'term' be in a safe curie?  e.g. [myTerm] ?  I don't think it can if terms are a separate datatype.... well, it can, but we need to define the data type as '[' + NMTOKEN + ']' | NMTOKEN
15:23:48 <manu> so, I'm fine with [myTerm] not being recognized as a SafeCURIE
15:23:59 <manu> then again, that might confuse some people...
15:24:09 <manu> that understand SafeCURIEs...
15:24:25 <manu> and I think that population is less than 1%
15:24:35 <manu> down with SafeCURIEs!
15:26:08 <ShaneM> thats funny.  I prefer safecuries because it is clear I am doign something special.  n about and resource anyway
15:27:07 <manu> which is probably why I like Python so much... no braces.
15:27:57 <ShaneM> wow.  pytyhon is so evil
15:28:04 <manu> oh oh
15:28:15 <ShaneM> any language where the whitespace dictates my nesting level must die
15:28:32 <manu> sacrilege
15:29:00 <ShaneM> ANYWAY.... back to work
15:48:33 <ShaneM> I think that based upon our discussion earlier the datatype CURIE always includes SafeCURIE in 1.1. 
16:07:33 <Steven> Manu, I think that 2 potrs are being added to the call as we talk
16:07:52 <Steven> ports
16:08:01 <ShaneM> nice work steven
16:11:59 <ShaneM> manu, can I get a list of working group members for the acks section?
16:12:09 <ShaneM> or is it on the web?
16:12:52 <ShaneM> never mind I foudn it on the web
16:21:15 <markbirbeck> Agrees that not keen on Python.
16:21:19 <markbirbeck> :)
16:40:31 <ShaneM> jython is worse.  weird syntax AND slow.  
17:29:19 <Zakim> Zakim has left #rdfa
17:34:11 <ShaneM> ShaneM has left #rdfa
17:36:46 <manu> Sorry, got pulled into a meeting - thanks for adding two ports, Steven!
17:37:25 <manu> re: Python hating - markbirbeck... and here I thought you were a swell guy. :)
17:56:03 <manu> rrsagent, bye
17:56:03 <RRSAgent> I see 2 open action items saved in http://www.w3.org/2010/04/01-rdfa-actions.rdf :
17:56:03 <RRSAgent> ACTION: Mark to review RDFa Core 1.1 [1]
17:56:03 <RRSAgent>   recorded in http://www.w3.org/2010/04/01-rdfa-irc#T14-36-18
17:56:03 <RRSAgent> ACTION: Manu to review RDFa Core 1.1 [2]
17:56:03 <RRSAgent>   recorded in http://www.w3.org/2010/04/01-rdfa-irc#T14-36-28
17:56:06 <manu> trackbot, bye
17:56:06 <trackbot> trackbot has left #rdfa