Re: Use cases wrt Dataset proposal (UC 1.5, UC 5.2)

On Thu, Mar 1, 2012 at 2:22 AM, Pat Hayes <> wrote:

> > It's certainly intended that the locally stored ontology is the same as
> what the writer of the OWL had in mind. But it's certainly possible to use
> a completely different document, and I understand how you find this state
> of affairs objectionable. In practice, the person importing the OWL into
> our tool is usually the same person who wrote it, so it's often a moot
> point.
> Ah, I see. OK, I understand better now. So this amounts to a kind of local
> caching, right? (You seemed to be saying something much crazier, sorry I
> misunderstood.)

That's exactly what this amounts to. Sorry if I didn't make that clearer in
my original email.

> > > So we keep a mapping off to the side of imported ontology URI to local
> graph label, and use that for an offline import mechanism whenever you
> access an ontology that has an import.
> > >
> > > There always seemed to be something vague and hand-wavy about how
> owl:imports was defined (especially in OWL 1)
> >
> > It was left in OWL 1 to what might be called Web common sense, but there
> was a clear understanding that it was intended to be based on HTTP URIs and
> the general Web machinery. The OWL 1 spec never got round to formally
> specifying HTTP, that being before the http-range-14 battleground, but I
> dont think anyone thought that there was any doubt that the relationship
> between URIs and OWL ontologies was supposed to be mediated by Web data
> transfer protocols, not left to some arbitrary proprietary mechanism.
> >
> > Understood. One enhancement we could certainly make is to offer to go
> fetch the ontology document for you when we find you're importing an
> ontology with an HTTP URI, though we don't do that right now.
> >
> > However, once we locate the ontology being imported, there are lots of
> good reasons to store a copy of it locally.
> Oh sure, no problem with that. But this also applies to browsers and web
> pages, its a general issue in Web access (right?).

Sure, it's by no means a new or unique problem. But I think OWL does
introduce some twists by layering semantics on top of a web access
mechanism (albeit indirectly). It brings up questions along the lines of,
what exactly is identified by the imported ontology URI? Is it a graph or
an ontology or maybe both? Is it a graph that serializes an ontology? I
think OWL says it's an "ontology document" but I'm not sure how that
relates to the ontology itself.  If two slightly different RDF documents
describe the same ontology (or equivalent ontologies) then is it OK to
identify them with the same URI?

In this particular case the answers to these questions aren't really
important because it falls in the category of the specs not telling people
what to do internally in their own applications. But it would be nice if we
had a coherent story to tell here, and I fear that's not the case right now.


> > Performance is the most obvious, but perhaps you've found a bug in the
> ontology being imported. Also, our users don't like things changing out
> from under their feet as things are liable to do when you pull stuff off
> the web, because then whatever application is built on top of that ontology
> breaks.
> Point taken. And there is a widespread assumption that imported ontologies
> are likely to be pretty stable, as Web information resources go.
> > > so we didn't give much thought to the underlying semantics. It would
> be great if, once the semantics of datasets and graph URIs/labels are
> formalized, it supports this use. In the end, it works and it seems to keep
> our users happy.
> >
> I apologize for the tone of the remaining comments. I should not respond
> to emails just after a telecon and before lunch.
> Pat
> ------------------------------------------------------------
> IHMC                                     (850)434 8903 or (650)494 3973
> 40 South Alcaniz St.           (850)202 4416   office
> Pensacola                            (850)202 4440   fax
> FL 32502                              (850)291 0667   mobile

Received on Thursday, 1 March 2012 15:10:55 UTC