Re: PROPOSAL: Split RDFa into two pieces--core attributes, plus language-specific 'interpretations'

Mark,

I generally fully agree with the approach that we don't change the core
language, RDFa only adds attributes and utilizes existing host language
attributes where they make sense. That's beautiful. I've been trying to
express this exact approach in the last few months (specifically with
respect to the href everywhere discussion), but you did it much better!

The one thing I would hesitate to do is to call this "splitting RDFa in
two," because what you call "RDFa core" doesn't really stand on its own.
In addition, this split might make things look much more complicated
than they actually are to the novice reader, e.g. "What, RDFa has
multiple layers and parts? Oy, microformats sound much simpler."

In other words, I think what you're describing is more of a design
philosophy than a naming scheme for RDFa.

What do you think?

-Ben

Mark Birbeck wrote:
> 
> Hello all,
> 
> I'd like to suggest that we split RDFa in two, as a way of addressing
> a variety of issues. This is slightly separate from the use of the
> @profile attribute, although could end up being related.
> 
> 
> MOTIVATION
> 
> The main motivation for this is that we're finding out, in a piecemeal
> fashion that some features of RDFa are problematic in some browsers,
> or that some people think that one feature or another would cause
> confusion. It seems better to unroll any changes to host languages,
> and take RDFa 'back to its roots', a little, with a focus on
> attributes. However, instead of just making RDFa into a set of new
> attributes in the way that it used to be, we make use of everything we
> have learned about making metadata work in HTML, and create an
> 'interpretation' of
> 
> 
> PROPOSAL
> 
> My picture of RDFa is that it can be seen as a series of 'layers'. The
> first layer would simply be the RDFa-specific properties, which could
> be applied to any mark-up. This gives us:
> 
>  @about
>  @property
>  @resource
>  @datatype
>  @content
> 
> (Haven't got time to check if I've missed any...but you get the point.
> :) We also need @id/@xml:id, but we could say that it is provided by
> the host language.)
> 
> Note that we could add elements to this list:
> 
>  link
>  meta
> 
> but I think they are only needed if we support reification, so we can
> put that to one side until that whole question is resolved.
> 
> Anyway, RDFa-core (just a working name :)) would define these
> attributes, and describe how triples are generated from them. It would
> also describe how to get namespacing. (I mean this in the broadest
> sense of the term, as opposed to the XML namespace sense, and this
> will be described in a separate proposal.) The upshot of this 'level'
> is that we get something a bit like N3, using XML as the
> serialisation.
> 
> 
> Although these attributes can be applied to any language, there will
> often be semantic features available in the languages being augmented,
> so the second layer up is to describe how some particular language
> provides language-specific syntax. So, at this level, when applied to
> HTML 4.01 or XHTML 1.x, we might have @rel and @rev, @href, <link> and
> <meta>, and so on. We'd also say what happens to <img> and @src, and
> maybe even things like @hreflang.
> 
> But whatever we define, my feeling is that at this level we should
> *not touch* the host language. So if HTML doesn't support '@href
> anywhere', then we don't add '@href anywhere' as a feature. In other
> words, all we are doing at this level is saying 'here is the RDF
> interpretation of existing mark-up', and of course adding the
> RDFa-core attributes. The process of creating the mappings could
> actually involve looking at all semantic features of a language and
> seeing what rules could be created form the language--so @title, for
> example, seems like it ought to generate an rdfs:label on a bnode. But
> the main point is that we should not _change_ the language, other than
> adding the RDFa-core attributes.
> 
> The justification for this approach is that we then take no chances
> with what browsers can support; for example, we don't have any
> problems with <link> and <meta> being moved from body to head in some
> browsers, since we simply don't allow it. And we don't have to debate
> whether @href should be allowed anywhere, because again, we just don't
> allow it. It makes life a whole lot easier since instead of having to
> do laborious testing to work out whether browsers will support this
> feature or that, we just rely on the one feature that we know to be
> safe--the addition of the RDFa-core attributes.
> 
> Now, there is nothing in this that stops new languages from being
> created that incorporate RDFa-core right into their heart, and then
> add more complex constructions, like <meta> anywhere, or @href
> anywhere. An example is obviously XHTML 2, although there could well
> be others. But the key change I'm suggesting is that it would be up to
> XHTML 2 to introduce ideas like '<meta> anywhere', '@href anywhere',
> and so on. Those ideas would not be in the core of RDFa, they would be
> part of the 'interpretation' layer, just like we have an
> interpretation of HTML that gives a meaning to @rel and @rev.
> 
> Regards,
> 
> Mark
>

Received on Saturday, 26 May 2007 02:59:41 UTC