Re: Semantic E-mail

Laurian Gridinoc wrote:

>On Thu, 15 Jul 2004 11:34:16 +0200, Danny Ayers <danny666@virgilio.it> wrote:
>  
>
>>> [snip]
>>
>>If the other terms really are equivalent then you could use
>>owl:equivalentProperty, but then why bother creating a new term when you
>>could use an equivalent?
>>    
>>
>
>"Property equivalence is not the same as property equality.
>Equivalent properties have the same "values" (i.e., the same property
>extension), but may have different intensional meaning (i.e., denote
>different concepts). Property equality should be expressed with the
>owl:sameAs construct. As this requires that properties are treated as
>individuals, such axioms are only allowed in OWL Full." [1]
>
>This is what I'm trying to avoid - OWL Full.
>  
>

Then don't use owl:sameAs.

This doesn't prevent you from using an existing equivalent or 
owl:equivalentProperty.

Look at some individuals:

{1}
m1 filsa:messageid "Message One"
m2 filsa:messageid "Message Two"
m3 filsa:messageid "Message Three"

if you said

{2}
new:messageId owl:equivalentProperty filsa:messageid

then you could infer -

{3}
m1 new:messageId "Message One"
m2 new:messageId "Message Two"
m3 new:messageId "Message Three"

btw, I suspect the actually aspect of owl:sameAs you'd be using in 
practice is the above,  the result of the entailment:

p1 rdf:type rdf:Property
p2 rdf:type rdf:Property
p1 owl:sameAs p2
=>
p1 owl:equivalentProperty p2


Anyhow, if there wasn't a one-to-one match between the sets of 
individuals, then you could say:

{4}
new:messageId rdfs:subPropertyOf filsa:messageid

but then you couldn't infer {3} from {1}, although you could infer {1} 
from {3}

you could swap it around, so new:messageId was the more general 
property, but it depends on what the semantics actually are, what you're 
trying to capture...

>I would prefer to stay with the most simple solution - RDF(S), worst
>case lightest OWL possible; but Josh Sled pointed that owl:sameAs
>applied to classes or properties is OWL Full.
>  
>

Those are really conflicting requirements - if you want to stay within 
OWL DL then you will need more qualification of the properties to which 
you refer. The simplest you could possibly do would be to use 
rdfs:subPropertyOf as above, or if you really want to assert equivalence 
then use -

p1 rdfs:subPropertyOf p2
p2 rdfs:subPropertyOf p1

the combination expresses equivalence of the properties, and an OWL Full 
reasoner could get {3} from {1} and vice versa.


>>The volatility issue is tricky - it's a common problem. OWL has
>>versioning capability terms that could be used to manage this, though
>>where individual terms may change independently OWL's per-schema
>>versioning isn't really granular enough. The craftiest solution I've
>>seen to this came recently from Alistair Miles and Chaals, using a
>>separate little ontology for each term.
>>    
>>
>
>Indeed a nice solution, if you can control the schema; which is not
>the case when you mix vocabularies.
>  
>

True, but you can still add a level of indirection:

foreign vocab :
their:messageId rdf:type rdf:Property

{local subschema} :
my:messageId owl:equivalentProperty their:messageId

local (namespaced that is used) schema
import {local subschema}

Cheers,
Danny.

-- 

Raw
http://dannyayers.com

Received on Thursday, 15 July 2004 08:07:13 UTC