W3C home > Mailing lists > Public > public-rdfa-wg@w3.org > October 2010

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]

From: Ivan Herman <ivan@w3.org>
Date: Thu, 7 Oct 2010 11:56:37 +0200
Cc: RDFa Working Group WG <public-rdfa-wg@w3.org>
Message-Id: <83C533D8-CA34-4650-8494-1B37B0E79BA6@w3.org>
To: Mark Birbeck <mark.birbeck@webbackplane.com>

I can see the merit of this approach, just adding some more thoughts to the discussion, though

- you refer to the restriction of the automatic procedure to <meta>. I can see the value of that. But, if we do that, don't we reduce the dangers down to a level that we can simply go with the original approach (ie, no duplication of triples) but with that restriction?

- I think we said last time that we would restrict the mechanism to those uri schemes that are officially registered by the IETF. Your proposal would restrict it to http scheme only. I think that is way too restrictive for the user community we have in mind, which would use, for example, https, ftp, or mailto fairly frequently, too...


On Oct 7, 2010, at 11:27 , Mark Birbeck wrote:

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

Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
PGP Key: http://www.ivan-herman.net/pgpkey.html
FOAF: http://www.ivan-herman.net/foaf.rdf

Received on Thursday, 7 October 2010 09:56:50 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:05:21 UTC