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

On Feb 29, 2012, at 4:38 PM, Alex Hall wrote:

> On Wed, Feb 29, 2012 at 5:01 PM, Pat Hayes <phayes@ihmc.us> wrote:
> 
> On Feb 29, 2012, at 9:44 AM, Alex Hall wrote:
> 
> > On Wed, Feb 29, 2012 at 10:27 AM, Pat Hayes <phayes@ihmc.us> wrote:
> >
> > On Feb 29, 2012, at 8:43 AM, Antoine Zimmermann wrote:
> >
> > > *Beware*: this is about design solutions using the dataset proposal as a whole. It is not strictly related to the semantics. It explains concretely how one could store things in a dataset, possibly entail new things according the dataset semantics of [2] and so on, such that eventually it addresses the use case. So it contains a number of things that applications should do to address the UCs, independently of the truth values of triples or "named" graphs.
> > >
> > >
> > > UC 1.5: Exchanging the contents of RDF stores
> > >
> > > This is trivial. RDF stores mostly implement SPARQL datasets, so it suffices to have a serialisation syntax for datasets. It does not matter what the semantics is. TriG or N-Qauds will do.
> > >
> > >
> > > UC 5.2: OWL's “Ontology Documents”
> > >
> > > Currently, OWL imports statement means that an OWL processor should fetch wathever document it founds when "accessing" the imported URI (using whatever protocol it needs, see [1]). This behaviour is independent of the formal semantics of OWL ontologies. It's an operation that must be done prior to any interpretation of the ontology.
> > >
> > > If multiple ontologies are stored in a dataset, it seems reasonable to use the import mechanism offline, where instead of a HTTP lookup, the system directly fetches from the corresponding "named" graph.
> >
> > Whoa. I dont think this is at all reasonable. This changes the meaning of owl:imports, in effect (or extends it in a new way). After all, the URIs used as labels in a datastore might *refer* to anything, and in particular, they might refer to a different ontology stored somewhere on the web identified by an http URI. So the meaning of an imports might change when the ontology containing it is put into a dataset and taken offline.
> >
> > Scruffy implementer hat on... This is more or less what our ontology management product (Knoodl) already does. If you load an ontology that owl:imports some http URI, we don't go out and fetch the document from that URI. Instead we ask you to map
> 
> Ask who to map? The OWL ontology might be out on the Web somewhere. You can't ask an OWL ontology document to do anything.
> 
> Ask the user to map, by presenting them a dialog box asking them to tell us where the ontology is stored locally that is identified by the URI that is the subject of the owl:imports statement.
>  
> 
> > that URI to some ontology stored locally in Knoodl.
> 
> And does this locally stored ontology have any relationship at all to the one that the writers of the OWL had in mind? Or do you make up your own? (I am finding it hard to believe that I am having this conversation.)
> 
> 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.)

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

> 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
phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes

Received on Thursday, 1 March 2012 07:23:20 UTC