Re: [RDFa] rdf:XMLLiteral (was RE: Missing issue on the list: identification of RDFa content)

Hi Ian,

> Needless to say this argument is completely bogus.

Why "needless to say"?


> Using the language
> attributes as you suggest is clearly the author's intent. If they wanted
> to encode a triple without the language, then they'd omit the language
> attribute.

You keep talking about authors 'encoding triples', but I'm trying to
stress that RDFa is primarily about being able to extract metadata
from documents that XHTML authors have created without them really
being aware of RDF. The idea has always been that if we can make it
easy for XHTML authors to add metadata then the 'RDF community' will
benefit.

So, given that having a language attribute is best practice in
XHTML-land, we can't really go suggesting that it is removed.


> Either way, RDFa currently provides no way of encoding a triple with a
> plain literal value using the text that the author has marked up.
> Currently it requires duplication of the text in a content attribute.
> This is a serious flaw.

That's true. And one part of addressing this question is to establish
whether this makes any difference in practice. Elias has an action
item from today's telecon to provide some examples of where having
plain literals is crucial.


> > So, all I did when trying to address this problem originally was ask,
> > what is so bad about the following triple being used instead:
> >
> >  <http://example.com/doc> dc:title "RDF or Bust"^^rdf:XMLLiteral .
>
> So, perhaps this is the flaw in your logic that you're asking us to
> find.

No...I'm not asking you to find anything. But I am asking for a better
proposal than the current one, that still addresses a number of
requirements. The key one being that XHTML authors do not have to know
about RDF, and that is the *only* reason I suggested using XML
literals as the default way, way back. No-one has yet come up with a
way of having a default of plain literals that does not require
authors to add extra mark-up when they have mark-up in their text.


> This is completely incompatible with having a language on the root
> element since "RDF or Bust"^^rdf:XMLLiteral is a typed literal which may
> not have a language.

That is certainly true. But that is a problem with RDF, not RDFa.
There has been much discussion in RDF-world about lack of language
support for typed literals.


> > Although it's not perfect, I found after a lot of research that there
> > isn't as much wrong with it as one might initially think, and I've
> > still not heard of another way to solve all of the issues and remain
> > consistent with our design goals.
>
> There is a lot wrong with it. Your technical argument ignores the social
> aspect entirely. Did you survey how people are using RDF instance data
> to determine whether people prefer to use plain or XML literals? If so,
> can you provide a URI so I can see the results.

RDFa is *not* an RDF serialisation syntax first, even thought it is a
pretty good one. It originated in work by the XHTML Working Group, as
an attempt to find a way to get more semantic information into XHTML
documents, in such a way that it is easy for authors. Given that, why
would I survey triple stores?

But more importantly, there is no social aspect to this issue. RDF
defines both plain literals and typed literals, and it defines how
literals are compared for equality. There's not much more to it than
that, and to suggest that we should look at whether typed literals are
more common than plain literals is just strange. It's like asking
which numbers are more common. Should everyone who is 6 ft tall choose
to be either 5 ft or 7ft, since those numbers are more common than 6?
It's a non-argument, because we're not dealing with specific numbers,
but a numbering _system_, and RDF is exactly the same--it's an entire
system that you cannot cherry-pick.

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, 19 March 2007 21:01:48 UTC