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

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


sorry for the poor quality of the line earlier. I need to make a correction
to the minutes:
s/inline/online

My point was that one could achieve something close to profiles with @vocab,
by defining a vocabulary which includes term mappings to other vocabularies.
For instance, this example from the specs

<div profile="http://example.org/profiles/alice">
    <span property="title">The trouble with Bob</span>
    <span property="name">Alice</span>
</div>

could be rewritten

<div vocab="http://example.org/vocabs/alice">
    <span property="title">The trouble with Bob</span>
    <span property="name">Alice</span>
</div>

where http://example.org/vocabs/alice defines the following terms mappings
in RDF:
http://example.org/vocabs/alice/title => og:title
http://example.org/vocabs/alice/name => foaf:name

browsers do not have to load the vocabulary, and RDF folks can dereference
it if they like. everyone is happy.

Steph.

On Thu, Jul 14, 2011 at 1:18 PM, Manu Sporny <msporny@digitalbazaar.com>wrote:

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