RE: Whether property values should be namespace prefixed

Tantek,

> Also, Mark's opening premise:
> 
> >> INTRODUCTION
> >> The usual approach with RDF is to say that everything that is 
> >> unprefixed is in a namespace that comes from the URI of 
> the current 
> >> document.
> 
> This ignores the fact that HTML (and XHTML) has a mechanism 
> for defining unprefixed <meta> property names and 'rel's, 
> namely, profiles which are referenced using the 'profile' 
> attribute of the <head> element.
> One example of what the 'profile' attribute can refer to is 
> XMDP. XMDP (conveniently built from XHTML) is a profile 
> format which allows easy defining of unprefixed property 
> names and relationships.
> 
>  http://gmpg.org/xmdp/

I don't feel this addresses the problem.


HUMAN READABLE V. MACHINE READABLE
XMDP is a great solution for providing *human readable* definitions, but
that is not the problem that we need to address. I am trying to:

  * provide RDF triples,
  * from XHTML documents,
  * without having to link to external documents,
  * without XHTML authors having to learn RDF/XML,
  * and without browsers having to include an RDF/XML
    parser.

My basis premise is that documents authors are placing an enormous of amount
of metadata into their documents, and it would be good to make this
available at the semantic level. The easier this is to author and process,
the more data we get out.


UNAMBIGUOUS PROPERTIES
Even putting aside my 'goals' you can see that @profile doesn't help
disambiguate property names:

  <html>
    <head
     profile="http://purl.org/dc/elements/1.1/
              http://www.example.org/software/"
    >
      <meta property="creator">Mark Birbeck</meta>
      <meta property="creator">Microsoft Word</meta>
      ...

You seem to think this is not a problem:

> Since the remaining analysis assumes that there is a problem 
> with unprefixed property names etc., and I strongly disagree 
> with that assumption ...

but how do we know which 'creator' is from which taxonomy? And that assumes
that we even know we have a taxonomy, i.e., we know what to do with these
@profile URIs, which as you yourself point out, we don't.


SPECIFYING URIs
Since @profile is just a list of URIs that may or may not be retrieved [1],
why not use a much more widely used mechanism for "listing URIs that may or
may not be retrieved" - XML namespaces. Why is this:

    <head
     profile="http://purl.org/dc/elements/1.1/
              http://www.example.org/software/"
    >

preferable to this?:

  <html>
    <head
     xmlns:dc="http://purl.org/dc/elements/1.1/"
     xmlns:sw="http://www.example.org/software/"
    >
      <meta property="dc:creator">Mark Birbeck</meta>
      <meta property="sw:creator">Microsoft Word</meta>
    ...

especially when, as I said before, the first approach doesn't even solve our
problem.


XHTML IS XML
This last point is even more significant when one of the design aims of
XHTML 2 is to use XML mechanisms wherever possible:

  "As generic XML as possible: if a facility exists in XML, try
  to use that rather than duplicating it." [2].


CONCLUSION
@profile is well past its sell-by date, and it never even solved the problem
is was hoping to. If it had then the RDF and HTML communities wouldn't be
trying to solve this problem now.

Regards,

Mark

Mark Birbeck
CEO and CTO
x-port.net Ltd.

Download our XForms processor for IE
from http://www.formsPlayer.com/


[1]
http://www.w3.org/TR/1999/REC-html401-19991224/struct/global.html#profiles
[2] http://www.w3.org/TR/xhtml2/introduction.html#aims

Received on Thursday, 15 April 2004 05:33:16 UTC