Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: URIs and Names on the Web
 > No, assuming I want to use Jena, how do I collect statements to much into > a Jena triple store? And assuming I've created a killer collection of > triples, how do I publish this for my friends? I do I _share_ this > information I've collected? Maybe this is different issue from using URNs in the triples, because there is no problem using URNs in all of the triples and publishing them over HTTP. But anyway, this is an important architectural question for a semantic web: "How do I publish, distribute, and query metadata?" > That is the fundamental problem with URNs: I can't easily publish them in > a way that allows people to find out about them -- well unless I resort to > HTTP, but then we would be using HTTP wouldn't we. Well that is the point: HTTP permits people to publish information that other people want to retrieve _based_on_publisher_. HTTP retrieval has strong affinity to publisher, and HTTP requests have strong affinity to publisher. Which query do you think will be most important for the semantic web: a) take me to a site that tells me one person's opinion about predicate/subject "X" b) tell me what people have said about resource "Y" with regards to predicate "X" c) tell me what people are saying about predicate/subject "X" This is the example I used earlier. Using an http: address to get information about a particular resource or predicate is kind of like calling up Universal Studios and asking them "Can you tell me if my people liked the movie?" It's much more reliable to just ask people you know(Instant Messaging), read the paper (trusted third-party web site), ask random people (newsgroups) etc. Using an http: identifier to identify something that is not a hypermedia server is only helpful in scenario "a", and scenario "a" doesn't have much to do with the semantic web, IMO. In fact, "a" really isn't that reliable even in the namespaces scenario. It's quite possible (and in fact common) that the documentation stored at the URL used as a namespace name is incorrect with respect to the actual schema being used in practice. Consider, for example, the novices who load up Visual Studio.NET and see that our sample schemas use http: identifiers as namespace names. They automatically assume that the namespace name should be the same as the absolute path to the XSD file, so it becomes very common for people to name their XSD schemas such that the targetNamespace URI and absolute path to the document are the same. At least when they *start* developing, they carefully copy their XSD to the absolute path specified as namespace URI. But, in my experience, people change their schemas quite frequently. And in practice, they usually *use* the schema by loading from a relative path, not an absolute URL path. So they can go many iterations of schema modification, with their application behaving *exactly* the way they want it to, but with the documentation at the absolute URL used as namespace name being out of date. I doubt that *any* XSD edit tools force the user to always have a current copy of the XSD mirrored at the URL used as namespace name. It is possible for a user with some expertise to semi-automate the process, but it's not going to be very trustworthy unless tools do it. So in any case where you are going to an http: URL to get some information about an XSD schema based on the namespace name, you are getting the opinion of one person (albeit, likely the person who first created the schema), and you know that the information could quite likely be out of date or incorrect. In other words, you never *depend* on the information. 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
