ontolog-forum
[Top] [All Lists]

Re: [ontolog-forum] CL, CG, IKL and the relationship between symbols in

To: "[ontolog-forum]" <ontolog-forum@xxxxxxxxxxxxxxxx>
From: "opensource@xxxxxxxxxxxxx" <opensource@xxxxxxxxxxxxx>
Date: Sat, 12 Jan 2008 12:28:46 +0100
Message-id: <4788A46E.3030105@xxxxxxxxxxxxx>
Hi John,    (01)

One of the underlying problems is that XML is a rather crude notation 
for KR.
* The underlying XML (KR) semantics is primarily defined here:
    <http://www.w3.org/TR/2004/REC-xml-infoset-20040204/>
* And the concrete textual notation/expression "XML Text" is defined here
   <http://www.w3.org/TR/2006/REC-xml-20060816/>
* a new variant "XML Binary" is  found here
   <http://www.w3.org/XML/Binary/>    (02)

 From what I can see in your  use case you are referring to meanings 
that is not really part of XML or even OWL (which is defined ontop of 
XML and RDF).    (03)

Discussing sub-superclass, aggregation, roles etc is rather difficult in 
terms of "XML", one can use XML as concrete notation/expression but XML 
itself does not have sufficient KR primitives. The XML Schema is attempt 
to add more KR primitives but it complicates and confuses the use of 
XML. Relax NG cleaner since its more oriented towards validation of XML 
document and not towards adding KR primitives.    (04)

The OMG approach with UML2 is an rather easy KR if one only needs basic 
gen-spec, aggregation ,class, properties, relation primitives.
There is another specification, XMI that describes how UML (or other MOF 
derived) Models are stored "using" XML. In XMI there are several flags 
defined that allows different XML styles to be used, i.e. the same 
knowledge can be stored in many different ways using XML.    (05)

One problem for XML is that there are may potential hierarchies and XML 
can only naturally express *one*. In UML2 Packaging is the dominating 
hierarchy, in others aggregation/composition or classification is 
*chosen* as the dominating hierarchy.
One can find arguments for either choice, personally i most often use 
hierarchical packaging or namespaces as dominating expression.    (06)

thanks
/anders w. tell    (07)

jayanosy@xxxxxxxxxxxxxxxxxxx wrote:
>
> Duane,
>
> I would really like to see response from the semantic community on 
> this question, since the XML hierarchy described illustrates concerns 
> I have about implicit semantics when applying XML approaches.
>
> Initially I thought the different paths through the hierarchy 
> demonstrated different 'sense' of meaning in an intensional manner, 
> like the well known 'morning star' and the 'evening star' examples 
> accomplish. But on further consideration it appears that they have 
> different referents, a buyer in one case and a seller in another case, 
> assuming that a buyer and seller on a purchase order cannot be the 
> same referent. So in some sense there is not a different context, but 
> rather a different name with a different referents, so no problem of 
> context here, nor a problem of different sense with the same referent.
>
>
> The following describes a few of my simple attempts to understand the 
> semantics of  the hierarchy.
>
> Let's assume the domain of discourse contains real world obects that are:
>
> Humans
> Buyers
> Sellers
> PurchaseOrders
>
> Let's assume that Humans have names, and expecially first names for 
> this example.
>
> //PurchaseOrder/BuyerParty/FirstNameOfHuman
>
> I can imagine different types of semantic realtionships defined for 
> the hierarchy, some make sense and others don't.
>
> Option 1: Class/SubClass relationship hierarchy with membership rule 
> stating that a member of a subclass is a member of the parent class, 
> and so on
>
> From the above XML hierarchy a BuyerParty is not an instance of a 
> PurchaseOrder so semantic model definition does not appear to work. 
> Also an instance of a Name is not an instance of a human but rather a 
> social property associated with a human.
>
> Option 2-: Aggregation relationship - where the parent class is 
> constructed from members of other classes. An example would be a car 
> with component elements of 'engine', 'exhaustsystem', 
> 'steeringsystem', etc.
>
> In the car aggregation example we can clearly define an aggregation 
> semantic relationship to  define a model that will represent all of 
> the elements of a car.
>
> Is a purchase order constructed in the same manner? I don't think so 
> since the real world referents are not elements of a purchase order 
> but have other semantic relationships to a purchase order.
>
> Does a PurchaseOrder have as a constituent element a Buyer or Seller? 
> I suspect that a Buyer or Seller has some form of commitment 
> relationship represented by the purchase order instance.
>
> The committment semantic realtionship could be stated as:
>
> purchaseCommittment(PurchaseOrder, BuyerParty)
> supplyCommittment(PurchaseOrder, SellerParty)
>
> Does a BuyerParty really have as a constituent element a 
> FirstNameOfHuman? I suspect that a name is not considered a 
> constituent element of a human but rather a social property associated 
> with a human for identification purposes. Thus I would think that the 
> semantic relationship between BuyerParty and FirstNameofHuman would be 
> some form of property identification relationship.
>
> hasIdentfier(BuyerParty, FirstNameofHuman)
> hasIdentifier(SellerParty, FirstnameofHuman)
>
>
> Option 3 - Defined Semantic Relationships
> With these new relationships we have a new semantic structure as follows.
>
> PurchaseOrder  ------purchaseCommittment  ---- BuyerParty
>                                 ------supplyCommittment  ---- SellerParty
>
>
> BuyerParty ------ hasIdentifier  ---- FirstNameofHuman
> SellerParty ----- hasIdentifier  ---FirstNameofHuman
>
>
> This type of structure clarifies the semantic relationships between 
> purchase order information elements and the referents in the domain 
> that the purchase order entails. I have used simple binary property 
> relationships between terms representing objects in the domain. 
> Obviously with this semantic structure it is possibled to represent in 
> an explicit semantic manner the conventional meanings asociated with 
> the information elements of a purchase order and the relationships to 
> the terms used for referents in the domain of discourse.
>
> So I think that these different hierarchy examples do not represent 
> different contexts with different semantic interpretations as a result 
> of context shifts, but rather different labels having different 
> referents. I also think that the semantics of the XML hierarchy are 
> not explicit in the XML representation and could be misinterpreted by 
> software developers not familair with the uses and conventions 
> associated with prushase orders. Worse different organizatiosn may 
> have different semantic understandings of the information elements of 
> a purchase order due to their organizations business rules or processes.
>
> *Use of XML for Context Metadata*
>
> This discussion I leave to the larger community, of whether simple XML 
> elements could be useful in a context representation, I suspect not.
>    (08)


_________________________________________________________________
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    (09)

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