Search Mailing List Archives


Limit search to: Subject & Body Subject Author
Sort by: Reverse Sort
Limit to: All This Week Last Week This Month Last Month
Select Date Range     through    

[p4-feedback] strange effects of the order of Prefix statements

Timothy Redmond tredmond at stanford.edu
Thu Nov 14 09:38:49 PST 2013


You missed my quote of the OWL 2 specifications where it says that 
prefix names should not be repeated in the prefix declarations in a 
single ontology.

> Moreover, Protege does not find the ontology to be invalid, regardless 
> of the order of the Prefix statements.

The OWL api is somewhat forgiving about malformed ontologies.  I believe 
that it shouldn't be so forgiving because this has generated a certain 
amount of misery in the community (mine as well).  But that is a matter 
of debate.

I think that the repeated prefix names probably explains your problems 
because I am guessing that your ontology gets parsed differently 
depending on which prefix is accepted by the OWL api. I am guessing that 
some of the names in your ontology are ambiguous.  I would have to see 
your ontology to give concrete examples.

-Timothy.




On 11/14/2013 05:24 AM, Tom Kramer wrote:
> Hello Timothy -
>
> I believe that this is valid OWL. The production in the OWL 2 syntax 
> document (http://www.w3.org/TR/owl2-syntax) for a prefixDeclarati||on is
>
> prefixDeclaration := 'Prefix' '(' prefixName '=' fullIRI ')'
>
> where prefixName matches the production for PNAME_NS of SPARQL
>
> and the production for PNAME_NC in SPARQL  
> (http://www.w3.org/TR/2008/REC-rdf-sparql-query-20080115) is
>
> PN_PREFIX? ':'
>
> which indicates that the PN_PREFIX (a constrained sequence of 
> characters with at least one character) is optional.
>
> Moreover, Protege does not find the ontology to be invalid, regardless 
> of the order of the Prefix statements. It just behaves differently in 
> displaying the class hierarchy when the order is changed. Since all 
> the names of the classes are different (without any prefix), changing 
> the order of the Prefix declarations should have no effect. Each name 
> occurs in only one included ontology.
>
> My guess would be that the explanation lies in some obscure corner of 
> the Protege source code and that the behavior is a side effect of 
> coding, not intentional.
>
> Tom Kramer
>
> On 11/13/2013 09:00 PM, Timothy Redmond wrote:
>>
>>> ***********************************************************************
>>> Prefix(:=<http://www.nist.gov/el/ontologies/geometryInstances2.owl#>)
>>> Prefix(:=<http://www.nist.gov/el/ontologies/topTypeClasses.owl#>)
>>> Prefix(:=<http://www.nist.gov/el/ontologies/mostTypesClasses.owl#>)
>>>
>>> Ontology(<http://www.nist.gov/el/ontologies/geometryInstances2.owl>
>>> Import(<file:topTypeClasses.owl>)
>>>
>>> ************************************************************************
>>
>> So the short answer is that this is not valid owl 2.  The OWL 2 
>> syntax document says this about prefixes:
>>
>>> Each part of the ontology document matching the prefixDeclaration 
>>> production declares a prefix name and associates it with a prefix 
>>> IRI. An ontology document /MUST/ contain at most one such 
>>> declaration per prefix name, and it /MUST NOT/ declare a prefix name 
>>> listed in Table 2.
>>
>> If I am understanding this situation then, in my opinion, the owl api 
>> should fail to parse this ontology.    It is possible - it depends on 
>> how your ontology is serialized - that this issue may mean that the 
>> content of your ontology will be non-deterministically parsed because 
>> the full name of an entity will depend on the order of the prefix 
>> declarations.
>>
>> My suggestion would be to use different prefix names in the prefix 
>> declarations above.
>>
>> -Timothy
>>
>>
>>
>> On 11/13/2013 02:54 PM, Tom Kramer wrote:
>>> Hello Protege Support -
>>>
>>> I have built a few related sets of OWL files (using OWL 
>>> functional-style syntax) in which one ontology file *include*s 
>>> another. I build them outside of Protege and then use Protege to 
>>> check them. I find that for Protege to produce the results I expect, 
>>> it is necessary to have a *Prefix* statement for each ontology that 
>>> is directly or indirectly *include*d. That seems slightly odd to me, 
>>> since *include* statements are needed only for directly *include*d 
>>> ontologies. But I can live with that.
>>>
>>> What seems unreasonable is that the order in which *Prefix* 
>>> statments are given is significant. As long as the including 
>>> ontology *Prefix* is given before the included ontology *Prefix*, I 
>>> get the results I expect, but if the order is switched, the "class 
>>> hierarchy" tab in Protege lists most classes twice.
>>>
>>> I find nothing about the order of Prefix declarations in 
>>> http://www.w3.org/TR/owl2-syntax/ or in
>>> http://protegewiki.stanford.edu/wiki/Protege4NamingAndRendering#Prefixes...
>>> Googling "protege prefix order" produced nothing useful.
>>>
>>> Here is a snippet from the geometryInstances2.owl file.
>>>
>>> ***********************************************************************
>>> Prefix(:=<http://www.nist.gov/el/ontologies/geometryInstances2.owl#>)
>>> Prefix(:=<http://www.nist.gov/el/ontologies/topTypeClasses.owl#>)
>>> Prefix(:=<http://www.nist.gov/el/ontologies/mostTypesClasses.owl#>)
>>>
>>> Ontology(<http://www.nist.gov/el/ontologies/geometryInstances2.owl>
>>> Import(<file:topTypeClasses.owl>)
>>>
>>> ************************************************************************
>>>
>>> The geometryInstances2.owl ontology includes topTypeClasses.owl, 
>>> which includes mostTypesClasses.owl. These are very simple 
>>> ontologies. All told, there are 6 classes. Each class is defined in 
>>> only one file.
>>>
>>> When the *Prefix* statements are in the order shown above, Protege 
>>> produces the class hierarchy diagram I expect; each class appears 
>>> once. If the order of the last two *Prefix* statements is switched, 
>>> Protege produces a class hierarchy diagram in which most classes 
>>> appear twice.
>>>
>>> Is this a Protege feature or a Protege bug? If it is a feature, what 
>>> does it do that is useful? If it is a bug, please fix it.
>>>
>>> Thanks. I will be happy to send you the files, if that would be helpful.
>>>
>>> Tom Kramer
>>>
>>>
>>> _______________________________________________
>>> p4-feedback mailing list
>>> p4-feedback at lists.stanford.edu
>>> https://mailman.stanford.edu/mailman/listinfo/p4-feedback
>>
>>
>>
>> _______________________________________________
>> p4-feedback mailing list
>> p4-feedback at lists.stanford.edu
>> https://mailman.stanford.edu/mailman/listinfo/p4-feedback
>
>
>
> _______________________________________________
> p4-feedback mailing list
> p4-feedback at lists.stanford.edu
> https://mailman.stanford.edu/mailman/listinfo/p4-feedback

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.stanford.edu/pipermail/p4-feedback/attachments/20131114/561f3871/attachment.html>


More information about the p4-feedback mailing list