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

On Thu, 2012-03-01 at 10:24 -0500, Lee Feigenbaum wrote:
> On 3/1/2012 10:10 AM, Alex Hall wrote:
> > On Thu, Mar 1, 2012 at 2:22 AM, Pat Hayes <phayes@ihmc.us
> > <mailto:phayes@ihmc.us>> 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.
> 
> FWIW, we do basically the same thing. Import an ontology from uri U. It 
> gets stored in our quad store in named graph U. Subsequent look ups for 
> U go against the quad store, as long as that named graph exists. You can 
> use our ontology editor to make changes to the ontology U (whatever 
> changes -- add/remove properties, change semantics, whatever), at which 
> point it would still be in named graph U, but would be out-of-sync (and 
> potentially inconsistent with) with whatever is still being served on 
> the Web at URI U. (Of course, that can happen without making any changes 
> locally, if changes are made at U.)
> 
> It's a cache, but not a read-only cache. We don't do anything to prevent 
> users from making whatever changes they want to the local copy of the 
> ontology.
> 
> (Same with any other RDF imported into Anzo from the Web, for that matter.)

An alternative design would be to store the fetched graph with one genid
tag and, when someone wants to modify it, copy it to another genid tag
and modify it there.   And somewhere keep the metadata of which tags are
associated which with URLs, and what their cache status is.   

How would you feel about that?   Completely needless complexity, or just
something you haven't found a strong enough need for, yet?

(It seems to me like with the current design people could definitely get
into trouble with lost updates and other synchronization problems, once
they start to have multiple people working on the same data.)

   -- Sandro

> Lee
> 
> 
> 
> >
> >
> >      > > 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.
> >
> > -Alex
> >
> >
> >      > 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 <tel:%28850%29434%208903> or (650)494 3973
> >     <tel:%28650%29494%203973>
> >     40 South Alcaniz St. (850)202 4416 <tel:%28850%29202%204416>   office
> >     Pensacola (850)202 4440 <tel:%28850%29202%204440>   fax
> >     FL 32502 (850)291 0667 <tel:%28850%29291%200667>   mobile
> >     phayesAT-SIGNihmc.us http://www.ihmc.us/users/phayes
> >
> >
> >
> >
> >
> >
> 
>

Received on Wednesday, 7 March 2012 03:15:02 UTC