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

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.


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


>
> > 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.
>
> All I can say is, I am sure glad I am not one your users.


Don't worry, I'm pretty sure you're not in our target customer demographic.


> And I also sincerely hope that you never get your hands on any OWL I might
> write, because God alone knows what it will then mean, apparently.
>

Sure, we might mangle it to the point where you no longer recognize it. But
we'll be doing so in a private sandbox, not publishing it out on the web
where everybody can see it and think you said the things we're putting in
your mouth.

-Alex



>
> Pat
>
> >
> > -Alex
> >
> >
> >
> > At the very least, if we mandate this, then we need to clarify the
> semantic role of "label" URIs in datasets.
> >
> > 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
> >
> >
> >
> >
> >
> >
> >
>
> ------------------------------------------------------------
> 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
>
>
>
>
>
>