Re: ACTION-264: Discuss imports with Tim Redmond.

>>  It might be great for a particular tool but it seems like it  will  
>> depend on many assumptions that get in  the way of sharing  
>> ontologies.
> [snip]
>
> How so? XML Catalogs can be shared.

I now think I was wrong about this.  If it is ok, I will give some use  
cases and you can let me know what you think.

I have a collection of ontologies in svn.  Different members of the  
team with different tool sets check these ontologies out onto their  
hard drives.  They are all going to use different tools to access the  
ontologies so it is important to represent important information in a  
way that can be recognized by all the tools involved.

In order to resolve the import statements we use an XML Catalog.  This  
XML Catalog will have entries such as the following:
     <uri name="http://purl.org/obo/owl/PATO" uri="file:obofoundry/ 
quality.owl"/>
The "file:obofoundry/quality.owl" has to be relative because anything  
else would encode assumptions about a particular users environment.   
But an obvious rule would be to interpret relative URI's as relative  
to the location of the XML Catalog.

You also mentioned an XML Catalog in a zip file - I like this case.   
The following doesn't work
     <uri name="http://purl.org/obo/owl/PATO"  
uri="zip:file:ontologies.zip!obofoundry/quality.owl"/>
It is broken if the name of the zip file is changed.  But in the  
spirit of the relative URI above perhaps the following works fine
     <uri name="http://purl.org/obo/owl/PATO" uri="obofoundry/ 
quality.owl"/>.

If XML Catalogs are adopted by ontology tools, then we could imagine  
that these tools would also include a capability to automatically  
generate XML Catalogs in various situations.  For example, when  
gathering the imports closure from the web onto a directory, an  
ontology tool can keep track of
1. the ontology name/ontology version found by a given imports directive
2. the location on disk where the ontology with a given name and  
version is placed.
Once the downloads are complete, the tool can combine the information  
from 1 & 2 above to create an XML Catalog.  By keeping track of items  
1 and 2 separately, the tool can avoid downloading two separate files  
on disk with the same ontology name and version.  Specifically the two  
imports
	imports http://purl.org/obo/owl/quality
and
	imports http://purl.org/obo/owl/PATO
will generate a single owl file on disk.

Another upcoming use case for XML Catalogs might be ontology  
repositories.

>>
>>  These I/O calls may behave  differently at different sites in  
>> different circumstances.
>
> I don't get it.

So the most obvious case is the one where I am working offline but  
have the imports closure on disk.  In this case, if the import is not  
clear the tool will have to simply ask the user which is imported.

The other case that I see is when the ontologies live in agent or  
tomcat space.  Unless I run the customers application I will not be  
able to retrieve IRI's such as http://localhost:8080/...

>>>  Protege 4 uses this fact to access the TONES ontologies.
>>
>> I don't see how that works.

Actually I think that the TONES repository is arguably a case in favor  
of the XML Catalog.  Instead of having a trivial but custom web  
service (http://owl.cs.manchester.ac.uk/repository/list) that Protege  
4 understands, the TONES repository could export an XML Catalog.  This  
is a simple and more general approach. It would also have a better  
chance of working with arbitrary tools out of the box.

>> This fact has been exploited  by the owl api.  It  makes sharing of  
>> ontologies easier because the meaning of imports can be
>> determined even  if the IO operations cannot succeed.
>
> How? If you don't have the imported ontology, you don't.

With import by name, one can determine which imported ontologies can  
be found in a directory.  If the imports statement says

	X imports Y

then I can look for ontologies with the name Y in the directory.  If  
it isn't there then obviously the tool either must go to the internet  
or the user must get involved.

>>  This seems
>> like a very useful feature of the language.
>
> In my experience it was a bane :)

Not sure what you mean.  But the one case where import by name does  
not work well is the case where the ontology cannot be found by its  
name.  This puts the user in the awkward position of having to choose  
between having a broken import which allows tools to find the ontology  
or having a good import which does not resolve to the ontology.  Is  
this the bane that you are referring to?

-Timothy


On Feb 17, 2009, at 2:22 AM, Bijan Parsia wrote:

> Ok, I still don't understand.
>
> On 16 Feb 2009, at 19:31, Timothy Redmond wrote:
>
>> I wanted to make a further clarification.  I am not particularly  
>> worried  about  the data structures that ontology tools use to
>> guide the IO redirection for imports.  What  I don't like is the  
>> fact that in OWL 2.0, the meaning of an  imports statements  can
>> only be resolved through I/O calls.
>
> How are these not related?
>
>>  There is no way to determine the meaning of an imports directive  
>> by looking  at the contents of
>> the imports  closure alone.
>
> I would have thought that an imports closure is a post-parsing  
> concept, thus you, in fact, can determine the meaning, since IO  
> calls have been resolved.
>
>>  These I/O calls may behave  differently at different sites in  
>> different circumstances.
>
> I don't get it.
>
>> In contrast, according to the direct semantics, in OWL 1.0, the  
>> imports statement has a meaning  based on the contents of the  
>> ontologies.
>> If I go to the OWL 1.0 direct semantics document and search for  
>> imports, I find the following statement:
>>
>>> Aside from this local meaning, an owl:imports annotation also  
>>> imports the contents of another OWL ontology into the current  
>>> ontology. The imported ontology is the one, if any, that has as  
>>> name the argument of the imports construct. (This treatment of  
>>> imports is divorced from Web issues. The intended use of names for  
>>> OWL ontologies is to make the name be the location of the ontology  
>>> on the Web, but this is outside of this formal treatment.)
>>
>> This fact has been exploited  by the owl api.  It  makes sharing of  
>> ontologies easier because the meaning of imports can be
>> determined even  if the IO operations cannot succeed.
>
> How? If you don't have the imported ontology, you don't.
>
>>  Protege 4 uses this fact to access the TONES ontologies.
>
> I don't see how that works.
>
>>  This seems
>> like a very useful feature of the language.
>
> In my experience it was a bane :)
>
>> In OWL 2.0, the imports statement is not mentioned in the direct  
>> semantics.  I think that this is because  the meaning of the imports
>> statement is divorced from the contents of the ontologies.
>
> I don't understand.
>
>> On Feb 16, 2009, at 5:43 AM, Ian Horrocks wrote:
>>> Just to be clear, I assume we are talking about recommendation in  
>>> the usual sense and not in the W3C sense.
>>
>> Yes - I think I agree.
>>
>>> Even in this case, I think that recommending this particular  
>>> solution may be too strong. Suggesting it should be OK though.
>>
>> I am  still looking at exactly what is being suggested here.  My  
>> first reaction, after looking at the XML catalog documents, was  
>> that the
>> idea was to map the iri being imported to the location of the  
>> imported ontology in a repository.
>
> For example.
>
>> Thus for the imports statement
>>
>> 	X imports http://purl.org/obo/owl/PATO
>>
>> the XML  Catalog would map
>>
>> 	http://purl.org/obo/owl/PATO to file:./quality.owl
>>
>> where quality.owl is the location of the Phenotypic quality  
>> ontology on disk.  As I thought about it, I am  not sure that this  
>> would be particularly
>> useful.
>
> Really? It seems to solve most problems.
>
>>  It might be great for a particular tool but it seems like it  will  
>> depend on many assumptions that get in  the way of sharing  
>> ontologies.
> [snip]
>
> How so? XML Catalogs can be shared.
>
> Cheers,
> Bijan.
>

Received on Tuesday, 17 February 2009 19:07:03 UTC