RE: URIS for Literals

I think this discussion of URIs for literals is a red herring, and obscures 
the more fundamental discussion about using literals as subjects of RDF 
statements.  Are there any fundamental semantic problems?  Absent OWL, I'd 
say not, but I'm not sure whether or not OWL makes this idea more diffcult.

The use of data: URIs serves as a valuable example that literals, too, 
denote resources, and URIs can be used in RDF to denote those resources.  I 
don't think it's an *architectural* issue to discuss the lexical form of 
those URIs.

I picked this particular email to respond in this thread because there's a 
small additional point I wish to clarify:

>However, the scope of things that we want to comment about using RDF
>surely includes both concepts (such as the idea of "number" vs the
>lexical form "number"), ...

This distinction between lexical form and the value denoted is already 
strongly embedded in the formal semantics for RDF.  Thus, lexical forms like:
   ("123",xsd:integer)
are elements of RDF abstract syntax that are used to denote integer values 
(in any model theoretic interpretation of RDF that includes the xsd:integer 
datatype restrictions).  And additionally, there are syntactic terms in RDF 
that, under suitable interpretations, denote the various lexical forms that 
might be suggested.

There are other legitimate points made in this email (to which I am 
responding);  I just wanted to pick on that one.

#g
--

At 07:15 30/10/04 -0400, Thompson, Bryan B. wrote:
>So, a question on this notion of using URIs for literals.  The notion is
>basically creating generative vocabularies for certain types of data in
>which the parts of the identifier (the URI) are parsed in order to know
>the type and value of the data.
>
>However, the scope of things that we want to comment about using RDF
>surely includes both concepts (such as the idea of "number" vs the
>lexical form "number"), a variety of infinite small typed data (integers,
>reals, string values up to some pragmatic length limit, SSNs, etc), and
>a whole range of data that are not going to, pragmatically speaking, fit
>within a URI, such as a specific JPEG image.
>
>When we have (a) larger data; or (b) the desire that the data may be
>updatable or definable by some authority, then an agent needs to use
>some protocol, e.g., HTTP, and some identifier, e.g., a URL, in order
>to access the representation of the data in a resource.
>
>When we have small data and a desire to lock down the meaning of the
>data, then we can use a Base URI and perhaps a generative grammar to
>map out a vocabulary of URIs whose meaning is fixed by an authority
>such that there is no need to de-reference the URL to obtain a
>representation of the state of the identified resource -- and since
>the expectation of the resource state is locked down by a standard, we
>do not even need to put up a server that would respond to those URLs.
>
>So, maybe the standardization of the expectation of the meaning of a
>URL can be seen as removing the need for using a protocol to obtain
>a representation of the state of the identified resource - and even
>the need to have a server that will respond to that URL?
>
>Thanks,
>
>-bryan
>
>-----Original Message-----
>From: www-tag-request@w3.org
>To: noah_mendelsohn@us.ibm.com
>Cc: Graham Klyne; Joshua Allen; Stuart Williams; Tim Berners-Lee;
>www-tag@w3.org
>Sent: 10/29/2004 4:32 PM
>Subject: Re: URIS for Literals (was: Re: referendum on httpRange-14 (was RE:
>"information   resource"))
>
>
>On Friday, October 29, 2004, 6:41:02 PM, noah wrote:
>
>nuic> Chris Lilley writes:
>
> >> With the proviso that I would prefer
> >>
>nuic>
>data:text/plain;charset="utf-8",some%20percent%20escaped%20literal%20val
>ue
>
>nuic> I think the above is a plausable way of carrying a literal which
>is a
>nuic> sequence of unicode chars.
>
>Yes - that is exactly what I thought it was good for, string literals.
>
>
>nuic>  I wonder whether there is any need to have a
>nuic> URI that represents the member of the type xsd:integer that has
>the
>nuic> numeric value 10, for example?
>
>It might be useful (and I agree that the above form would not be
>suitable)
>
>
>
>nuic>   http://www.w3.org/2004/SchemaSimpleTypes/Integer/value/12
>
>nuic>   http://www.w3.org/2004/SchemaSimpleTypes/Integer/lexical/012
>
>nuic>   http://www.w3.org/2004/SchemaSimpleTypes/Integer/12
>
>I agree those forms are much preferable, although I am sure someone will
>suggest that #12 is far preferable.
>
>
>nuic> I don't think you'd want to make quite that same assertion about:
>
>nuic>         data:text/plain;charset="utf-8",12
>
>nope. Although you might make an assertion
>
>data:text/plain;charset="utf-8",12
>isValidLexicalFormOf
>http://www.w3.org/2004/SchemaSimpleTypes/Integer/value/12
>
>nuic> I'm not pushing this 'URI for typed literals' idea, except to
>suggest that
>nuic> it's worth exploring.
>
>I think it is. Further, other types can be created that were not in
>W3C XML Schema, a benefit of using URIs for them.
>
>--
>  Chris Lilley                    mailto:chris@w3.org
>  Chair, W3C SVG Working Group
>  Member, W3C Technical Architecture Group

------------
Graham Klyne
For email:
http://www.ninebynine.org/#Contact

Received on Monday, 1 November 2004 09:31:58 UTC