RDFa Working Group Teleconference -- 11 Mar 2010

<trackbot> Date: 11 March 2010

<ivan> hey manu

<manu> Hi Ivan :)

<ivan> I cannot really change the header of the working group mailing list, I would have to go to systeam for that

<ivan> that is the problem; it should have been done when setting up the list

<ivan> my mistake

<ivan> yeah

<ivan> I did change the one of the public list

<ivan> is it worth going through that hassle? Let us wait until somebody else gets to the same problem...

<ivan> hm

<ivan> remember our discussion on how to set up the lists? :-)

<manu> I can contact the system team if you'd like with text that would correct the issue?

<ivan> I can do that, if you give me a text...

<Benjamin> hi everybody

<Knud> now I'm mute. :)

<tinkster> I will probably have to send regrets for next two weeks then.

<tinkster> Hello.

<tinkster> I don't mind doing it.

<scribe> Scribe: Steven

Note that the call is one hour earlier for Europeans next week and the week after

Action Items

<manu> http://www.w3.org/2010/02/rdfa/track/actions/open

Manu: Action 5 for Ivan?
... mark as done?

<manu> ACTION-5?

<trackbot> ACTION-5 -- Mark Birbeck to generate spec text for pulling in external vocabulary documents -- due 2010-03-18 -- OPEN

<trackbot> http://www.w3.org/2010/02/rdfa/track/actions/5

Ivan: the discussion is still ongoing

<manu> trackbot, close ACTION-5

<trackbot> ACTION-5 Generate spec text for pulling in external vocabulary documents closed

<manu> trackbot, comment ACTION-5 Ivan produced a merged specification explaining how to pull in external vocabulary documents.

<trackbot> ACTION-5 Generate spec text for pulling in external vocabulary documents notes added

Manu: URL for that Ivan?

Ivan: Just a moment, watch the IRC

Manu: I will fix the descriptions of the list

<ivan> vocabulary document (version 1)

ISSUE-1 RDFa Vocabularies (on Mark)

<ivan> vocabulary document (version 2)

<manu> The things that we may have consensus on:

<manu> * RDFa profiles are specified in an external document (profile document)

<manu> * We should use the @profile attribute to specify the profile document

<manu> * The @profile attribute can be placed on any element and is scoped

<manu> to the element on which it is defined and its children

<manu> * The profile document is marked up in RDFa, using a vocabulary

<manu> designed to modify the behavior of the RDFa Processor

<manu> * The default profile document can be specified in the RDFa Core spec.

<manu> This document will outline what prefixes and tokens are pre-defined

<manu> * The profile document can specify tokens and prefixes

<manu> * One does not use xmlns: to declare prefixes and tokens

<tinkster> ... but that <head profile> applies to *whole* document.

Ivan: I'm not sure all of these do have consensus
... such as the xmlns one

Manu: I thought there was opposition to the JSON method, so then there was one proposal left

Ivan: There are two issues
... whether we use an RDF vocabulary for prefixes and tokens, and then how we serialise
... I thought Mark was not in favour of the first bit
... though I and Ben are

Manu: So the last bullet point and what Ivan has just said are dependent on each other
... Mark said we should be able to use xmlns for prefixes and tokens

Ivan: You are right
... I am against that as well

Manu: There was a problem of leakage of prefixes into the authors document
... we may have consensus on the RDFa as profile bit
... we may want dc and foaf in the predefined prefixes
... we would do that by saying if there is no profile specified then use this one by default
... agree?

<manu> Steven: Do we really need to have a default profile?

Manu: we wanted to have a default case that was available without using profile

<tinkster> Would the default profile apply to XHTML+RDFa 1.1? or RDFa Core 1.1?

Steven: What is the advantage over saying that the defaults are always there?

Manu: There are two possibilities: overlaying your profile over the default
... or replacing the default with your profile

<tinkster> Other host languages might prefer different default profiles.

Manu: Answering Toby's question [scribe missed]
... Does ODF have a viewpoint on this?

Rob: Not really

Manu: I would expect ODF to want a different set of defaults

Rob: The vocabs we are seeing in ODF1.2 are about embedded vcards, events etc; no FOAF

Ivan: My proposal is we should postpone this discussion
... we don't know what a profile doc will contain
... so the default issue is premature

Manu: Fine

Steven: For ODF there is no real problem with always having an explicit @profile, since the authoring arguments don't apply

Manu: If we want the concept of a default profile we need to be able to support prefixes in a profile document

Ivan: I think the list if fine
... I'm not sure if we have consensus about dropping JSON

Manu: There are security implications associated with it, and CORS will solve it, and so will the RDFa API
... and we don't want to mark up in two different ways

Ivan: What does Toby think?

Toby: The format should be RDF of some kind
... in any serialisation, but only RDFa is the only required one

Steven: I think it is the wrong way round - there is no consensus on *adding* JSON

Shane: I agree strongly

<manu> The things that we still have to discuss:

Manu: I would still like to hear Mark; he will have to fight hard though

<manu> * What happens when you can't dereference the profile document? (Toby's proposal)

<manu> * Are we limiting next/prev/index/license/etc to @rel/@rev or allowing them everywhere?

<manu> * What is the mental model are tokens/prefixes two different concepts in RDFa or are they the same thing?

