[sc34wg3] Questions on N0396: (16) locators

[Jan Algermissen]

Murray,

I agree with you. OTH, I don't fully understand how
you think topic maps should address the URI issue.

Should we


- 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
  user/application programmer

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


Jan

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
> 
> ......................................................................
> 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
> sc34wg3@isotopicmaps.org
> http://www.isotopicmaps.org/mailman/listinfo/sc34wg3

-- 
Jan Algermissen                           http://www.topicmapping.com
Consultant & Programmer	                  http://www.gooseworks.org