[seek-kr-sms] KR Ontology Needs

Serguei Krivov Serguei.Krivov at uvm.edu
Tue Sep 14 13:35:33 PDT 2004


 
 
Hi All,
Here are some points on actors ontology  that were inspired by our last
year discussion in SB and Shawn's& Bertram's paper "Ontology driven
framework for Data Transformation...". To keep my messages compact and
possibly to have a conversation rather then a long monolog I'll send
them in peaces as I write. I would be happy if this could help to
generate questions, disagreements or design ideas.
 
 
 
Remark #1. Initially I had doubt that one could use DL for expressing
relations. For example if an actor A has input ports P1 and P2 and
output ports P3 and P4 and the data send to ports P1 and P2 must be
correlated. Could we express in DL that P1 and P2 are correlated?
 
Suppose that SP1 and SP2 are the names of semantic types for P1 and P2
respectively. Then we could think of semantic type SAin for actors input
as:

This declaration suggest that instance of input has two fields which are
values of properties SP1 and SP2. The real instance will provide two
values <x1,x2> where x1 is of type SP1 and x2 is of type SP2. Since they
are attribute values of just one instance- they could be related.
 
Thus, it is easy (at least on the surface) to simulate say n -tuple
P(X1,..Xn) by an instance of a class with n  attributes/slots. 
 
This answers a big question which bothered me one year back in SB on
"how to model relations in DL". (Perhaps this was not at all a question
for Bertram and Shawn, but sometimes it takes so long to understand what
others try to explain)
 
Yet there is one implication of the above consideration that may be of
interest- Whatever number of input ports agent has- they could be
represented just by one class/semantic type. In the example above SAin
is a single semantic type of input for actor A. Similarly we could
express output type of actor by just one class:

 
Note that classes SP1.SP4 may be pretty complex- they may themselves
have multiple slots, and could contain several nested declarations.
 
 
Remark #2. Given Remark 1,  an actor could be thought (1)  as a role
 
 

 
or (2) as a Class with two roles in and out:

 
or (3)  as both of those.
 
In first case the hierarchy of actors is role hierarchy.
In second case it is normal class hierarchy where roles in and out will
be further and further restricted as hierarchy moves down of the tree to
more specific classes. But actors have just two ports any level of
hierarchy. In the third case the two things have to be both present and
be correlated.
 
Those three ways are alternatives to the most evident way of actor
classification:
 (4)Use class to represent actors and roles to represent each input and
output port. Here  semantic types are assigned to each input/output port
separately. In this case the   specialization of actor classes is
achieved by incremental adding roles that represent either input or
output ports. Actors have more ports as we move down of actors tree. An
actor should have all the in/out ports of its respective super-actors.
 
(5)Perhaps #4 could be used in combination with #2, but it may prove
complex.
 
 
Does this have sense? If yes, then what strategy out of these 5 will you
guys like to use?
 
Serguei
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/seek-kr-sms/attachments/20040914/b1d79a16/attachment.htm
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 10847 bytes
Desc: not available
Url : http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/seek-kr-sms/attachments/20040914/b1d79a16/attachment.jpg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 11528 bytes
Desc: not available
Url : http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/seek-kr-sms/attachments/20040914/b1d79a16/attachment-0001.jpg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 6057 bytes
Desc: not available
Url : http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/seek-kr-sms/attachments/20040914/b1d79a16/attachment-0002.jpg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 10514 bytes
Desc: not available
Url : http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/seek-kr-sms/attachments/20040914/b1d79a16/attachment-0003.jpg


More information about the Seek-kr-sms mailing list