RDF Web Apps WG telecon minutes for 2011-07-14

Thanks to Steven for scribing! The RDF Web Apps WG telecon minutes for
July 14th 2011 are now available here:

http://www.w3.org/2010/02/rdfa/meetings/2011-07-14

If you would like to read minutes from this or previous meetings, the
public record of all RDF Web Apps WG telecons is available here:

http://www.w3.org/2010/02/rdfa/wiki/Meetings

Full text log follows:

----------------------------------------------------------------------------

RDF Web Applications Working Group Teleconference
Minutes of 14 July 2011

Agenda
  http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Jul/0028.html
Seen
  Gregg Kellogg, Henri Bergius, Knud Möller, Manu Sporny,
  Niklas Lindström, Steven Pemberton, Stéphane Corlosquet,
  Ted Thibodeau, Thomas Steiner
Guests
  Henri Bergius, Stéphane Corlosquet, Niklas Lindström
Chair
  Manu Sporny
Scribe
  Steven Pemberton

Topics
 1. Announcements and News
 2. ISSUE-96: Document not ready
 3. Any other business?

----------------------------------------------------------------------------

Manu Sporny: Any updates/changes to the agenda?

1. Announcements and News

Knud Möller: I have a quick question: is there any RDFa parser for iOS?
Knud Möller: or something along those lines?
Knud Möller: I was thinking of writing one, then
Manu Sporny: You could use: https://github.com/msporny/librdfa
Knud Möller: 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
Knud Möller: I'm not promising anything. :)
Ted Thibodeau: I haven't tested ... but ODE may already do, and should
be portable from base Mac OS X if not...
Knud Möller: just a toy project for me... I'll check out ODE
(Scribe set to Steven Pemberton)

Manu Sporny: http://80legs.com/
Ted Thibodeau: Knud - just tested... iOS Safari won't download/install
extension, so not yet. I'll make sure that's put on our roadmap.
Manu Sporny: 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.

... we are thinking of working with 80legs to get data about RDFa,
Microdata, and Microformats usage

... 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.

... 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.

Manu Sporny: I've been talking to people that work at browser companies,
trying to get feedback

... about what changes they would like to see in RDFa to make them happy

... they have been very willing to talk, which is a good sign

... so some recent bugs filed against RDFa are a result of those discussions

Niklas Lindström: 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.

... from my point of view, it's about publishing more data than we've
got today

Niklas Lindström: And they don't know why we want the data there

Manu Sporny: Robert Nyman?

Niklas Lindström: Yes, Mozilla and Firefox guy

Manu Sporny: Should we talk with them?

Niklas Lindström: I haven't spent a lot of time doing that yet, but I'm
thinking of doing more

Manu Sporny: 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.

Niklas Lindström: They don't grok why we need the graphs of RDFa

Manu Sporny: 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.

2. ISSUE-96: Document not ready

Manu Sporny: http://www.w3.org/2010/02/rdfa/track/issues/96
Manu Sporny: Which direction should we go with this?

Henri Bergius: +q
Gregg Kellogg: Doing a callback is my preference

Henri Bergius: 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

Niklas Lindström: I prefer callback

Manu Sporny: An RDFa doc can have miltiple profiles. Processing can be
done ignoring a subtree for a profile that can't be fetched

... just one event is difficult

... so how do we address one of 5 profiles not loading??

Niklas Lindström: We don't have to resolve the profiles immediately, we
could delay resolution until we need to turn it into RDFa.

Manu Sporny: 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?

Gregg Kellogg: That comes down to a usage model

... if the app knows what it needs. But doesn't get round needing to
know when you can process

... we can't get away from needing that feedback. We need to dereference
the profiles at some point.

Manu Sporny: So we could have a callback that gives a map of the
profiles and whether they have loaded

Gregg Kellogg: That would do it

... it's easier to have a second callback saying when all profiles have
been loaded

... knowing about failures could be useful

Manu Sporny: We could do the same with an event, it's about the
parameter passed with event or callback

Thomas Steiner: 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
... but one event/callback for each profile would require the developer
to keep track of which ones loaded successfully and which ones didn't.

... by the app writer

Steven Pemberton: Sounds like you need an event to say they've all been
done, and one error event if one of them fails. [ Scribe Assist by Manu
Sporny ]
Thomas Steiner: so you'd have an event dataloaded or whatever with
fine-grained success/failure states
Thomas Steiner: then +1 for doing it the XForms way, Steven ;-)
Manu Sporny: 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.

Niklas Lindström: The latter

... I agree with an evet/callback saying everything is ready

... progress reporting is not so important

