Re: ISSUE-1: Status of RDFa Profiles

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