Re: ISSUE-46 (conversion of plain literals to IRIs): Should plain literals that match fully qualified IRIs be automatically converted to IRIs [RDFa 1.1 Core]

Hello all,

I won't be on the call today, and thought I'd best get some notes in
on this issue, in case it goes to a vote.

I think automatic conversion is a non-starter, since it throws up so
many other issues, and I would definitely be against it.

However, I have an idea that I haven't had time to play with, but it
may provide another line of enquiry on this issue.

A different way of coming at this would be for the parser to generate
*both* a literal *and* a URI in certain circumstances. I haven't had a
chance to work through the implications, or to think through whether
this is something that the spec would mandate or make optional, but
the essential rationale is that:

  * removing information is not a good idea, so changing something from
    a literal to a resource is to be avoided;

  * adding information is something else entirely, so we should therefore
    consider the implications of adding an extra resource that 'complements'
    the literal.

Given the use-cases that the 'large RDFa adopters' have outlined, we
could start conservatively with this approach and restrict it to (a)
just the <meta> element, and (b) only those URIs that begin 'http'
(given that the justification for this is that new authors might make
a mistake).

As it happens I don't see many downsides to having the extra triples
in all circumstances, since developers can go in either direction
(literal or resource) by constructing their queries accordingly. But I
don't think it hurts to limit ourselves to addressing only the
use-case requested, at least until other people have chimed in.

Whilst we're here, one thing I've mentioned before is having some kind
of switching mechanism that allows us to give authors more control
over the parsing. I think this would be a good time to return to this
question, because then we could provide authors with a way of turning
off these duplicates, without having to use some per-element mechanism
like @datatype.

Perhaps a 'mode' attribute which takes a series of flags?

(This might also help in the XML Literal issue.)

Regards,

Mark

On Sun, Oct 3, 2010 at 6:47 PM, RDFa Working Group Issue Tracker
<sysbot+tracker@w3.org> wrote:
>
> ISSUE-46 (conversion of plain literals to IRIs): Should plain literals that match fully qualified IRIs be automatically converted to IRIs [RDFa 1.1 Core]
>
> http://www.w3.org/2010/02/rdfa/track/issues/46
>
> Raised by: Ivan Herman
> On product: RDFa 1.1 Core
>
> This issue was raised by two large RDFa adopters that would like to see the following markup
>
> <meta property="foo:bar" content="http://example.org/baz" />
>
> generate the following triple:
>
> <> foo:bar <http://example.org/baz>
>
> instead of what would be created in RDFa 1.0:
>
> <> foo:bar "http://example.org/baz"
>
> It's fairly clear that the author intended the first triple and not the second, however, RDFa does not allow a simple way to generate the first triple. The change request would make it such that when an IRI is detected as a plain literal, the value is converted to an IRI. If the author would prefer to generate a plain literal instead, datatype="" could be provided in those corner cases.
>
> It has been suggested that we add this as an at-risk feature to RDFa Core and ask for broader community feedback.
>
>
>
>

Received on Thursday, 7 October 2010 09:28:40 UTC