Re: slotted notation -summary

Chris Welty wrote:

>> In RDFS/OWL that "must conform to" is not quite the same notion as in 
>> many object oriented notations, in RDFS/OWL it effectively means "does 
>> not contradict". The semantics license a deduction that vali is of 
>> type typi and only if one of vali's types is disjoint from typi is 
>> there a contradiction. Many object oriented systems have a stronger 
>> notion of type conformance.
> 
> I wouldn't use the word "stronger" here, I've heard some argue that it 
> is weaker, even though they are talking about the same thing.  What you 
> are trying to get at is that the OO notion is syntactic, and the RDFS 
> (indeed, the FOL) notion is semantic.  To have a value that is an 
> instance of a type disjoint with the slot signature is a syntax error in 
> OO and a contradiction in FOL.  In the latter, you can at least *say* 
> it, even though it leads to contradiction, in the former you cannot say 
> it in the language at all.
> 
> The closed world assumption comes into play here as well, as types in 
> most OO systems (but not all!) are assumed disjoint unless there is a 
> subclass relation between them.  FOL (and thus RDFS and OWL) semantics 
> make no assumptions.

Agreed. It was this common (but, as you say, not universal) closed-world 
assumption of disjointness in the absence of an explicit subclass 
relation that I was particularly concerned with.

>> Further in some object oriented notations the signature is regarded as 
>> closed so that if you have:
>>    p(slot1=>typ1, ... slotn=>typn)
>> and then later see
>>    p(slotz->valz)  (where z not in 1 .. n)
>> that is an error unless you modify the signature to include slotz.
>> In RDFS it is perfectly legal (and beneficial).
>>
>> I don't know enough about F-logic to be sure whether it is identical 
>> to RDFS in these regards but in any case it seems that even within the 
>> object-oriented slot notion there is some variation of semantics 
>> possible.
> 
> This closed signature actually causes a genuine incompatibility between 
> FOL and OO semantics, when (using Michael's syntax here) we allow the 
> predicates to have a taxonomic structure, ie p:q means that p is a 
> subclass of q and "inherits" its signature, then if you have:
> 
> q(slot1=>typ1, ... slotn=>typn)
> p(slotz=>typz)
> 
> in both semantics, the signature of p becomes (by "inheritance") 
> essentially:
> 
> p(slot1=>typ1, ... slotn=>typn, slotz=>typz)
> 
> BUT, in FOL semantics, since all p's are q's, it is perfectly reasonable 
> to have some q with a slotz, in fact there are a bunch of them (all the 
> instances of p), but in OO there would be no way to express the rule 
> that any q with a slotz of typz is a p.  Since the signature of q is 
> closed, you cannot have an instance of q that has a slotz, unless it is 
> *already* a p.  

> Another peculiarity here, that I'm not sure what to make of yet, is that 
> in what Michael is calling the OO slot notation, all the types are 
> themselves relations.  This is normal in FOL style semantics, but NOT 
> normal in OO style semantics, where classes have a special status.

Quite so.

> Again, I think it's useful to point out these differences, but I'm not 
> sure how important they are.

Seems me that at least the choice of open or closed signatures is 
important. At least in one direction - picking closed signatures would 
limit the usefulness of the slotted syntax for working with RDF, not a 
fatal flaw but something to be conscious of.

What I don't understand is what people want out of this slotted notation 
in the first place to know whether the open world assumption would 
negate its value to them.

It's certainly the case that one of our major support costs is users 
approaching RDFS/OWL as if it were object oriented and implicitly making 
closed world assumptions and getting burned. So I'm keen that whatever 
choices are made here are at least spelled out extremely clearly.

Dave

Received on Thursday, 4 January 2007 15:24:58 UTC