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

Mark!
 
+1
 
Would it be a partition by levels [1] then?
 
Cheers,
Michael
 
[1] http://www.w3.org/TR/spec-variability/#subdivision-level
 
----------------------------------------------------------
 Michael Hausenblas, MSc.
 Institute of Information Systems & Information Management
 JOANNEUM RESEARCH Forschungsgesellschaft mbH
 Steyrergasse 17, A-8010 Graz, AUSTRIA

 <office>
    phone: +43-316-876-1193 (fax:-1191)  
   e-mail: michael.hausenblas@joanneum.at
      web: http://www.joanneum.at/iis/ <https://webmail.joanneum.at/exchweb/bin/redir.asp?URL=http://www.joanneum.at/iis/> 

 <private>
   mobile: +43-660-7621761
      web: http://www.sw-app.org/ <https://webmail.joanneum.at/exchweb/bin/redir.asp?URL=http://www.sw-app.org/> 
----------------------------------------------------------


________________________________

From: public-rdf-in-xhtml-tf-request@w3.org on behalf of Mark Birbeck
Sent: Thu 2007-05-24 16:15
To: RDFa
Subject: PROPOSAL: Split RDFa into two pieces--core attributes, plus language-specific 'interpretations'




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

--
  Mark Birbeck, formsPlayer

  mark.birbeck@x-port.net | +44 (0) 20 7689 9232
  http://www.formsPlayer.com <http://www.formsplayer.com/>  | http://internet-apps.blogspot.com <http://internet-apps.blogspot.com/> 

  standards. innovation.

Received on Thursday, 24 May 2007 14:34:06 UTC