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

Hi Mark,

I agree with your proposal, but I was thinking more in depth about it 
and it seems to me that the RDFaCore spec is going to be something like 
the spec of some attributes without anymore.
I mean, that, without the host language, you are not going to be able to 
provide "semantics" to the RDF-A attributes.

Thanks and best regards

Mark Birbeck escribió:
>
> 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 Thursday, 24 May 2007 15:53:59 UTC