[sc34wg3] Questions on N0396: (16) locators
Thu, 24 Apr 2003 10:00:44 +0200
I agree with you. OTH, I don't fully understand how
you think topic maps should address the URI issue.
- silently ignore everything about HTTP indirection
and URI names vs. URI addresses
- explicitly state that TMs understand locators to
address information resources, leaving the burdon to
cope with the underlying system's specialties to the
- recognize (as N0396 does) the idea that locators can
be used as names for abstract concepts and give the
hint not to use them as subject addresses
What do others think.
Murray Altheim wrote:
> Lars Marius Garshol wrote:
> > * Jan Algermissen
> > |
> > | N0396 says in 3.1:
> > |
> > | "A locator is a string that references one or more information resources"
> > |
> > | The note at the end of 3.4.5 says:
> > |
> > | "Locators which refer directly to subjects which are not information
> > | resources must be used with caution. They should not be used in the
> > | [subject addresses] property, as this is intended only for references
> > | to information resources. Rather, they should be placed in the
> > | [subject identifiers] property."
> > |
> > | The two statements contradict each other.
> > They do, though I would perhaps rather say that the note expands on
> > the definition. It turns out that whether we want it or not there are
> > URIs that do not reference information resources.
> > | I strongly advice us NOT to try any 'fixups' towards
> > | interoperability with RDF. I think that topic maps are far better of
> > | if they stick to the idea that "a URI allways refers to the
> > | information resource that (might) be returned by an HTTP GET. There
> > | are no locators that refer to abstract concepts." Anything else is
> > | introducing evil, IMHO.
> > The trouble is that URIs were defined by the IETF and we can't change
> > them. It's a fact of life that there are quite a few URI schemes that
> > do not reference information resources and there's not a whole lot we
> > can do about it. It's impossible to outlaw them in any meaningful way,
> > and to pretend that the problem does not exist is the worst we can do.
> > Note that there are many other kinds of URIs than just "http://" ones.
> > We can't disallow ftp, nntp, gopher, news, mailto, ... URIs, nor the
> > more dubious ones like urn:isbn:..., tdb:..., and so on.
> > This is SAM issue locator-reference, BTW:
> > <URL: http://www.ontopia.net/omnigator/models/topic_complete.jsp?tm=tm-standards.xtm&id=locator-reference >
> Honestly, I haven't been following this discussion all that closely,
> but it sounds very much like you're trying to solve all the world's
> problems, which is a problem in itself. This is like trying to figure
> out what to do with edge cases like URI references that are empty
> strings. Yes, they exist. No, the SAM doesn't have to answer all of
> the possible questions on all the existing muck that's been created
> in the past ten or twenty years. Perhaps a horse blinder approach,
> a tighter scope?
> Dunno, it just seems like a Sisyphean task in front of you, and I
> can't think of too many specs that attempt it. Put it another way,
> within the W3C they've spent many *thousands* of hours arguing over
> what URIs are and what they mean and what they taste like fried up
> in butter. It's not worth the pain, really.
> Murray Altheim http://kmi.open.ac.uk/people/murray/
> Knowledge Media Institute
> The Open University, Milton Keynes, Bucks, MK7 6AA, UK .
> Moonlight slanting
> through all the
> bamboo forest...
> and nightingale song
> -- Basho
> sc34wg3 mailing list
Jan Algermissen http://www.topicmapping.com
Consultant & Programmer http://www.gooseworks.org