W3C home > Mailing lists > Public > public-lod@w3.org > February 2012

Re: How do OBO ontologies work on the LOD?

From: Alan Ruttenberg <alanruttenberg@gmail.com>
Date: Thu, 23 Feb 2012 21:31:44 -0500
Message-ID: <CAFKQJ8=Jxy1g25b7Tz9cOH=sK9K1Z1Am3u5km-87x8NrnjG6gw@mail.gmail.com>
To: Peter DeVries <pete.devries@gmail.com>
Cc: public-lod@w3.org
On Thu, Feb 23, 2012 at 9:14 PM, Peter DeVries <pete.devries@gmail.com>wrote:

> Hi Alan,
> I am not against OBO.
> I am against people giving the impression that if it is an OBO ontology,
> it will work as expected by the LOD community.


> The basics are pretty simple. If you use a URI it should behave in a
> predictable way. (Vapour Validator)

Don't know vapour validator but will check it out later. I agree on the
principle. Did you receive my last message?

> OBO does not do this in the expected LOD way. This is fine as long as
> people don't give others the impression that it does.

Read my messages, please. OBO is not a unitary thing. Developers have
autonomy. There are bugs. We have only told people it is our intent to make
this work and have provided a service that works for those ontologies that
use it.

> I suspect there is a way for OBO to do this without some special "OBO"
> rule like their would have been with LSID's

Completely incomparable. LSIDs would have required that all clients have
new code to access the protocol. OBO ontologies that use ontobee or follow
our recommendations are accessible via http according to spec. Where there
are bugs they are being fixed.

This is very repetitive and I'm thinking "sheesh". But I won't let this
conversation end on misinformation.

> By this I mean each service has to support special logic that recognizes
> an OBO URI and handles it differently from all other URI's.


In a sense the http://purl.obolibrary.org/ service creates a URL mapping
> not unlike what I proposed earlier.

Nope. There is no "mapping". Our use of purls satisfies another desideratum
of the web, namely stable URIs. We have designed things so that we can
maintain service in the face of servers going down, or even purl.org going

> The problem is that even those mapped URI's do not work in the expected
> LOD way.

Gross overgeneralization. You've found one ontology with bugs in its

> This is the distinction that I am calling attention to.

I'm sorry, I maintain that the distinction you are trying to make is
misguided and factually incorrect.

> At this point in time it appears to be both a real difference and a
> significant difference.

At this point in time there appears to be a bug and some misunderstanding.

> Is this the only theoretical way to handle URI's?

Is what the only way?

> No, but if you intent is to create URI's for the LOD then they should
> behave in the expected LOD way.


> OBO seems to have all sorts of rules on how OBO ontologies should work,
> why can't the OBO people respect the LOD best practices when they are in
> LOD space?

Circles. Continued ascription to "OBO" verging on insult already.

> Or at least admit that there are differences in the way URI's are handled?

I've told you those aspects that I'm aware of that violate your
expectations. We don't do content negotiation, we just return RDF. HTML is
generated in the browser via a stylesheet. We will provide html at a
different URI (as it is a different resource) and link to it using

None of this translates into "differences in the way URIs are handled" as
far as I can tell from reading specifications. If LOD requires more than
what is generally expected from http and general semantic web principles
I'd be surprised.

I'm sorry we're disagreeing, and even more sorry that we are going in
circles on the list. Can we take further discussion of this offlist and
report back once we're confident we're talking about the same thing?

Received on Friday, 24 February 2012 02:32:42 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:29:57 UTC