RE: RDFCore Update

> The alternative often suggested is to pack datatypes into the values
> themselves (through various uri schemes). This seems to me more like a
> serialization solution than a datamodel solution. 

Well, this is really what is done by any system that employs weak
data typing. The data type is packaged up with the value rather than
prescribed for the container.

This is essential for handling complex multi-typed containers where
the range type of the container is an ancestor of the types
of actual values.

Consider a piece of fruit. One may define for a property something like 
'rdfs:range="#fruit"' and then one could assign various values having
types such as "#orange", "#banana", "#kiwi", etc., all of which are
sub-types of "#fruit" and an RDFS schema validator is happy with any
of them, because they are all valid "#fruit" values -- but nevertheless
you *still* have to inform the RDFS validator the exact type for each 
value. You can't derive it from the rdfs:range, as that is a general 
type, not the *actual* type -- and you need to know the actual type, as 
it can affect system behavior (one might do things with bananas that one 
would never do with pineapples ;-) and you wouldn't want to have to 
enumerate all the descendant types of "#fruit" as ranges, as that 
precludes flexible extensibility (the ability to define new types of fruit 
which are valid values for that property).

So, no matter how you go about it, you have to define type for each
value. The question really is how, and URI schemes seem to me to be 
the most efficient, portable, and consistent means to do that.

Maybe there is yet a better way. Let's hear suggestions. Though I agree
that qualified anonymous nodes is not the optimal way to do it (even
despite low memory prices ;-)

> Do we 
> really want to put
> the burden on applications of parsing uris to extract type 
> info and values?

Ideally, a class of such URI schemes would be identifiable and parsable
by an RDF capable system and such parsing would be less of a burden
as it could be done generically. This is why the "classical view" of
URI classes seems to me to be the correct one. If applications are
able to be made aware of the class of a given URI scheme, then they
can interpret URIs in meaningful ways. Just as there exists a defined
type of hierarchical URI form which has a consistent parsable structure
denoting a path, so too there could be a type of URV which has a
consistent parsable structure denoting the data type and value. Such
classificational knowledge about URIs would go along way towards being
able to genericize processing and thereby reduce implementational
burden on specific systems.

Since URI encoded literals are resources, one could also employ the
(unfortunately now deprecated) aboutEachPrefix to explicitly define
their type. I.e.

  <rdf:Description rdf:aboutEachPrefix="xyz:integer:">
     <rdf:type rdf:resource="xyz:integer"/>
  </rdf:Description>

Now, ideally, the URI scheme would be indentified natively by the
RDF parser and that knowledge would be enumerated for all values
encountered on input based on the generic operation 

     prefix("scheme:type:") -> type("scheme:type")

But the end result is the same.

--

An interesting question is: Are URI schemes or URN namespaces URIs? 
I.e. is 'http:' a URI? How about "urn:issn" or "urn:issn:"?   

Most RDF parsers I've tested (fortunately) seem to think they are... ;-)

Cheers,

Patrick

--
Patrick Stickler                      Phone:  +358 3 356 0209
Senior Research Scientist             Mobile: +358 50 483 9453
Nokia Research Center                 Fax:    +358 7180 35409
Visiokatu 1, 33720 Tampere, Finland   Email:  patrick.stickler@nokia.com

Received on Friday, 19 October 2001 11:07:02 UTC