W3C home > Mailing lists > Public > public-rdfa-wg@w3.org > February 2011

Last Call Response to ISSUE-46: Conversion of Plain Literals to IRIs

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Sun, 06 Feb 2011 14:12:24 -0500
Message-ID: <4D4EF298.20303@digitalbazaar.com>
To: Harry Halpin <hhalpin@w3.org>
CC: RDFa WG <public-rdfa-wg@w3.org>
Hi Harry,

This is an official response from the RDFa Working Group concerning your
comments around ISSUE-46: automatically converting plain literals to IRIs.

During the triage of your issue, both you and Ivan had a fairly in-depth
discussion about how to deal with each sub-part of the issues that you
raised. The result of one of those discussions was the re-opening of an
ISSUE that we had addressed and closed previously:

http://www.w3.org/2010/02/rdfa/track/issues/46

ISSUE-46 basically asks the question of whether we should automatically
convert things that look like URIs in Plain Literals to IRIs in RDF
output. So this:

<meta property="foo:bar" content="http://example.org/baz" />

would generate the following triple:

<> foo:bar <http://example.org/baz>

instead of what would be generated in RDFa 1.0:

<> foo:bar "http://example.org/baz"

We re-visited this during a telecon last week:

http://www.w3.org/2010/02/rdfa/meetings/2011-02-01#ISSUE__2d_46__3a__Should_plain_literals_that_match_fully_qualified_IRIs_be_automatically_converted_to_IRIs

We had discussed whether having IRIs in plain literals was damaging to
the semantic web on a number of occasions previous to the discussion
above. In each of these discussions, the only downside that we could see
is that applications that read in an IRI via a Plain Literal would need
to do the conversion based on the vocabulary term that was being used.

For example, in the case of Facebook's OGP term "og:url" in a META
element, a consuming application would need to take care of the IRI
conversion during a post-processing step, instead of the RDFa Processor
automatically doing the conversion for the application (based on the
value being in a @href or @resource attribute). Post-processing of
triples is expected in cases like this, so this didn't strike the RDFa
Working Group as particularly troubling.

Additionally we found that, and this is a big technical issue with what
you propose, there is no deterministic way to tell the difference
between an IRI and a plain text string with a colon in it. That is, we
cannot tell whether "foo:bar" is a plain text string or an IRI unless it
is in @href, @src, or @resource. That non-determinism issue is the final
nail in the coffin of auto-detecting IRIs in PlainLiterals. There is no
clear technical solution to that problem. If there was, we would be far
more open to implementing your suggestion.

So, we're closing ISSUE-46 without adding this feature because we don't
think there is a technical issue with the status-quo, because nobody
seems to have a deployment concern with it, because we don't want to
further complicate the RDFa specification and because changing it would
introduce a non-deterministic parsing algorithm capable of introducing
false IRIs into RDFa processor output.

Thank you for your feedback on RDFa Core, Harry and for your continuing
input into the RDFa Working Group. We have attempted to address your
concerns with this issue to the best of our ability.

Since this is a Last Call issue, we ask that you please respond to this
e-mail and let us know if this solution works for you.

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: Towards Universal Web Commerce
http://digitalbazaar.com/2011/01/31/web-commerce/
Received on Sunday, 6 February 2011 19:12:54 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:19:50 UTC