- From: Pierre-Antoine CHAMPIN <champin@cpe.fr>
- Date: Mon, 22 Nov 1999 09:30:17 +0000
- To: Jonas Liljegren <jonas@paranormal.o.se>
- CC: RDF Intrest Group <www-rdf-interest@w3.org>
Jonas Liljegren wrote: > The semantic of the URI is not predefined. It could represent a thing, > not connected to the web. It could represent a person. In those cases, > the content of the URI is NOT the resource. That's very right. > But it would be nice if there was a standard as to the > intrepretation. In this way: > * If the URI is recognized as an retrievable document, the resource > IS that document. > * If the URI is not an retrievable document (an URL), it's abstract > for you. I guess it is a 'de facto' interpretation, to say that a resource you CAN'T retrieve is abstract for you (even if the resource might be retrievable in some other context). And if you can retrieve it, you can hopefully get a mime type. > Any given implementation will only support a subset of all the types > of URIs. It could know what types it can retrieve, what types > represent "the outside world", etc. But new types could be > invented. Previously unaccessible objects, like bar-code numbers, > could be made accessible by a new internet service, giving metadata > about the product. Yes, but you will never get the product ! The codebar URI can identify a product, since there is a one-to-one relation between them, but it can't dereference to the product itself, only to information about it. So I think the important thing is to make the difference between * URI we use to identify a piece of (meta)data (retrievable or not) * URI we use to identify a 'real' object, and which can perhaps be dereferenced to some metadata ABOUT that object. I guess this is application dependant : some application will be interested in the sociol security file of a person, so the SSN-schema URIs will be in the first category above ; some other could use the SN-schema to identid=fy persons, in which case these URIs will be in the second category. Hope this'll help Pierre-Antoine
Received on Monday, 22 November 1999 03:53:26 UTC