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

Mark,

I think I like that. At least I have not found any major problem with it
yet (I am trying!:-)

Some immediate remarks:

- Maybe it is worth defining these attributes in their own namespace.
Ie, we could also envisage using that set in any XML application without
the need for that XML spec to be adapted. A good example is to add RDFa
data to an SVG file; SVG user agents are very tolerant and proper to
other namespaces, ie, I could use these without any further  change on
the SVG spec itself. Well... I still have to define somehow the mapping
itself (eg, in SVG, I guess the @property without @content could be used
on <desc> and <text> elements only) but no requirement on the SVG spec
and the SVG user agents at all.

In other cases, like XHTML1.1, changes are made to the host language
(ie, an XHTML1.1 module) that make the usage of the namespace
unnecessary (though probably possible; it should not be a bug to use the
namespace, just unnecessary)

- There is an analogy to this set of attributes' approach: ITS[1]. Note
that the I18N people will have the same problem with HTML5 as we do, ie,
how to get those set of attributes accepted... (I also wonder whether
XHTML1.1 should not pick up its, too, the same way as it does for RDFa,
but that is another issue)

- Actually... it would be an interesting exercise to do this mapping
with XHTML1.1 *and* SVG and not with the (hypothetical) XHTML2. It may
help focussing our thoughts...

Still trying to find a flaw:-)

Thanks

Ivan


[1] http://www.w3.org/TR/its/

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
> 

-- 

Ivan Herman, W3C Semantic Web Activity Lead
URL: http://www.w3.org/People/Ivan/
PGP Key: http://www.cwi.nl/%7Eivan/AboutMe/pgpkey.html
FOAF: http://www.ivan-herman.net/foaf.rdf

Received on Friday, 25 May 2007 08:34:37 UTC