Re: attempting to merge the 'vocab' and 'profile' documents

Hi Ivan,

> It is not my goal to use RDF just to use RDF, obviously. But RDF gives
> me a way to define both the concepts and the resulting mechanism in an
> abstract manner that is independent of the serialization. And that is
> what I think is nice in Manu's original document.

Of course I agree, and my guess is that every time any of us needs to
define something, we all reach for RDF. :) After all, just about
everything can be expressed using triples -- why not the properties
that guide the creation of triples.

But then when you delve into this a little deeper, you are left asking
whether it is actually the right thing to do, to define profile values
using triples.

For example, take the notion of 'base' -- the base URI used to guide processing.

It's expressed in HTML/XHTML+RDFa using the base attribute, and in N3
using the @base syntax. In my RDFj syntax, I use a property in the
context object.

I.e., in all of these situations it's not expressed using RDF.

Now, you *could* say, what's the big deal? Surely 'base' is just like
a predicate; we can easily say 'this document has a base of <x>'.

But what if, when we look at <x> we discover that it's a relative URI?
What do we make it absolute against? After all, it's the base.

Perhaps we get round it by saying that the value must always be
absolute? But then we're no longer dealing with RDF, because there are
no such restrictions on any other resource URIs in RDF.

It gradually emerges that 'base' is not a 'property' of the current
document at all; it's a precondition for extracting the properties of
the current document. And I believe that this same circularity rears
its head with other profile properties (although the issues are less
direct), which is why I think we should avoid this altogether.

This dicussion is not dissimilar to the argument that took place on
the list about whether @profile can be expressed as @rel="profile"; I
believe that the key point is that you need some 'out of band' method
to express the values that drive processing, and that method needs to
be distinct from what you are actually processing.

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 Friday, 5 March 2010 16:54:39 UTC