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

Re: IRIs are distinct from literal strings?

From: Nathan <nathan@webr3.org>
Date: Tue, 04 Jan 2011 16:54:23 +0000
Message-ID: <4D2350BF.3040600@webr3.org>
To: Tim Berners-Lee <timbl@w3.org>
CC: Manu Sporny <msporny@digitalbazaar.com>, RDFa WG <public-rdfa-wg@w3.org>
Hi Tim,

Tim Berners-Lee wrote:
> 2) I am confused a little in that these functions all return
> URIs as as strings, so  I am not sure how this fits with my previous comments
> about having named nodes as first class objects, in which can one will need
> routines to return them.
> How do you you use the API to add to the store the equivalent of this N3
> 	<#Joe>  foo:homepageURI "http://example.com/fred";
> 			foo:homepage <http://example.com/fred>.
> distinguishing the objects?

In the API [1] it's the distinction between a NamedNode and a Literal

rdf.createLiteral("http://example.com/fred"); // Literal
rdf.createNamedNode("http://example.com/fred"); // NamedNode

Then it's up to implementations on just how they expose these 
interfaces, for instance in one of my projects JS3 the approach would be:

   "http://example.com/fred" // NamedNode
   "http://example.com/fred".datatype = ""; // now a Literal

Other approaches in the library include setting the default prefix to 
"http://example.com/" then doing ":fred", or using a prefix like 
"ex:fred" to get NamedNodes, and to get strings setting the datatype, 
the lang, or adding a simple method like toString() can easily address 
the type juggling side of things.

These are just a few of many approaches, however any implementation 
(offering an abstraction layer) simply needs to decide whether strings 
which match the syntax of a URI/term/qname are taken to mean NamedNode 
or Literal by default, then offer a way to juggle between them. Or of 
course, whether to be more verbose and use the create* methods (which 
will always be exposed by any implementation of the API).

[1] http://www.w3.org/2010/02/rdfa/sources/rdf-api/#overview


Received on Tuesday, 4 January 2011 16:56:19 UTC

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