- From: Dave Viner <dviner@apache.org>
- Date: Thu, 24 Mar 2005 09:58:58 -0800
- To: <semantic-web@w3.org>
is this really a distinction between URI and URL ? here's a snippet from rfc 2396: A URI can be further classified as a locator, a name, or both. The term "Uniform Resource Locator" (URL) refers to the subset of URI that identify resources via a representation of their primary access mechanism (e.g., their network "location"), rather than identifying the resource by name or by some other attribute(s) of that resource. The Semantic Web (as far as I can tell) relies upon URI (identifier), which may or may not be a URL (network-retrievable thing). I think this is the root of the problem. Stephen originally asked for a way to convert a URI into a URL in order to obtain data or metadata about the thing to which the URI refers. Moreover, Stephen seems to echo the sentiments of Tim Berners-Lee, but extending these sentiments to the Semantic Web: "The Web works because, given an HTTP URI, one can in a large number of cases, get a representation of the document." http://www.w3.org/DesignIssues/HTTP-URI.html I don't have an answer to the problem, but I think the distinction between URI and URL is pretty important, and the confusion between the two has lead me into long nights of confusion. dave (I'm still reading thru the archives that someone else posted from the -----Original Message----- From: Benjamin Nowack [mailto:bnowack@appmosphere.com] Sent: Thursday, March 24, 2005 12:25 AM To: Max Voelkel Cc: semantic-web@w3.org Subject: Re: Not needed? Distributed URI Discovery On 23.03.2005 21:32:22, Max Voelkel wrote: > >>>At present, there is no formal, generalized mechanism whereby a Web Agent, >>>upon discovery of a URI, and lacking knowledge about that URI, can query the >>>Originator of the URI in order to obtain an RDF description of the URI. > >Lets compare URIs with symbols. When I discover a new term, I can not >ask the term, what it means. I ask a knowledge source (friends, books, >search engine) about it. >Why do we have to make things different on the web? When I find >a RDF document with URIs I don't know i just ignore them. When you come across an unknown non-web term, you ask a knowledge source. If you don't want to make things different on the web, you'll try to find a knowledge source for an unknown web term or resource URI as well, won't you? > If the RDF >document was well-written it should contain rdf:seeAlso links to URLs >of RDF-documents describingthe terms. Mights this be a solution? Yeah, but we don't have an RDF document. All we start with is a URI. The problem we discussed here was how to find this document containing the description of the resource denoted by the URI (in an efficient way), or how/where to serve this document in case you are the URI owner/publisher... Of course you can say that URIs are just labels and that noone should try to find out more about resources identified by URIs, but http-URIs have 95% of what is needed for automatic resource description discovery already built in, it seems to be worth the effort to find a solution for the remaining 5% in order to help the semantic web grow faster. (damn tricky 5%, ok ;) best, benjamin -- Benjamin Nowack Kruppstr. 100 45145 Essen, Germany http://www.bnode.org/ >It is inspired by the WWW approach of links and by the design >criterion of separation between identity (URI) and location (URL). I >think also "_:1 rdf:type foo:isCrawlable" or similiar would be >helpful. > >My conclusion is thus we need no index.rdf, no URI originator, no MGET etc. >__ Location is not identity. __ > > >Ok, what if somebody else adds statements about a URI? Well, then i >either need something like >a) a search engine = centralized infrastructure or >b) something like traceback = distributed, networked infrastructure > -> we need a standard for RDF-traceback-servers! > >I hope I inspired some people, > >Kind regards, > >Max >-- >University of Karlsruhe, AIFB, Knowledge Management Group >room #258, building 11.40 www.xam.de > >
Received on Thursday, 24 March 2005 18:00:38 UTC