W3C home > Mailing lists > Public > public-rdfa-wg@w3.org > March 2010

Re: ISSUE-1: Status of RDFa Profiles

From: Mark Birbeck <mark.birbeck@webbackplane.com>
Date: Sun, 14 Mar 2010 15:48:41 +0000
Message-ID: <640dd5061003140848n5796c521k3089ce4ad8063754@mail.gmail.com>
To: Ivan Herman <ivan@w3.org>
Cc: Ben Adida <ben@adida.net>, Manu Sporny <msporny@digitalbazaar.com>, RDFa WG <public-rdfa-wg@w3.org>
Hi Ivan,

I appreciate you taking the trouble to reply, in between packing. :)

I won't respond to this just yet though, because I think the reply
that I sent earlier today, to a discussion that I was having with
Manu, explains my thoughts better than I had before.

So I'd like to wait and see what people think of that, if that's ok.

Have a good trip!

Regards,

Mark

On Sun, Mar 14, 2010 at 3:16 PM, Ivan Herman <ivan@w3.org> wrote:
> Mark,
>
> sorry, but I do not have time to go into a detailed discussion; I leave
> for Boston tomorrow and I still have to put my gears together... But
> some of the main issues, at least the way I see them
>
>
> On 2010-3-14 12:19 , Mark Birbeck wrote:
>
> [skip]
>>>
>>> My feeling is that we are forgetting about one of the major advantages
>>> of RDFa over, say, microdata (and whether we like it or not, I consider
>>> microdata as being here to say). And that is that RDFa scales gracefully
>>> over vocabularies while microdata (or microformats) do not. And that is
>>> due to the prefix mechanism.
>>
>> RDFa scales because it took into account URIs -- the building-block of
>> the semantic web.
>>
>
> I think we are saying more or less the same thing here but yes, the
> fundamental issue is URI
>
> [skip]
>
>>
>> And I realise you might also say, that
>>
>>
>> PREFIXES
>>
>> Prefixes are a way of saying 'here is a vocabulary and you can use any
>> term from it, simply by appending the term to a base URI'.
>>
>> However, it has become clear to me in my ontology work (and I'm not
>> alone in this), that what you invariably end up doing is bringing
>> together a collection of terms for a particular purpose -- terms that
>> come from different vocabularies.
>>
>
> Absolutely. And a great value of RDFa (whatever mechanism we use) is to
> make this possible.
>
> [skip]
>
>>
>>> As I said, the keywords mechanism is fine and essential. Of course, CC
>>> can provide a profile document if they wish so, and people will use it;
>>> it is not very complicated because the CC vocabulary is relatively
>>> small. For FOAF I begin to doubt; and if I look at the bibliography
>>> ontology, or the music ontology, I just do not believe that it is
>>> realistic to expect that anybody would come up with a keyword vocabulary
>>> for those, ie, a vocabulary file that would list each individual terms
>>> in those URIs to avoid using bibo: or mo: or foaf:.
>>
>> You've lost me...how is creating the token "name" any more difficult
>> to come up with than "foaf:name"?
>>
>> You might be saying that we can't be sure that "name" doesn't exist in
>> two different profiles, but that's just a case of us agreeing on how
>> to decide which wins. Microformats never had such a mechanism, which
>> is what made it difficult. I've already proposed a few techniques, and
>> no doubt others will suggest further ones.
>>
>
> Although the problem you refer to (clash of names) is real (witness the
> fact that Yahoo had to reinvent a namespace like mechanism for
> flickr...), that is not the issue I was referring to. Sorry I was not clear.
>
> What I was saying is that when one has a vocabulary with 40-50 terms or
> more (which may be the case for bibo or mo although I did not check)
> than it is not really realistic to expect that, say, the publishers of
> bibo will, beyond the OWL/RDF file and documentation, also provide a
> separate profile document that will explicitly list all the terms with
> their corresponding URI-s for the purpose of RDFa keywording.
>
> (You refer to the 'application profile' idea that DCMI is considering
> which is indeed the definition of subsets of the whole vocabulary for
> particular applications, but the many discussions and process that
> happen within DCMI on how to do that in a controlled fashion shows that
> it is not easy to set this up.)
>
> [skip]
>>
>>
>>> It is also
>>> unrealistic to expect an individual author to take the time and energy
>>> to form a separate vocabulary file for, say, the subset of bibo he/she
>>> would use locally.
>>
>> This is a crucial point, I think.
>>
>> First, I don't know why you think that prefixes would be removed in my
>> proposal; tokens and prefixes co-exist. So they can still use "bibo:"
>> if they want.
>>
>
> I did not say that! I know your approach encompasses both. Your "success
> criteria" were what triggered my response, though.
>
>> But more importantly, people don't mark-up documents in a vacuum;
>> "Individual authors" in the sense of the HTML author, will almost
>> certainly use the profile that most suits the work they are trying to
>> do. If they're concerned to get their page indexed by Google, then
>> they'll probably use Google's 'profile', when such a thing exists. If
>> they work for a library or are a scientist, then they will probably
>> use a profile that's been agreed at some international conference or
>> other. (The application profiles idea from Dublin Core [2] is also
>> relevant here.)
>>
>
> See above.
>
>> Any author that starts to form their own vocabulary is in my view
>> moving into the more techie end of the spectrum, rather than being
>> somehow 'everyday', and different criteria will apply.
>>
>>
>>> On the contrary, we should loudly encourage users to
>>> use a prefix mechanism when and if they need it...
>>
>> I really have to disagree strongly!
>>
>> :)
>
> :-) back ;-)
>
> More seriously: I think the prefix mechanism _is_ an asset for RDFa for
> many applications and authoring. We should not hide it:-)
>
> [skip]
>>
>>
>>> ... and we should make it
>>> easier than using just a load of @xmlns attributes. Ie, to paraphrase
>>> you I think we will also fail if we have not provided authors with a way
>>> to write prefixes simply.
>>
>> You mean 'declare prefix-mappings simply', of course -- since the
>> writing of prefixes doesn't change.
>>
>
> Sure
>
> [skip]
>
>>
>>> And, I am sorry Mark to disagree with you again, I maintain that a
>>> separate prefix and keyword mechanism are simpler concepts to grasp for
>>> non-experts than mixing the two together...
>>
>> So to recap on why I disagree with you disagreeing with me disagreeing with you:
>>
>> 1. For those who have never used namespaces before -- which should be
>> the bulk of our audience now -- telling them that they can use a token
>> on its own ("blah") or a token followed by a suffix ("blah:foo") is so
>> simple I'm shocked that you think people won't get it. (Ok...not
>> shocked...that was for effect...mildly surprised.)
>>
>
> So on the disagreement on what we disagree that with disagree that...
> (sorry, lost track on that one:-)
>
> Seriously: I think the only disagreement we really have, you and me, is
> whether the same mechanism should be used for prefixes and keywords, or
> whether the two notions should be kept separated. I think we both agree
> that we have to provide a mechanism for both (although we may disagree
> on the relative importance of things but that does not really matter).
>
> And the other disagreement is between Ben and me (or us?) insofar as Ben
> feels uncomfortable having _any_ mechanism for prefixes.
>
> I must admit I feel more strongly in my opinion against Ben (sorry Ben!)
> than in our disagreement. Ie: I can _live_ with a merge of prefixes and
> keywords though I continue to dislike it. But I think it would be a
> serious mistake not to provide _any_ prefix mechanism along the lines of
> profile documents.
>
> As far as I could see (looking also at other mails) the rest (JSON or
> not, RDF triples to describe things, etc) seem to be minor difference of
> opinion...
>
> Cheers, gotta run to pack for two weeks:-)
>
> Ivan
>
>
>
>
> --
>
> 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
> vCard  : http://www.ivan-herman.net/HermanIvan.vcf
>
>
Received on Sunday, 14 March 2010 15:49:17 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 04:55:06 GMT