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

+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.
>
>
>
>
>
>

Received on Thursday, 24 May 2007 15:54:53 UTC