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
Wed Nov 13 18:00:15 PST 2013


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

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


More information about the p4-feedback mailing list