Chatlog 2011-07-14

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

13:56:14 <RRSAgent> RRSAgent has joined #rdfa
13:56:14 <RRSAgent> logging to http://www.w3.org/2011/07/14-rdfa-irc
13:56:16 <trackbot> RRSAgent, make logs world
13:56:16 <Zakim> Zakim has joined #rdfa
13:56:18 <trackbot> Zakim, this will be 7332
13:56:18 <Zakim> ok, trackbot; I see SW_RDFa()10:00AM scheduled to start in 4 minutes
13:56:19 <trackbot> Meeting: RDF Web Applications Working Group Teleconference
13:56:19 <trackbot> Date: 14 July 2011
13:57:32 <manu> Chair: Manu
13:57:59 <manu> Agenda: http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Jul/0028.html
13:57:59 <manu> Guest: Henri (bergie) Bergius
13:57:59 <manu> Guest: Stéphane (scor) Corlosquet
13:57:59 <manu> Guest: Niklas (lindstream) Lindström
13:58:02 <Zakim> SW_RDFa()10:00AM has now started
13:58:09 <Zakim> +??P0
13:58:19 <gkellogg> zakim, P0 is gkellogg
13:58:19 <Zakim> sorry, gkellogg, I do not recognize a party named 'P0'
13:58:38 <gkellogg> zakim, ??P0 is gkellogg
13:58:38 <Zakim> +gkellogg; got it
13:58:58 <Zakim> +??P1
13:59:05 <Zakim> +??P5
13:59:10 <manu> zakim, I am ??P5
13:59:10 <Zakim> +manu; got it
13:59:17 <Zakim> +bergie
14:00:03 <Zakim> +Knud
14:00:09 <Zakim> +OpenLink_Software
14:00:09 <Zakim> +scor
14:00:14 <MacTed> Zakim, OpenLink_Software is temporarily me
14:00:15 <Zakim> +MacTed; got it
14:00:34 <manu> zakim, who is on the call?
14:00:34 <Zakim> On the phone I see gkellogg, ??P1, manu, bergie, Knud, MacTed, scor
14:00:41 <tomayac_> tomayac_ has joined #rdfa
14:00:54 <manu> zakim, who is making noise?
14:00:55 <lindstream> zakim, ??P1 is me
14:00:55 <Zakim> +lindstream; got it
14:01:05 <Zakim> manu, listening for 10 seconds I heard sound from the following: gkellogg (16%), ??P1 (36%), Knud (49%), manu (100%), MacTed (24%)
14:01:11 <MacTed> Zakim, mute me
14:01:11 <Zakim> MacTed should now be muted
14:01:21 <Knud> zakim, mute me
14:01:21 <Zakim> Knud should now be muted
14:01:41 <bergie> Zakim, mute me
14:01:41 <Zakim> bergie should now be muted
14:01:58 <Steven> zakim, code?
14:01:58 <Zakim> the conference code is 7332 (tel:+1.617.761.6200 tel:+33.4.26.46.79.03 tel:+44.203.318.0479), Steven
14:02:46 <manu> Any updates/changes to the agenda?
14:02:46 <manu> Topic: Announcements and News
14:02:55 <Knud> I have a quick question: is there any RDFa parser for iOS?
14:03:12 <Zakim> +Steven
14:03:13 <Knud> or something along those lines?
14:03:46 <Knud> I was thinking of writing one, then
14:04:37 <manu> You could use: https://github.com/msporny/librdfa
14:04:37 <Knud> Yeah, I know librdfa - but if I want to implement the RDFa API on top of it, I'd rather have my own RDFa parser implementation
14:04:52 <Knud> I'm not promising anything. :)
14:04:58 <MacTed> I haven't tested ... but ODE may already do, and should be portable from base Mac OS X if not...
14:04:58 <Knud> just a toy project for me... I'll check out ODE
14:05:38 <Steven> Scribe: Steven
14:06:06 <manu> http://80legs.com/
14:06:30 <MacTed> Knud - just tested...  iOS Safari won't download/install extension, so not yet.  I'll make sure that's put on our roadmap.
14:06:55 <Steven> Manu: We need better data to analyze RDFa usage in the wild. Google, Yahoo and the other search companies, while helpful, are difficult to get raw data from. 80legs.com could help us crawl the entire web and get raw usage data to analyze. We would, of course, make all of the raw data public.
14:07:32 <Steven> ... we are thinking of working with 80legs to get data about RDFa, Microdata, and Microformats usage
14:07:59 <Steven> ... so that we can defend some of our positions, or otherwise find out that we have been wrong about some of our positions and fix the spec if necessary.
14:08:17 <Steven> ... and as a basic input for the RDFa/Microdata task force so that they're making decisions based on real-world data and not what we /think/ Web developers are doing out in the wild.
14:09:10 <Steven> Manu: I've been talking to people that work at browser companies, trying to get feedback
14:09:27 <Steven> ... about what changes they would like to see in RDFa to make them happy
14:09:31 <Steven> ... they have been very willing to talk, which is a good sign
14:09:54 <Steven> ... so some recent bugs filed against RDFa are a result of those discussions
14:10:57 <Steven> Niklas: A lot don't know what they are going to do with the RDFa data yet, which leads to them not understanding why we have it in the first place.
14:11:12 <Steven> ... from my point of view, it's about publishing more data than we've got today
14:11:37 <Steven> Niklas: And they don't know why we want the data there
14:11:47 <Steven> Manu: Robert Nyman?
14:11:55 <Steven> Niklas: Yes, Mozilla and Firefox guy
14:12:05 <Steven> Manu: Should we talk with them?
14:12:27 <Steven> Niklas: I haven't spent a lot of time doing that yet, but I'm thinking of doing more
14:12:57 <Steven> Manu: They say that they don't need it, but at the same time they say they like Microdata - so there is some cognitive dissonance here. 
14:13:26 <Steven> Niklas: They don't grok why we need the graphs of RDFa
14:13:48 <Steven> Manu: They don't want to negatively impact browser performance for the benefit of, what they perceive to be, a small audience. We hope the audience will grow over time, but it would be a shame for the browsers to integrate some heavy stuff into the browser and then find out that RDFa is not successful. Cruft lasts a very long time in the browser world.
14:15:00 <manu> Topic: ISSUE-96: Document not ready
14:15:07 <manu> http://www.w3.org/2010/02/rdfa/track/issues/96
14:17:05 <Steven> Manu: Which direction should we go with this?
14:17:08 <gkellogg> q+
14:17:08 <bergie> Zakim, unmute me
14:17:09 <Zakim> bergie should no longer be muted
14:17:12 <bergie> +q
14:17:33 <Steven> Greg: Doing a callback is my preference
14:17:40 <manu> ack gkellogg
14:18:07 <lindstream> q+
14:18:20 <manu> ack bergie
14:18:21 <Steven> Henri: CLient-side js people are familiar with event model, so I would bind to a ready event of some kind, or a similar event; don't bother with ready signals for a particular resource
14:18:22 <bergie> Zakim, mute me
14:18:22 <Zakim> bergie should now be muted
14:18:29 <Steven> sNiklas: I prefer callback
14:18:33 <Steven> s/sN/
14:18:39 <Steven> s/iklas/Niklas/
14:19:12 <Steven> Manu: An RDFa doc can have miltiple profiles. Processing can be done ignoring a subtree for a profile that can't be fetched
14:19:20 <Steven> ... just one event is difficult
14:19:33 <Steven> s/CL/Cl/
14:19:50 <Steven> ... so how do we address one of 5 profiles not loading?
14:19:53 <lindstream> q+
14:19:56 <Steven> s/ing/ing?/
14:19:59 <manu> ack lindstream
14:21:09 <Steven> Niklas: We don't have to resolve the profiles immediately, we could delay resolution until we need to turn it into RDFa.
14:21:26 <Steven> Manu: So, what you're saying is that the only time the profile needs to be loaded is when we are trying to do something RDF-like with the data? We could just use the terms displayed in the page?
14:21:34 <Steven> s/data/data?/
14:21:34 <gkellogg> q+
14:21:41 <manu> ack gkellogg
14:21:48 <Steven> Greg: That comes down to a usage model
14:22:07 <Steven> ... if the app knows what it needs. But doesn't get round needing to know when you can process
14:22:39 <Steven> ... we can't get away from needing that feedback. We need to dereference the profiles at some point.
14:22:59 <Steven> Manu: So we could have a callback that gives a map of the profiles and whether they have loaded
14:23:08 <Steven> Gregg: That would do it
14:23:33 <Steven> ... it's easier to have a second callback saying when all profiles have been loaded
14:23:35 <lindstream> q+
14:23:48 <manu> ack lindstream
14:23:54 <Steven> ... knowing about failures could be useful
14:24:04 <manu> q+
14:24:51 <Steven> Manu: We could do the same with an event, it's about the parameter passed with event or callback
14:25:00 <tomayac> is it a good idea to decouple profile(s) loaded and document loaded events? wouldn't fine-grained error reporting be better? => e.g. profile x timeout
14:25:07 <Steven> ... but one event/callback for each profile would require the developer to keep track of which ones loaded successfully and which ones didn't.
14:25:15 <Steven> ... by the app writer
14:25:23 <Steven> q+
14:25:28 <Steven> ack m
14:25:47 <manu> ack manu
14:26:07 <manu> Steven: Sounds like you need an event to say they've all been done, and one error event if one of them fails.
14:26:15 <Steven> ack me
14:26:21 <tomayac> so you'd have an event dataloaded or whatever with fine-grained success/failre states
14:26:49 <tomayac> s/failre/failure/
14:27:25 <tomayac> then +1 for doing it the XForms way, Steven ;-)
14:27:28 <lindstream> q+
14:27:31 <Steven> Manu: Are we talking about the processor writer using these events in JavaScript, or the webdeveloper knowing that the RDFa data is ready? I think we want the latter.
14:27:37 <Steven> Niklas: The latter
14:27:38 <manu> ack lindstream
14:28:01 <Steven> ... I agree with an evet/callback saying everything is ready
14:28:10 <Steven> ... progress reoprting is not so important
14:28:17 <Steven> s/reop/repo/
14:28:41 <Steven> Manu: So maybe an event and a callback, event is RDFa-data-ready, the callback is an error callback
14:29:10 <Steven> ... does that cover it?
14:29:25 <Steven> [voice]: I think so
14:29:39 <bergie> Sounds good
14:30:10 <bergie> Zakim, unmute me
14:30:10 <Zakim> bergie should no longer be muted
14:30:26 <manu> s/[voice]/Niklas/
14:30:27 <Steven> Henri: Sounds good. Keep things simple.
14:30:43 <tomayac> document.ondataready(event)
14:31:08 <bergie> Zakim, mute me
14:31:08 <Zakim> bergie should now be muted
14:31:14 <tomayac> similar to document.onload
14:31:16 <Steven> ... try running VIE editing environment on top of RDFa API, would be a good test case
14:31:33 <lindstream> q+
14:31:33 <Steven> Manu: Some like the microdata API because there is only one event
14:31:38 <Steven> s/event/call/
14:31:40 <bergie> link to VIE for those who haven't seen it: https://github.com/bergie/VIE#readme
14:33:10 <Steven> Niklas: One remark, using profiles we don't need to use URIs, but the mapping is awkward for developers
14:34:51 <Steven> Manu: So maybe we need a "getraw" for the attribute as used in the page
14:35:01 <Steven> zakim, agenda?
14:35:01 <Zakim> I see 3 items remaining on the agenda:
14:35:02 <Zakim> 1. ISSUE-96: Document not ready [from Steven]
14:35:03 <Zakim> 2. Graph.toArray() list order [from Steven]
14:35:05 <Zakim> 3. Live NodeLists and Graphs [from Steven]
14:35:36 <Steven> scor: So @profile is a new feature; why not have the default profile in the spec, and no other profile at all.
14:35:52 <Steven> ... what is the real benefit of profiles?
14:36:16 <Steven> Manu: The one big use case is microformats
14:36:25 <gkellogg> q+
14:36:33 <Steven> ... the other is for people who don't like CURIES
14:36:58 <manu> ack lindstream
14:36:59 <Steven> scor: Well, they can define the vocab inline
14:37:02 <manu> ack gkellogg
14:37:43 <Steven> Greg: Microformats work with a profile with an NCNAME
14:37:57 <Steven> ... maybe we can provide those as standard
14:38:03 <Steven> q+
14:38:30 <manu> ack Steven
14:38:43 <manu> Steven: The reason profiles are there are to provide an extension mechanism.
14:39:00 <manu> q+
14:39:09 <Steven> ack m
14:39:37 <manu> ack manu
14:39:41 <Steven> Manu: Good discussion, revisiting some of these decisions. Stephane made a good point, that most of the profile use cases could be addressed with @vocab
14:40:16 <Steven> ... but vocabulary mixing wouldn't work
14:40:32 <Steven> ... but you could just use prefixing
14:40:44 <lindstream> q+
14:41:28 <Steven> Niklas: I see the value in that. I thought of profiles as vocabs with mixing at a direct level. That use case might be small, and then you could use prefixes
14:41:49 <manu> ack lindstream
14:42:17 <Steven> Manu: So you suppotr removing @profile?
14:42:22 <Steven> s/potr/port/
14:42:38 <Steven> Niklas: Not sure. I like @profile
14:43:43 <Steven> Manu: People were wondering why we were using URLs to identify everything.
14:44:09 <Steven> ... they suggested using a default profile, wioth registering prefixes at the profile
14:44:21 <Steven> q+
14:44:28 <Steven> s/wio/wi
14:44:36 <Steven> ... a registery
14:44:38 <bergie> q+
14:44:44 <lindstream> q+
14:44:46 <Steven> s/registery/registry
14:44:57 <manu> ack Steven
14:45:40 <bergie> Zakim, unmute me
14:45:40 <Zakim> bergie should no longer be muted
14:45:42 <manu> ack bergie
14:45:48 <Steven> Steven: The idea is to give freedom, not asking people to register. It's like asking people to register class names
14:45:53 <Steven> Niklas: I second that
14:46:13 <Steven> ... people can use the ontology they feel like
14:46:29 <gkellogg> q+
14:46:36 <Knud> could we have both: a registry _and_ a local prefixing mechanism?
14:46:40 <Steven> ... I'm strongly against registering
14:46:44 <bergie> Zakim, mute me
14:46:44 <Zakim> bergie should now be muted
14:46:48 <manu> ack lindstream
14:46:57 <Steven> s/Niklas/Henri/
14:47:04 <Steven> Niklas: I support Steven and Henri on this
14:47:36 <MacTed> centralized registries are trouble
14:47:36 <Knud> a registry could help 80% of the big name use cases, the local prefixing could help the rest?
14:47:41 <manu> ack gkellogg
14:47:44 <MacTed> q+
14:47:54 <MacTed> Zakim, unmute me
14:47:54 <Zakim> MacTed should no longer be muted
14:47:57 <Steven> Greg: @profile is a complication in an implementation
14:48:06 <Steven> ... we should think about removing it
14:48:20 <Steven> ... @prefix does address the use cases
14:48:30 <manu> ack MacTed
14:48:57 <Steven> Ted: Centralised registries are always problematic. Doomed
14:49:09 <Steven> ... RDFa is succesful because it is not centralised
14:49:15 <Steven> s/sf/ssf/
14:49:29 <Steven> q+
14:49:56 <Steven> ... eventually we should think about getting rid of prefixing
14:50:07 <gkellogg> q+
14:50:10 <Steven> Manu: Is that an argument for @profile
14:50:13 <Steven> Ted: Not sure
14:50:35 <Steven> Ted: Ultimate solution is doc to be fully expanded at delivery
14:50:50 <Steven> Steven: I disagree with that point of view
14:51:22 <manu> ack Steven
14:52:09 <manu> q+
14:52:26 <Steven> Ted: Shorthand gets in the way of knowing what the fully expanded form is
14:52:48 <Steven> Steven: I think that is anti-author
14:53:05 <Steven> ... writing the full form URIs would be awful
14:53:08 <manu> ack gkellogg
14:53:34 <Steven> Greg: Some of the copy-paste issues could be addressed at the top-level
14:53:35 <Steven> q+
14:53:37 <Steven> q-
14:53:42 <Steven> q+ on copy paste
14:54:06 <Steven> Greg: There is something to be said for things that are easy to read
14:54:12 <Steven> ... full URIs are a nightmare
14:54:15 <lindstream> q+
14:54:20 <bergie> bergie has joined #rdfa
14:54:26 <Steven> ... CURIEs are elegant in comparison
14:55:13 <Steven> Manu: I don't think Ted and Steven are saying different things; I think the transformation can happen at a different layer. Perhaps the author uses CURIEs to author, but the authoring software or the web server expands all CURIEs to full IRIs before they go out.
14:55:33 <manu> ack manu
14:55:50 <Steven> Ted: Where it happens is up to a lot of things
14:56:00 <Steven> ... you may not have control over the webserver
14:56:36 <Steven> ... there are multiple stages where these things matter
14:56:56 <Steven> ... who pays? The author, the end user, the programmer?
14:57:15 <Steven> ... The ugliness should be hidden from the enduser
14:57:24 <manu> ack Steven
14:57:25 <Zakim> Steven, you wanted to comment on copy paste
14:58:02 <manu> Steven: I've always thought that the copy-paste problem was a bit of a red herring - I've never had problems with it myself - people that copy/paste tend to work in the same areas
14:58:12 <manu> Steven: if copy-paste is an issue, then authoring in general is an issue.
14:58:25 <manu> Steven: I don't think it's a big issue.
14:58:27 <manu> q+
14:58:36 <Zakim> -scor
14:58:37 <webr3> webr3 has joined #rdfa
14:58:39 <Steven> Niklas: CURIES are one way to make things easier, @profile can help too
14:59:33 <Steven> Manu: So profiles can be used to ease authoring and consumption by the browser?
14:59:38 <manu> ack manu
14:59:39 <Steven> Niklas: Possibly
14:59:44 <manu> ack lindstream
15:00:05 <Steven> Manu: can someone raise these issues on the mailing list to get some feedback?
15:00:14 <Steven> ... such as proposing removing @profile
15:00:20 <MacTed> I have to jump to another call...
15:00:37 <Steven> ... restricting @prefix to toplevel
15:00:54 <Zakim> -MacTed
15:00:55 <Steven> ]Manu: removing prefixes no one likes, but perhaps it's worth raising
15:01:05 <Steven> s/]//
15:01:11 <Steven> Greg: I'll do removing @profile
15:01:28 <Steven> Manu: I'll do restricting @prefix to head
15:01:41 <Steven> ... and removing prefix altogether
15:01:44 <Steven> s/[//
15:02:20 <Steven> Topic: Any other business?
15:02:39 <Steven> Steven: Enquire using doodle about coming meetings?
15:02:43 <Steven> Manu: I'll do that
15:02:45 <Steven> ADJOURN
15:02:53 <bergie> bye
15:03:20 <gkellogg> s/Greg/Gregg/
15:03:27 <Zakim> -Steven
15:03:29 <Zakim> -manu
15:03:31 <Zakim> -gkellogg
15:03:36 <Zakim> -Knud
# SPECIAL MARKER FOR CHATSYNC.  DO NOT EDIT THIS LINE OR BELOW.  SRCLINESUSED=00000296