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

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.   There is no way to determine the  
meaning of an imports directive by looking  at the contents of
the imports  closure alone.  These I/O calls may behave  differently  
at different sites in different circumstances.

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.  Protege 4 uses  
this fact to access the TONES ontologies.  This seems
like a very useful feature of the language.

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.

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

But then it occurred to me that the XML Catalog could alternatively map

      http://purl.org/obo/owl/PATO to http://purl.org/obo/owl/quality

meaning that the statement

	X imports http://purl.org/obo/owl/PATO

will  import the ontology that has the name  http://purl.org/obo/owl/quality 
.  (There are no ontology versions in this case.)  This could be
used also to indicate current versions of ontologies

While I  am not sure if this matches the original intent of  the  XML  
Catalog, this could
conceivably be useful.

-Timothy



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. Even in this case, I think  
> that recommending this particular solution may be too strong.  
> Suggesting it should be OK though.
>
> Ian
>
>
>
>
> On 14 Feb 2009, at 00:56, Timothy Redmond wrote:
>
>>
>>
>> I am not very knowledgeable about XML catalogs but they do look  
>> like exactly the right thing.  In fact it looks like the suggestion  
>> goes beyond my original query.
>>
>> Without the recommendation though, different tools will probably  
>> end up using different solutions.  While not fatal this is awkward  
>> for sharing between different systems.  Even Protege 3 and Protege  
>> 4 have some of this awkwardness already.
>>
>> So if XML catalogs make sense I favor the recommendation.
>>
>> -Timothy
>>
>>
>>
>> On Feb 12, 2009, at 1:42 PM, Bijan Parsia wrote:
>>
>>> Sorry not to delve into to the emails (too much on my stack at the  
>>> moment), but I'm unclear why Protege adopting something like XML  
>>> Catalogs doesn't solve everything without changes to the current  
>>> spec. Indeed, forget "like", just use XML Catalogs.
>>>
>>> P4 could even export a catalog to a zipped directory which  
>>> maintains the mappings.
>>>
>>> I'd be happy with us recommending this, even.
>>>
>>> Cheers,
>>> Bijan.
>>
>>
>

Received on Monday, 16 February 2009 19:32:47 UTC