ontolog-forum
[Top] [All Lists]

Re: [ontolog-forum] Fwd: Semantic Web shortcomings [was Re:ANN: GoodRela

To: "[ontolog-forum] " <ontolog-forum@xxxxxxxxxxxxxxxx>, "Len Yabloko" <lenya@xxxxxxxxxxxxx>
From: "Christopher Spottiswoode" <cms@xxxxxxxxxxxxx>
Date: Wed, 27 Aug 2008 19:00:43 +0200
Message-id: <002001c90866$889592c0$0100a8c0@Dev>
Len, sorry about the delay but I have (somewhat interruptedly)
been trying hard to understand you in this matter...  I had even
formulated a lot of comments and questions but I was not happy
with them.    (01)

Finally I came to the conclusion that your reference framework
was a CT one, so I shall fall back on my earlier request to you
(when you had explicitly mentioned categories and morphisms) to
return to the issue after my (still forthcoming) 5th instalment.    (02)

So I am hoping I can look forward to your CT-based perspectives
once you have seen the core role in MACK of transformations.  I
have a very simple programmer's view of that scene, albeit in a
strongly philosophical vein too, but I do also very strongly
suspect that CT could have an important role to play in refining
(in the sense of purifying) that aspect of MACK.    (03)

Christopher    (04)

----- Original Message ----- 
From: "Len Yabloko" <lenya@xxxxxxxxxxxxx>
To: "[ontolog-forum]" <ontolog-forum@xxxxxxxxxxxxxxxx>
Sent: Monday, August 25, 2008 4:22 PM
Subject: Re: [ontolog-forum] Fwd: Semantic Web shortcomings [was
Re:ANN: GoodRelations - The Web Ontology for E-Commerce]
>>>
>>>>Len,
>>>>
>>>>> Christopher:
>>>>>
>>>>> CS:
>>>>>>While I can quite understand the short-term convenience of
>>>>>>it, my problem with method overriding is that it torpedoes
>>>>>>the Liskov Substitution Principle:  an instance of a
>>>>>>subclass is no longer guaranteed to be an instance of the
>>>>>>baseclass. That's more than just a bizarre abuse -- it's
>>>>>>an overthrow of polymorphism as well as inheritance.
>>>>>
>>>>> I don't agree. Identity and behavior are orthogonal
>>>>> aspects in OO.
>>>>
>>>>Not so.  If an instance X of class A is defined as
>>>>necessarily having behavior P, but a programmer now states 
>>>>that entity X in this situation must now have behavior Q but 
>>>>not P, then, for all I know, X is no longer an A.
>>>
>>> LSP does not relate identity to behavior. In fact it does
>>> not deal with identity or behavior directly - instead it 
>>> promotes substitutability and correctness resulting from 
>>> behavior. (see
>>> http://en.wikipedia.org/wiki/Liskov_substitution_principle)
>>
>>Thanks for the pointer.  So I followed its references.  In the
>>first, Liskov's original 1987 paper enunciates "the following
>>substitution property" (where S is a subtype of T):
>>
>>"If for each object o1 of type S there is an object o2 of type
>>T such that for all programs P defined in terms of T, the 
>>behavior of P is unchanged when o1 is substituted for o2, then 
>>S is a subtype of T."
>
> The quote above does not contradict my point because neither
> identity or behavior of o1-->o2 is involved. The behavior of
> P, on the other hand, can not be directly related to identity 
> of o1 or o2. Moreover, it can be inferred that P defines the 
> scope and criteria for identity of o1 and o2.
>
>>
>>Even her (and Wing's) 1999 paper, the second Wikipedia
>>reference, in its abstract opens with this sentence:
>>
>>"We present a way of defining the subtype relation that
>>ensures that subtype objects preserve behavioral properties of 
>>their supertypes."
>>
>>So it would seem that the LSP does directly concern behavior.
>>
>
> LSP concerns behavior of some abstract program P that implies
> set of operations for which subtypes preserve invariance of 
> some properties. Nothing here directly relates identity of 
> individual type to its behavior.
>
>>And behavior in such circumstances must surely preserve
>>identity.  Then If a program transmutes identity, neither type
>>nor subtype would necessarily apply any more.
>>
>
> That is correct because program is the scope where subtype
> holds.
>
>>>
>>> I can understand your concern about method overriding done
>>> incorrectly in violation of LSP, but that does not mean that
>>> allowing overriding "torpedoes LSP".
>>
>>Not necessarily, but overriding does invite practices which
>>can easily torpedo both integrity and identity and thereby the 
>>intent of the LSP.
>>
>
> On the contrary - overriding according to LSP is the way to 
> enforce behavioral properties defined by the program operating 
> with abstract types. It provides the way to refine behavior 
> without imposing unnecessary constraints. That is intent of 
> LSP and not linking identity of types to their behavior.    (05)



_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/  
Subscribe/Config: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/  
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/ 
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx    (06)

<Prev in Thread] Current Thread [Next in Thread>