RE: RDF for molecules, using InChI

> From: Chimezie Ogbuji
> [ . . . ]
> Well, it's one thing to be neutral wrt schemes and another to
> make a statement about the use of certain schemes (HTTP) as
> preferred for authors who are in the business of minting URIs.
> I'll just echo Michel's sentiments about not alienating
> communities and focusing on a clear definition of the problem
> statement.

I certainly hope that communities do not feel alienated by this
discussion, but somehow awareness needs to be raised, because there are
some major misconceptions, and I don't know how to dispell them without
pointing out specifically why nearly all of the supposed benefits of
non-HTTP URIs are based on faulty assumptions.

> > From: Alan Ruttenberg
> > If you consider LSIDs without resolution then I don't think
> > they have any value over any other URI scheme. They are
> > simply strings and any old scheme will do.
>
> Not necessarily true. Consider schemes which have a specific
> (and useful) formal semantics for parts of their strings. The
> tag
> [1] scheme
> incorporates a date component and a mechanism to guarantee
> uniqueness while minting tag-based URIs. The LSID scheme has
> specific portions of the string for revision. These are all
> parts of the URI that the author has to contend with rather
> than begin with a clean slate for an arbitrary string with a
> naming convention picked by the author.

But HTTP URIs can do *exactly* the same thing, as pointed out in
http://dbooth.org/2006/urn2http/

> < [ . . . ]
> > I think follow-your-nose is unworkable for the sort of work
> > we mostly do,
>
> Precisely! 

I stronly disagree that follow-your-nose is unworkable.  It may be
*insufficient* for some purposes though.  

> In fact I was going to lay out an example where the
> restriction of working within an enterprise network severely
> reduces the argument for minting HTTP URIs for terms coined by
> employees within that enterprise who do not have control over
> their webspace. So, follow-your-nose (which strikes me as one
> of the primary arguments for HTTP scheme monopoly) works for
> the open web but not the 'enterprise' web.

Can you be more specific about this example?  Are you saying that the
employees cannot control how their URIs are minted?  Do they wish to
share these URIs with others outside the enterprise?  

>
> > but because of the rest of web usage, we have thus far
> > considered it a goal to enable the sort of discovery that it
> > commonly expected. Personally, I consider it a matter of
> > courtesy to give people a way to find out more.
>
> Right, but direct URI dereference of terms is *one* such way to
> extend that courtesy. I've argued (long ago) that this is not
> necessarily the most effective way if 'finding out more' is
> meant to lead to inference.

Right, but giving people the option of "follow-your-nose" does not
prevent them from using other mechanisms also.  It's like always
supporing the web-friendly common denominator, but allowing more
sophisticated users to also use something more powerful.

> [ . . . ]
> > I'm still waiting for an example that *can't* be solved using
> > a HTTP scheme. Do you have any?
>
> The HTTP scheme:
>
> http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?"
> query ]]
>
> Does not have any formal components for identify management
> (dates and versions). 

Right, but the URI owner (or delegate) can overlay those formal
components on the basic http_URL syntax if desired, as described in
http://dbooth.org/2006/urn2http/

> A person (or group) who may not have
> control over webspace but has a coherent theory they wish to
> express in OWL will probably find these aspects of the tag (and
> lsid) schemes useful for guiding their naming convention rather
> than inventing one (with perhaps a bogus authority - such as
> 'example.com').

Can you be more specific?  It may help if we can make this more
concrete.

>
> One could suggest a best practice for minting HTTP URIs which
> takes into account provenance dates and revision, however there
> are URI schemes that already have a well defined structure for
> representing such things. It would be more productive (IMHO) to
> review where alternative schemes get this right, how this may
> be replicated in HTTP (consider W3C specification URIs) - i.e.,
> clarify the problem statement rather than proposing *a*
> solution (perhaps out of context).

I agree that it's useful to understand the contributions of other URI
schemes.  But I think a major misconception is in assuming that they
need to be discarded or reinvented in order to use the HTTP scheme.  For
example, the technique described in
http://dbooth.org/2006/urn2http/
completely reuses the conventions of the URI scheme that is being
converted to the HTTP scheme.  It builds on top of it.


David Booth, Ph.D.
HP Software
+1 617 629 8881 office  |  dbooth@hp.com
http://www.hp.com/go/software

Opinions expressed herein are those of the author and do not represent
the official views of HP unless explicitly stated otherwise.

Received on Tuesday, 7 August 2007 18:25:56 UTC