W3C home > Mailing lists > Public > semantic-web@w3.org > August 2007

Re: Datatypes

From: Reto Bachmann-Gmür <reto@gmuer.ch>
Date: Wed, 22 Aug 2007 09:25:33 +0200
Message-ID: <46CBE4ED.9050009@gmuer.ch>
To: Garret Wilson <garret@globalmentor.com>
CC: semantic-web@w3.org
Garret Wilson wrote:
> Reto Bachmann-Gmür wrote:
>> - fully qualified java-class names (eg: "org.example.tools.MyTool")
>> While I could use xsd:string I think it would be better to use custom
>> datatypes to have literals like
>> "org.example.tools.MyTool"^^http://example.org/datatypes#javaClass.
> My opinion (see my earlier rants against RDF literals on this list):
> for Java classes shun literals and use URIs. For Java classes, use the
> "java" URI scheme. That's what I do. No, it's not official, but I
> would argue that it's more standardized than an any RDF Java class
> datatype out there. It makes sense. It was even listed on
> http://www.w3.org/Addressing/schemes.html at one time.
I wouldn't say that something is more standardized just because its used
by more people, creating a uri-scheme involves registration with iana,
as the space for scheme's is much more limited than the URI-space used
for datatypes.

But the question to me seems to be whether the thing is a name or
something mapping to a value. If we follow the URI approach and say that
the uri-scheme denotes exclusively Resources of type ex:JavaClass I
could set the range of my ex:javaImplementation property to ex:JavaClass
this would allow any resource with a URI of the java-scheme to be its
object, but it would also allow resources with URIs from other schemes
to be used, e.g. an HTTP-URI (as long as the server returns a 303).
Having a datatype-property with java-class-name as range is much more

Another issue is the identity of the nodes, the unique-name constraint
of java-classes can be expressed with an identity constraint definition
on the datatypes but I can't think of any way to tell an RDF or OWL
processor that a resource may not have two different URIs of the


Received on Wednesday, 22 August 2007 07:25:45 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 08:45:02 UTC