Re: Last Call comments on RDFa Core (Issue-86)

On Dec 13, 2010, at 19:38 , Harry Halpin wrote:

>> Just for the records, and to link to the reference: I believe most of
>> Harry's  comments boil down to the issue the group discussed in the past:
>> 
>> http://www.w3.org/2010/02/rdfa/track/issues/46
>> 
>> The issue was closed, but can of course be reopened if the group wishes to
>> do so as an answer to Last Call comments.
>> 
> 
> I think *two* other separate issues should be opened for  (if they don't
> exist already)
> 
> 1) Using XHTML vocabulary document as a default profile for common
> vocabularies.
> 
>  Earlier I note that Toby Inkster thought that only W3C recs could
> register there. But this would exclude work like OGP or FOAF that is
> unlikely to be a Rec. We could run it like either the XPointer registry
> at W3C or in some new way, i.e. by looking at common prefixes for common
> vocabularies using empirical data.

While I see the interest in something like that, and I am trying to understand the mechanisms, I am a bit wary about the empirical data approach. What we would need is independent, ie, impartial sources of empirical data and I am not sure where we would find those from. I mean, prefixes like foaf, sioc, vcard, dublin core, creative commons have become ubiquitous, and I do not think anybody would object in taking them on board. Probably good relations, too. But I would not rely on data coming from google or yahoo that we could not check independently; nothing against them, but it might raise discussion questioning W3C's impartiality.

I am more in favour of some XPointer registry line. Something sketched by Tony: a dedicated mailing list where institutions would actively submit the prefix they would have to see in the profile, let a few weeks (months may be a bit too much in my view) go by where objections might be raised and, at the end of that period, W3C could decide whether yea or nay. The documentation of the profile file would also include a clear reference to the submission and the possible discussion thread. Something like that...


> 
> 2) Adding in extra blank node default subjects as a feature of RDF
> Profiles vocabularies, i.e. to make vocabularies like OGP produce valid
> triples. Note that in some instances of RDFa processing the profile is
> retrieved anyways, so might as well make it do very useful things.

I am not sure how to interpret the last sentence, I can read it as "they are not useful at the present state". I hope that is not what you meant...

As for the setting the default subject in the @profile file: I could see the point of that. But that would still mean that for the OGP usage one would have to say, for example,

<head profile="http://OGP-vocabulary-uri">
   <link....
   <meta....
</head>

ie, an extra active step for webmasters. In case the OGP prefix is taken up as part of the default XHTML profile, then the win of that, at least for OGP users, is not that big; after all, the effect can be reached by

<head about="_:blabla">
  <meta....>
</head>

which is about the same amount of typing. Ie, what is the gain? (b.t.w., one could also use about="_:")

Note that this would have interesting side effects, though. a <head> has, typically, copyright or stylesheet link statements. These are official XHTML terms, ie, they are interpreted as such. At the moment, they are triples generated for the base URI of the document which is the correct subject. If we have the mechanism above, than the stylesheet and copyright statements would go to the blank node which is meaningless. B.t.w., I am not sure this is what you meant, but if you wanted to have that blank node subject be part of the XHTML default vocabulary, that would have the same effects and also create a significant amount of backward compatibility issues...

Ivan


> 
> 
>> Ivan
>> 
>> ----
>> Ivan Herman
>> Tel:+31 641044153
>> http://www.ivan-herman.net
>>> 
>> 
> 
> 


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

Received on Tuesday, 14 December 2010 08:20:43 UTC