Re: Another way other than @profile, @vocab or @map

Hi Martin,

> I dont really have an issue with using rdfa profiles Im just not keen on the
> level of indirection that may be involved, It would make parsing more
> intensive, particularly if for whatever reason the profile is down, the only
> way to avoid this is either having a list of profiles stored with the parser
> or having the profile stored along side the document that has to be parsed,
> what happens if it becomes popular practice to omit the @profile attribute
> ...  I worry too much anyway ;)

A key part of the proposal is that processors may not even need to
retrieve the profile, since it may be a 'well-known profile'. In that
situation there is nothing that can go wrong.

For example, let's say that Google issues a profile that matches the
vocabularies that it processes when crawling. Obviously that would
include the rich snippets vocabulary, but since they process FOAF for
their social graph API, then the profile might also include that. In
short, it's a pretty useful profile.

Now, we all know that everyone loves to get their pages indexed, so
the first thing we can say is that people will almost certainly *not*
miss out the profile value. It would be like messing up your XML
sitemap, or producing a badly formed RSS feed; if you want to be found
then you need to get it right.

We can also assume that if Google is going to use this profile on
nearly every page they find, then they aren't going to waste time
loading it from somewhere else -- it will be built into the parser in
some way.

And finally, since we can extrapolate that this profile is going to
become pretty popular -- because you don't get indexed properly
otherwise -- then we can also assume that other RDFa parser creators
will consider embedding the values indicated by the profile right into
their parser, rather than retrieving it.

In short, a handful of key profiles will become well-known and
regularly used, and won't suffer from the shortcomings that you
describe.

(And I haven't even begun to talk about setting long cache expiry
times, and so on, on the profiles that don't fall into this
'well-known' category.)


> Better I think to have *all* the relevant information stored with the
> document itself ( like rdfa currently does ) than to introduce external
> files that may or may not be available for parsing.

There's nothing to stop you from embedding 15 namespace declarations
at the top of your documents if you are concerned about reliability.

But if you want that to be a core principle of the RDFa design, then I
think you do have to ask what we're trying to protect ourselves from,
when we worry about the small number of occasions when a profile will
not be retrievable.

(And as I've said previously, in another thread -- if your site uses
jQuery or Google Maps and you can't retrieve the scripts, you are in
just about the same location with no paddle. Long cache expiry times
are used widely in the JavaScript world to go some way towards
addressing this problem.)

Regards,

Mark

--
Mark Birbeck, webBackplane

mark.birbeck@webBackplane.com

http://webBackplane.com/mark-birbeck

webBackplane is a trading name of Backplane Ltd. (company number
05972288, registered office: 2nd Floor, 69/85 Tabernacle Street,
London, EC2A 4RR)

Received on Monday, 22 March 2010 18:58:47 UTC