W3C home > Mailing lists > Public > public-rdf-in-xhtml-tf@w3.org > May 2007

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

From: Mark Birbeck <mark.birbeck@x-port.net>
Date: Thu, 24 May 2007 15:59:04 +0100
Message-ID: <640dd5060705240759m3abbfd94n27fc4238d9350695@mail.gmail.com>
To: RDFa <public-rdf-in-xhtml-tf@w3.org>

Hi José,

You are more than welcome!

Regards,

Mark

On 24/05/07, José Manuel Cantera Fonseca <jmcf@tid.es> wrote:
> +1 also.
>
> By the way, after being convinced of not creating a new attribute for
> classes :),  I'm starting to participate (is a small participation :), I
> know ) in discussions but I'm not a member of any of the groups involved
> in this task force, although my company is a W3C member. Is that a problem?
>
> I guess that the answer is no. It's like other W3C groups that work in
> public. The public can express opinions but the group has the last word.
>
> Thanks and best wishes
>
> Hausenblas, Michael escribió:
> > 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.
> >
> >
> >
> >
> >
> >
>
>
>
>


-- 
  Mark Birbeck, formsPlayer

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

  standards. innovation.
Received on Thursday, 24 May 2007 15:06:28 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:15:04 GMT