Re: Defining subsets of existing OWL / RDF-S vocabularies in another vocabulary?

On Sep 28, 2007, at 7:19 AM, Richard Cyganiak wrote:

> But if you exchange data with the rest of the world, then you'll  
> have to keep in mind that some agents are web-aware, and will get  
> their definition of foaf:name from http://xmlns.com/foaf/0.1/name,  
> and not from your copy, regardless of whatever owl:imports you may  
> have declared.

An agent that is "web-aware" in such a way as to ignore owl:imports,  
and retrieve definitions of terms in an OWL ontology from the web  
would be in variance with the OWL specification. If something is to  
be fixed, it is the web agent. To build anything to conform to a  
buggy system is a corrupting influence on the web, vis browser  
hassles with ensuring compatibility with IE, bugs and all.

> If you really want to make sure that all agents encountering your  
> data work off the same vocabulary definitions, then you should  
> probably duplicate the relevant terms in your own namespace,  
> creating hepp:name and hepp:knows and so on, and declare them  
> owl:equivalentProperty to the original terms.

If you really want to make sure that all agents encountering your  
data work off the same vocabulary definitions, then you need to  
follow the specification. If we follow the specification, then web  
agents designers will appreciate  that it is worth learning what the  
specification says and we will all be better off. If not, we will  
compound the problem by doing what we think some undocumented web  
agent wants, because this will undoubtedly violate the undocumented  
assumptions of some other web agent not following the spec.

That said, it has been my practice to define, within my owl ontology,  
select terms from other ontologies, when I make an assessment that I  
am not changing the intended meaning of the term, and when importing  
the full ontology would have undesirable effects - for instance  
making my ontology OWL-Full, or when the source ontology has bugs  
that violate their own english definitions, or then the source  
ontology is too large to import for practical reasons. I'm not  
suggesting that this is the best idea - time will tell.

YMMV for RDFS, where the means of specifying how definitions are to  
be retrieved are, at best, loosely specified.

-Alan

>
> Best,
> Richard
>
>
>>
>> If that was okay, it would make it easier to prepare pre-composed  
>> blends of relevant ontologies that can be directly used for form- 
>> based instance data creation.
>>
>> However, I fear that defining an element that is residing in  
>> someone else's URI space is not okay, since I (e.g. http:// 
>> www.heppnetz.de) have no authority of defining the semantics of an  
>> element that is within
>> |http://xmlns.com/foaf/0.1/, even if I what I am saying is  
>> consistent with the authoritative definition of the given  
>> vocabulary element. |
>> ||
>> ||I am assuming that I duplicate the very same specification of  
>> the element, i.e., I would assure that my definition just  
>> replicates a subset of the official vocabulary. I also abstract  
>> from semantic dependencies, i.e., whether it is possible to  
>> specify a consistent subset of a given vocabulary (this may not be  
>> trivial for an expressive DL ontology, but should be feasible for  
>> lightweight RDF-S or OWL vocabularies). Also, the legal point of  
>> view (whether I am allowed to replicate an existing specification)  
>> is less relevant for me at the moment. I just want to know whether  
>> this is an acceptable practice from a Web Architecture perspective.
>>
>> Any feedback would be very much appreciated!
>>
>> Best
>>
>> Martin
>> -----------------------------------------------------
>>
>> martin hepp
>> e-mail: martin.hepp@deri.at
>> web:    http://www.heppnetz.de
>> skype:  mfhepp
>> office: +43 512 507 6465
>>
>> Check eClassOWL, the first real-world e-business ontology
>> for products and services in OWL at
>> http://www.heppnetz.de/eclassOWL
>>
>>
>>
>
>

Received on Saturday, 29 September 2007 21:33:37 UTC