RE: [xml-dev] URIs and Names on the Web

["Joshua Allen" <joshuaa@microsoft.com>]

> 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.