OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

soa-rm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [soa-rm] [For Issue #525] RE: [soa-rm] Groups - Proposed SOA-RM Relationship Names (SOA-RM Relationships Names.xls) uploaded


Meant to send DRM 2.0 link:
http://www.whitehouse.gov/omb/egov/documents/DRM_2_0_Final.pdf
(see document pages 21, 41, and 59 for concept maps with relationship
names)

Joe

Joseph Chiusano
Associate
Booz Allen Hamilton
 
700 13th St. NW, Suite 1100
Washington, DC 20005
O: 202-508-6514  
C: 202-251-0731
Visit us online@ http://www.boozallen.com

-----Original Message-----
From: Chiusano Joseph [mailto:chiusano_joseph@bah.com] 
Sent: Monday, May 01, 2006 1:36 PM
To: soa-rm@lists.oasis-open.org
Subject: RE: [soa-rm] [For Issue #525] RE: [soa-rm] Groups - Proposed
SOA-RM Relationship Names (SOA-RM Relationships Names.xls) uploaded

Hi Duane,

Do you see value in providing relationship names for the purpose of
clarity of understanding, apart from any particular technology? FWIW, we
included relationship names in the DRM (just as one example out there).
Would be interested in your take on this, as well as others.

Joe

Joseph Chiusano
Associate
Booz Allen Hamilton
 
700 13th St. NW, Suite 1100
Washington, DC 20005
O: 202-508-6514
C: 202-251-0731
Visit us online@ http://www.boozallen.com

-----Original Message-----
From: Duane Nickull [mailto:dnickull@adobe.com]
Sent: Monday, May 01, 2006 1:33 PM
To: Rex Brooks; Chiusano Joseph; soa-rm@lists.oasis-open.org
Subject: RE: [soa-rm] [For Issue #525] RE: [soa-rm] Groups - Proposed
SOA-RM Relationship Names (SOA-RM Relationships Names.xls) uploaded

Guys:

If you are going to do this, I would suggest that you define or use some
form of FOL before trying to map this.  I also suggest that this be done
in a sub TC so we don't clutter up the main list for those who have no
interest in mapping the concepts to an ontology.  Perhaps one of you can
propose this but you also have to consider the original charter does not
state we are going to deliver this.  I think it would be okay but we
would have to check.

Some of the concepts I see the names for are very concrete.  How can you
have a "thing" consisting of another thing in the abstract?  Without
first defining the FOL, this is not meaningful to me.

Rex is correct - the exact version of OWL must also be specified.  

The abstract relationship types are much more complex than they first
appear.  I usually borrow from SUMO and use the defined FOL binary
associations.  The supported types are very thoroughly documented.

An example of FOL is the definition of binary predicate:

(instance instance BinaryPredicate)
(domain instance 1 Entity)
(domain instance 2 SetOrClass)
(documentation instance "An object is an &%instance of a &%SetOrClass if

it is included in that &%SetOrClass.  An individual may be an instance
of many classes, some of which may be subclasses of others.  Thus, there
is no assumption in the meaning of &%instance about specificity or
uniqueness.")

This appears to only be applicable to concrete classes and not abstract
classes however.  

(instance inverse BinaryPredicate)
(instance inverse IrreflexiveRelation)
(instance inverse IntransitiveRelation)
(instance inverse SymmetricRelation)
(domain inverse 1 BinaryRelation)
(domain inverse 2 BinaryRelation)
(documentation inverse "The inverse of a &%BinaryRelation is a relation
in which all the tuples of the original relation are reversed.  In other
words, one &%BinaryRelation is the inverse of another if they are
equivalent when their arguments are swapped.")

(=>
   (inverse ?REL1 ?REL2)
   (forall (?INST1 ?INST2)
      (<=>
         (holds ?REL1 ?INST1 ?INST2)
         (holds ?REL2 ?INST2 ?INST1))))

Notwithstanding the foregoing, the task at hand is to ask the question
"what types of relationships are you trying to label?".  An intransitive
binary relationship has completely different properties that reflexsives
do.  The simple story is down to "if A means X to B, what does B mean to
X?".  Can B even be aware of X? Is the relationship symmetrical or
asymmetrical.

Without these items defined, the conversation is a non starter.  There
is lots of work to do on this.

Duane


*******************************
Adobe Systems, Inc. - http://www.adobe.com Vice Chair - UN/CEFACT
http://www.uncefact.org/ Chair - OASIS SOA Reference Model Technical
Committee Personal Blog - http://technoracle.blogspot.com/
******************************* 


-----Original Message-----
From: Rex Brooks [mailto:rexb@starbourne.com]
Sent: Monday, May 01, 2006 10:03 AM
To: Chiusano Joseph; soa-rm@lists.oasis-open.org
Subject: Re: [soa-rm] [For Issue #525] RE: [soa-rm] Groups - Proposed
SOA-RM Relationship Names (SOA-RM Relationships Names.xls) uploaded

Yup,

If we are going to provide relationship names to accommodate OWL, we
need to be specific about which version of OWL we want to support or CAN
support, given the abstract nature of the Reference Model.

I would be happy with OWL DL, less happy with OWL Lite, and opposed to
OWL Full. Going into the reasons is something we should take up in the
f2f, because it is too lengthy for an email. However, I would prefer to
put this on hold for a v2.0 which I suspect is almost unavoidable,
though one hoped it would not be given sufficient abstraction.

That said, I would select relationship names directly from the realm of
RDF in general and RDF Schema in particular and, for me, OWL DL and not
make up any new ones and I would start with extremely basic, very
abstract, relationships and not use any terms that are open to
interpretation. In other words, I would try to start with compliance
with first-order logic. Going beyond basic classes and properties to
subClassOf and subPropertyOf is about as far as I would go. Otherwise we
open the door to a purely endless exercise in futility. It would take a
lot of work and I don't think we have time for it in this version.

This is probably not a good idea.

I would prefer to see it be a separate specification, with its own set
of requirements starting with mereology from general to specific, where
you define things in the isPartOf relationship not the consistsOf
relationship.  The difference is that there are some accepted rules for
mereology, and it works with formal logic. If we are going to
accommodate OWL now we need to make sure we are not setting ourselves up
for a bunch of logical contradictions by going full steam ahead before
looking at the landscape and figuring out what kind of roadmap we need.

I think the spreadsheet is a good way to get concepts out where you can
look at them and pick away at them. I just don't think this is likely to
get well baked enough to include in this round, and perhaps ought to be
its own specification, a SOA ontology based on the RM. 
That would give us plenty of time to noodle and boil this down to
workability.

Regards,
Rex



At 11:05 AM -0400 5/1/06, Chiusano Joseph wrote:
>I've updated the subject for this thread to reflect the Issue #. Any 
>thoughts on the proposed relationship names?
>
>Joe
>
>Joseph Chiusano
>Associate
>Booz Allen Hamilton
>
>700 13th St. NW, Suite 1100
>Washington, DC 20005
>O: 202-508-6514
>C: 202-251-0731
>Visit us online@ http://www.boozallen.com
>
>-----Original Message-----
>From: chiusano_joseph@bah.com [mailto:chiusano_joseph@bah.com]
>Sent: Thursday, April 27, 2006 8:52 PM
>To: soa-rm@lists.oasis-open.org
>Subject: [soa-rm] Groups - Proposed SOA-RM Relationship Names (SOA-RM 
>Relationships Names.xls) uploaded
>
>The document named Proposed SOA-RM Relationship Names (SOA-RM 
>Relationships
>Names.xls) has been submitted by Mr. Joseph Chiusano to the OASIS SOA 
>Reference Model TC document repository.
>
>Document Description:
>This is related to issue #525, which described "the potential creation 
>of an OWL ontology for SOA-RM to be considered as an upper ontology for

>different architectures guided by SOA-RM, in order to provide semantic 
>interoperability between these architectures and their implementations 
>(instances), once they are SOA-RM based.". The submitter expressed how 
>the lack of relationship names in our spec inhibited this.
>
>I have worked with the submitter and Ken Laskey to create this 
>spreadsheet of proposed relationship names for all figures that contain

>directed relationships. Please review and comment; you may wish to use 
>the spreadsheet row # when referring to specific relationships. We have

>provided 2 sets of proposed names for each relationship (except the 
>final
>one) - one primary, and one alternate.
>
>Please also keep in mind that some of the proposed relationship names 
>may bring with them minor alterations in the relationships themselves.
>
>Thanks,
>Joe
>
>View Document Details:
>http://www.oasis-open.org/apps/org/workgroup/soa-rm/document.php?docume
n
>t_id=17877
>
>Download Document:
>http://www.oasis-open.org/apps/org/workgroup/soa-rm/download.php/17877/
S
>OA-RM%20Relationships%20Names.xls
>
>
>PLEASE NOTE:  If the above links do not work for you, your email 
>application may be breaking the link into two pieces.  You may be able 
>to copy and paste the entire link address into the address field of
your
>web browser.
>
>-OASIS Open Administration


--
Rex Brooks
President, CEO
Starbourne Communications Design
GeoAddress: 1361-A Addison
Berkeley, CA 94702
Tel: 510-849-2309


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]