- From: Sean B. Palmer <sean@mysterylights.com>
- Date: Wed, 26 Sep 2001 17:25:38 +0100
- To: "Dan Brickley" <danbri@w3.org>, <Patrick.Stickler@nokia.com>
- Cc: <aswartz@upclink.com>, <gojomo@bitzi.com>, <www-rdf-interest@w3.org>
> And I'll merrily disagree with the pair of you. The cheapest > way to deal with this is as a textual property of the resource. Actually, that may be the most expensive way. As Al Gilman wrote earlier on uri@w3.org:- [[[ The point of URIs is that they creates a single non-colliding space for "references outside this context" which is not aware of what is a type, what is an instance, or much of anything else. ]]] - Al Gilman, Sent: Wednesday, September 26, 2001 1:51 PM Subject: Re: Excess URI schemes considered harmful I actually countered with an example that in certain contexts you don't need to identify the resources using a URI... you can use (for example) an RDF property! [[[ For example, RDF doesn't particularly need a URI scheme to identify media types, because it's much easier to just invent a predicate relationship between some node and a literal value, which is to the effect that the literal value is the unique MIME type for the subject. ]]] - Sean B. Palmer, Sent: Wednesday, September 26, 2001 4:35 PM Subject: Re: Excess URI schemes considered harmful But the Bitzi metadata structure may not be set up to store the bitprints explicitly as RDF literal values that can be unambiguously typed due to a well defined predicate relationship within a triple. In other words, if it uses something other than (er... as well as) RDF to store the bitprints, then it needs to come up with yet more architecture for typing them. The value of a URI scheme/URN namespace/content type is that you no longer need to add that mechanism, and hence in this context it may be a lot "cheaper" to do that than the RDF property based solution. Cheers, -- Kindest Regards, Sean B. Palmer @prefix : <http://webns.net/roughterms/> . :Sean :hasHomepage <http://purl.org/net/sbp/> .
Received on Wednesday, 26 September 2001 12:26:04 UTC