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

Hi Ben,

I do agree that it's primarily about a design philosophy. But within
that I would say that I'm trying to find a way of nailing down some
concepts that will remain fixed throughout what we do.

However, for the 'novice reader' I agree with you that we don't want
them to have to see the join; I think the RDFa primer serves that
purpose, and we should make it explicitly about the combination of
RDFa and XHTML/HTML *only*. As it happens, we decided to move in that
direction a while ago anyway, so there is probably not a lot to do
other than syntax stuff like reintroduce @resource, and of course the
checking of our examples.

In terms of the other documents, I think that the RDFa Syntax document
could become RDFa-core, and describe all the parsing rules,
namespacing (however we decide to do it), and so on.

The specifics of XHTML/HTML plus RDFa should form a third document,
but that pretty much already exists in the form of the schema/DTD
document, and that could be altered as necessary to tell the whole
story for XHTML/HTML.

I'm trying to think about how we create something that can be used in
other specs--such as in XHTML 2 or SVG--as well as avoid repetition in
our documents, so a stack of documents like this, seems to work:

  * RDFa-core, which describes syntax and parsing, plus some key terms;

  * 'RDFa in HTML Syntax', which describes the use of RDFa in the specific
    context of HTML/XHTML, and includes the schemas, DTDs, and whatnot.
    For implementers, features of HTML/XHTML are defined in terms of the
    'key terms' defined in RDFa-core. For example, we should be able to
    say simply that @href behaves exactly like @resource;

  * 'RDFa in HTML Primer', which describes the use of the whole thing.

Does that sound reasonable/desirable/workable?

Regards,

Mark

On 26/05/07, Ben Adida <ben@adida.net> wrote:
>
> 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
> >
>
>
>


-- 
  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 Monday, 28 May 2007 20:52:42 UTC