<manu> * Are there backwards compatibility issues with the proposed path forward?

Ivan: I agree with Toby
... RDFa is the only required serialization

<ShaneM> Me too

Manu: Mark seems to be concerned with the relation between token and prefix
... and there are backward compatibility issues
... Any other issues?

Ivan: No
... how will we decide?
... We have already had two versions of this document
... I would like to see a feeling for which direction
... we have to move on

<manu> Steven: There is no immediate hurry to move forward - we may want to let this stuff sink in for a while.

Manu: A lot of the decisions are interrelated, and that's why I would like a bit more time to hold back on making a firm decision
... I think we should point to the latest document, and then work with that

Ivan: The decision on the restriction of tokens to @rel @rev is important

<tinkster> Another possibility is allowing profiles to define keywords that only apply to particular attributes.

Manu: Anyone object to allowing all tokens everywhere?

<tinkster> e.g. typeof="Person"

Ivan: Then the management of keywords and prefixes becomes very different

Shane: For an implementation?

Ivan: No

<Benjamin> http://lists.w3.org/Archives/Public/public-rdfa-wg/2010Mar/0068.html

RDFa API Direction

Benjamin: See the above mail
... why is an API needed?
... I looked at the code of some of the libraries
... and how could an API help to reduce them
... conclusion - most of the code is for HTML attributes
... and so an API could help
... developers have to use some form of recursion
... an API may help that

<tinkster> yes

Benjamin: I looked at Operator for Firefox

<manu> yes

<Knud> yup

Benjamin: RDFa DOM API may help for that sort of app
... an API can hide the difference between URIs and CURIEs
... and external definitions in profiles

Manu: Are we focussing on RDFa parser developers, or web page developers?
... I think the latter

<tinkster> Certainly, to help page authors. The parser would be built into the browser.

<Knud> I think the latter

<manu> ack [IP

<Zakim> ShaneM, you wanted to ask about audience

<tinkster> DocA loads DocB in an iframe, and extracts triples from DocB.

<Knud> useful for mashups?

Shane: Who is our audience for this?

Manu: App writers, crawlers

<tinkster> Also GreaseMonkey/Opera User Scripts...

Manu: extracting the triples

Shane: So native in a browser, or a library?

Manu: Yes

Benjamin: If we have an API, we don't need RDFa parsers anymore?

<tinkster> The parser powers the API.

Manu: Yes

Shane: At least on the client side

Ivan: So my distiller will still be used.

<tinkster> Even though we have XML DOM, we still need XML parsers!

Manu: We want to make it easier for web developers to use

Benjamin: So the real focus is to extract RDF triples
... and it should be possible to query
... add triples, and remove them
... those last two may be optional

<manu> ack [IP

<Zakim> [IPcaller], you wanted to discuss add/removal of RDF triples

<ivan> +1 to the current order

Manu: Not sure about 2, and against 3 and 4

<tinkster> #3 is hard; #4 is easy but not especially useful without #3.

Manu: at least in the first version
... maybe we can build it up by stages

<ShaneM> I agree with Toby - you would need a CSS selector-like query interface... SPARQL in the browser

Manu: It would be difficult to do 3 and 4

Ivan: I think 1 and 2 should be the focus for now

Benjamin: We need to define the cut between the RDFa DOM API and the triplestore API

Manu: Big unanswered question

Ivan: Toby collected some APIs as examples

<tinkster> http://www.w3.org/2010/02/rdfa/wiki/RDF-API

Ivan: but what a triplestore API can do in a browser is unclear at the moment
... it is right to divide them

<Zakim> Manu, you wanted to discuss how this hooks into ODF and SVG

Ivan: for the time being, treat as separate

<ShaneM> +1 to permitting extracted triples to be put into a local triple store

Manu: We may want to decide if there are triggers that require the one API to use the other
... safety and privacy issues need attention
... shouldn't focus on the triplestore API
... we may want to see how the DOM API matches the SVG DOM API
... and there's ODF as well

Rob: No standardised DOM representation as of now

Manu: We should watch that though
... and talk to Doug Schepers too

Ivan: I have used the SVG DOM, I don't foresee a problem
... it is a read-only API
... only if we start adding and removing triples do I see a problem

<Zakim> Benjamin, you wanted to talk about the first sketch at http://www.w3.org/2010/02/rdfa/wiki/RDFa-DOM-API

Benjamin: Just to mention the first version

<ShaneM> Do we envision this is a 'live' list that is updated as there are mutation events, or a static list that must be updated by the developer as needed?

Benjamin: we should play with it
... try it out

Ivan: Looking at the microdata API would be a good comparison
... try to keep them similar

<tinkster> IIRC microdata API is quite resource-based, whereas current RDFa suggestion quite triple-based.

<Zakim> Manu, you wanted to end the meeting.

Ivan: Don't forget the time changes

Steven: Ivan and I can't make the call in two week's time, because of the W3C AC meeting

<tinkster> bye all!

<Knud> bye!

Ivan: And I will miss the call after that as well

[ADJOURN]

<Benjamin> bye

- DRAFT -

RDFa Working Group Teleconference

11 Mar 2010

Attendees

Contents

Action Items

ISSUE-1 RDFa Vocabularies (on Mark)

RDFa API Direction

Summary of Action Items

Scribe.perl diagnostic output