On Thu, 20 Jul 2006 11:48:56 -0400, Xiaoshu Wang wrote: > What you said is not correct that "When RDF was invented it was > mostly intended to be used with URLs of the second group", Tim > Bernerds-Lee has long envisioned that URI is for everything.
Agreed, however I have observed that the emphasis shifted from the first days of pure RDF (around 1999) until now, where we have standards like OWL. > Again, please don't mix naming issue with implementation/management > issue. The URI specification specifically said that we should not > guess the nature of the resource from the surface representation of > the URI. Yes, that is the reason why I think we need a mechanism to clarify wheter we are pointing to something that can yield additional data/information via a resolution mechanism or not -- simply reading 'http://' at the start of the URI is not enough. > To figure out what a URI represents, you must "follow > your nose" to dereference the URI, or other URIs ensued. > The first group is adequately solved with a HTTP 303 for the non- > IR. The motivation for my proposal was that I think it is better to know which URIs are supposed to be resolvable before we are actually trying a HTTP GET or try to resolve something with the LSID system. In large datasets we have plenty of URIs -- if every agent would try to GET/resolve every URI that would pose quite a burden on the whole system (especially in the case of LSID). > The distinction between what you called group 2 and group 3 can > never be solved with a just a name. No one can promise that the > metadata of a data never change because in SW no one has the > complete knowledge about a resource. I should have been clearer, sorry. I was not talking about the metadata in an arbitrary context -- I was talking about the metadata we get back when we resolve the URI through a given mechanism. I implied that because the wiki-page deals with LSIDs, where this can be the case: we have a LSID URN and the LSID resolution system. If we send the LSID URN to the resolution system it returns associated information encoded in RDF. The distinction between "metadata that can change" and "metadata that does not change" does only make sense in that context. And it has practical repercussions (e.g. for caching). In the context of the whole world of the Semantic Web, of course, everyone can make any statement, and nobody has the authority to declare something immutable or static. > With regard to the resolvable ontology, I am not sure if its > intends. Is it to make claims about the URI or about the RESOURCE > that the URI represents? It makes a claim about wheter we should even try to start a resolution process with the URI we have got (can we expect to get something back or will it be futile? What kind of data will come back?). Nothing more. It does not make claims about the URI or any resource the URI might symbolize. But in either case, the problem > contradicts itself because: how how can someone and somehow get a > hold of a description in your proposed ontology at the first place? Well, it could be part of the ontology the user/agent is already posessing. It could also be part of the metadata yielded by a resolution process. Its not harder or easier than getting a hold of any kind of RDF triples. You start with something and try to go further. > But just as Godel's incomplete > therom has told us: don't try to use the same technology to define > the foundation of the technology. Doing so will only get more > questions than answers. As someone who has already invested some brain power in researching the brain, these sentences seem very discouraging to me ;) cheers, Matthias