Manu Sporny: So maybe an event and a callback, event is RDFa-data-ready,
the callback is an error callback

... does that cover it?

Niklas Lindström: I think so

Henri Bergius: Sounds good
Henri Bergius: Sounds good. Keep things simple.

Thomas Steiner: document.ondataready(event)
Thomas Steiner: similar to document.onload
... try running VIE editing environment on top of RDFa API, would be a
good test case

Manu Sporny: Some like the microdata API because there is only one call

Henri Bergius: link to VIE for those who haven't seen it:
https://github.com/bergie/VIE#readme
Niklas Lindström: One remark, using profiles we don't need to use URIs,
but the mapping is awkward for developers

Manu Sporny: So maybe we need a "getraw" for the attribute as used in
the page

Stéphane Corlosquet: So @profile is a new feature; why not have the
default profile in the spec, and no other profile at all.

... what is the real benefit of profiles?

Manu Sporny: The one big use case is microformats

... the other is for people who don't like CURIES

Stéphane Corlosquet: Well, they can define the vocab inline

Gregg Kellogg: Microformats work with a profile with an NCNAME

... maybe we can provide those as standard

Steven Pemberton: The reason profiles are there are to provide an
extension mechanism. [ Scribe Assist by Manu Sporny ]
Manu Sporny: Good discussion, revisiting some of these decisions.
Stephane made a good point, that most of the profile use cases could be
addressed with @vocab

... but vocabulary mixing wouldn't work

... but you could just use prefixing

Niklas Lindström: 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

Manu Sporny: So you support removing @profile?

Niklas Lindström: Not sure. I like @profile

Manu Sporny: People were wondering why we were using URLs to identify
everything.

... they suggested using a default profile, with registering prefixes at
the profile

... a registry

Steven Pemberton: The idea is to give freedom, not asking people to
register. It's like asking people to register class names

Henri Bergius: I second that

... people can use the ontology they feel like

Knud Möller: could we have both: a registry _and_ a local prefixing
mechanism?
... I'm strongly against registering

Niklas Lindström: I support Steven and Henri on this

Ted Thibodeau: centralized registries are trouble
Knud Möller: a registry could help 80% of the big name use cases, the
local prefixing could help the rest?
Gregg Kellogg: @profile is a complication in an implementation

... we should think about removing it

... @prefix does address the use cases

Ted Thibodeau: Centralised registries are always problematic. Doomed

... RDFa is successful because it is not centralised

... eventually we should think about getting rid of prefixing

Manu Sporny: Is that an argument for @profile

Ted Thibodeau: Not sure

Ted Thibodeau: Ultimate solution is doc to be fully expanded at delivery

Steven Pemberton: I disagree with that point of view

Ted Thibodeau: Shorthand gets in the way of knowing what the fully
expanded form is

Steven Pemberton: I think that is anti-author

... writing the full form URIs would be awful

Gregg Kellogg: Some of the copy-paste issues could be addressed at the
top-level

q+ on copy paste

Gregg Kellogg: There is something to be said for things that are easy to
read

... full URIs are a nightmare

... CURIEs are elegant in comparison

Manu Sporny: 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.

Ted Thibodeau: Where it happens is up to a lot of things

... you may not have control over the webserver

... there are multiple stages where these things matter

... who pays? The author, the end user, the programmer?

... The ugliness should be hidden from the enduser

Zakim IRC Bot: Steven, you wanted to comment on copy paste
Steven Pemberton: 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 [ Scribe Assist by Manu
Sporny ]
Steven Pemberton: if copy-paste is an issue, then authoring in general
is an issue. [ Scribe Assist by Manu Sporny ]
Steven Pemberton: I don't think it's a big issue. [ Scribe Assist by
Manu Sporny ]
Niklas Lindström: CURIES are one way to make things easier, @profile can
help too

Manu Sporny: So profiles can be used to ease authoring and consumption
by the browser?

Niklas Lindström: Possibly

Manu Sporny: can someone raise these issues on the mailing list to get
some feedback?

... such as proposing removing @profile

Ted Thibodeau: I have to jump to another call...
... restricting @prefix to toplevel

Manu Sporny: removing prefixes no one likes, but perhaps it's worth raising

Gregg Kellogg: I'll do removing @profile

Manu Sporny: I'll do restricting @prefix to head

... and removing prefix altogether

3. Any other business?

Steven Pemberton: Enquire using doodle about coming meetings?

Manu Sporny: I'll do that

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: PaySwarm Developer Tools and Demo Released
http://digitalbazaar.com/2011/05/05/payswarm-sandbox/

Received on Thursday, 14 July 2011 17:19:02 UTC