Re: ISSUE-73 (RDFa Profile management): The RDFa WG needs to determine how each RDFa Profile document is managed [LC Comment - RDFa Core 1.1]

I do not think we should separate it in the official issue list, but I think we have some sub-issues that we may want to discuss and decide upon separately (I also give my opinion on those:-)

As I see them, here they are:

1. Do we need an XML+RDFa and an XHTML+RDFa default profile?

My feeling from the call, and also related to Issue-72: if we decide to have a separate XML+RDFa document conformance, then I think the answer to XML+RDFa profile must be yes.

2. Is there an 'inheritance', ie, would the XML+RDFa profile be valid for XHTML+RDFa, too? 

I think we agreed on the call that the answer is 'no'. But it is worth having that recorded here. This also means that some of the decisions on the content of these profiles is such that there may be overlaps between the two profiles.

3. What is the content of those profiles? Here again, we have some sub-issues that are worth separating

3.1: which terms should be in those profiles?

We have an obvious list for XHTML. I think those should be part of XHTML+RDFa, but should not be part of XML+RDFa; all those are really bound to (X)HTML.

There is a proposal to add the powder term (described by): this seems to be a useful term for XHTML and I would be in favour of adding it. I would consider adding it to the XML profile, too.

3.2: which default prefixes should be in those profiles (if any)?

(Note: we rejected default prefixes in the past but, I believe, the main reason was that we did not have the mechanism of default profiles at the time. The situation has changed...)

I would consider adding default prefixes for all the vocabularies being part of W3C recs. Ie, rdf, rdfs, owl, skos, powder, ... This would be valid both for the XHTML+RDFa and the XML+RDFa profiles. For the rest, see 3.4 below.

3.3: Toby has proposed additional relationships that connect the terms of XHTML+RDFa to, eg, dc terms and iana terms (eg, alternate is a subproperty of dc:relation, or equivalent to iana:alternate)

While connecting these to iana terms wherever appropriate looks clear to me, I am less sure about the relationship to vocabularies like bibo or dc. We may have to go into a lengthy process of checking with the organizations behind those to see if there is validity in those. Note also that there is no fixed organization for bibo, this is very much a grass-root issue. I think it is worth starting a community feedback call (eg, on swig) on those and, if that round can be finished when we go to Rec, adopt those. But the discussion may easily go out of bounds...

3.4: Are the profile files cast in concrete when we publish the Rec? 

Toby has proposed a policy mechanism to make those profiles updateable; I do not have a clear opinion in my mind yet. My instinct says that it would be good to have that, both for terms and for default prefixes; this would allow us to, say, add the facebook or google prefixes to the default profile of XHTML. But the mechanism is very touchy and we should avoid having a bias... 

Both for 3.3 and 3.4 we may actually play the google trick but not with google: I could imagine that search engines like sindice may have statistics about the usage frequency of certain vocabularies, and we can use that as an initial list of default prefixes and/or terms (beyond the W3C recs). 

I hope this helps...

Ivan


On Jan 6, 2011, at 18:27 , RDFa Working Group Issue Tracker wrote:

> 
> ISSUE-73 (RDFa Profile management): The RDFa WG needs to determine how each RDFa Profile document is managed [LC Comment - RDFa Core 1.1]
> 
> http://www.w3.org/2010/02/rdfa/track/issues/73
> 
> Raised by: Manu Sporny
> On product: LC Comment - RDFa Core 1.1
> 
> Based on a discussion in the RDFa WG telecon today:
> 
> http://www.w3.org/2010/02/rdfa/meetings/2011-01-06#XHTML_Profile_document_changes__2f_management
> 
> The RDFa WG needs to determine how each RDFa Profile document is managed. One management proposal was provided by Toby:
> 
> http://lists.w3.org/Archives/Public/public-rdfa-wg/2010Dec/0054.html
> 
> Another option is to create the XML+RDFa and XHTML+RDFa Profile documents and freeze them when the first specification that they're associated with goes to REC. Note the XHTML Profile document is associated with XHTML+RDFa 1.1 and HTML+RDFa - it would be frozen when XHTML+RDFa 1.1 goes to REC.
> 
> The RDFa WG should be careful to ensure that the management proposal doesn't block RDFa Core and XHTML+RDFa from going to REC.
> 
> 
> 


----
Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
PGP Key: http://www.ivan-herman.net/pgpkey.html
FOAF: http://www.ivan-herman.net/foaf.rdf