RE: [OEP] minutes of 5/26 telecon - Naming the 3rd Use Case

In trying to think of a better name for Use Case 3, I tried to identify
the essential similarities and differences between the three use cases,
and then to think of names that consistently and accurately refer to the
core aspect(s) that distinguish each case.

First a question to the authors: For pattern 1, use case 1, do you
really mean to only have 1 additional attribute, or could there be
several? e.g. you might include the person making the diagnosis. The
latter seems more likely.

I propose the following as a structure for presenting the use cases, the
goal is to make clear the essential similarities and differences among
the approaches.
The three different use cases should focus on two main things that
differentiate them
1.	when they arise
2.	what you actually do to represent them in OWL - the details
focusing on variations of the common core.

PATTERN 1: Introducing a new class for a relation
When it arises:
* when there is no special order relationship on the different
participants in the [n-ary] relation.

What you actually do: 
we create a new class and n new properties to represent an n-ary
relation. 

USE CASE 1: "additional attribute[S] describing a relation"
When it arises: 
*	when we need to represent one [or more] additional attributes
describing a relation instance, and 
*	when there is a distinguished individual that is involved in the
relationship, and the other individuals describe attributes of the
relation.

What you actually do: 
* create a new [distinguished] property representing the relationship
between the distinguished individual participating in the original n-ary
relation and the new class representing the relation instance.
* create new properties for each of the other individuals that
represents the additional attributes of the relation.

USE CASE 2: "different aspects of the same relation"
When it arises: 
*	when you need to represent different aspects of the same
relation and 
*	when there is a distinguished individual that is involved in the
relationship, and the other individuals describe the different aspects
of the relation.

What you actually do: 
* create a new [distinguished] property representing the relationship
between the distinguished individual participating in the original n-ary
relation and the new class representing the relation instance.
* create new properties for each of the other individuals that
represents the additional aspects of the relation.

NB: this is very similar (identical?) to the first one. Basically, I
only replaced the word 'attribute' with 'aspect'. These words are mighty
similar in meaning.  I don't get the essential difference between
"additional attributes describing a relation" and "different aspects of
the same relation". Can you explain it?
I guess this means I disagree with or don't understand the claim that:
"In most intended interpretations, this instance of a relation cannot be
viewed as an instance of a binary relation with additional attributes
attached to it."

There might really be a good clean distinction between these two use
cases, but to me it is fairly slippery, and I still don't quite see it.
If it is this slippery for me, then it might be difficult for less
knowledgeable readers?

USE CASE 3: "network of individuals" 
When it arises: 
*	When there is a single event or situation that has multiple
aspects or attributes, and
*	When there is a NO distinguished individual that is involved in
the relationship; all participants/individuals are roughly comparable in
importance. 

What you actually do: 
* create new properties for each of the individuals that represents the
different aspects/attributes of the event or situation.

PATTERN 2:
When it arises: 
When there IS a linear ordering relationship among the different
participants in the relation..

What you do: blah blah blah.

=====


So, what to name the last use case?

The only thing that distinguishes this from the first two is that there
is no distinguishing participant in the n-ary relation. That's it. So,
somehow the name should indicate that. Ideally, the names of the other
two should also reflect that issue, but that would result in awkward
names.

My suggestion for the last one:
"Multiple aspects of a single event or situation, with no distinguished
participant."

It is semantically accurate, though not that great otherwise.


-----Original Message-----
From: Christopher Welty [mailto:welty@us.ibm.com] 
Sent: Thursday, May 26, 2005 1:55 PM
To: public-swbp-wg@w3.org
Subject: [OEP] minutes of 5/26 telecon



Minutes of 5/26/2005 OEP telecon 1900 UT

Attendees: Chris_Welty, natasha_noy, Mike_Uschold, Evan_Wallace, 
aldo_gangemi
IRC log: http://www.w3.org/2005/05/26-swbp-irc

We discussed the latest n-ary relations editors draft of 24 May 
[http://smi-web.stanford.edu/people/noy/nAryRelations/n-aryRelations-2nd
-WD.html], 
and Mike's extensive review.  Numerous minor changes and some rewordings

suggested.  The main discussion centered on the name for Use Case 3, 
currently "network of individuals".  We tossed around the idea of using 
"Events", but convinced ourselves this was too specific, as the use case

applies in general to n-ary relations for which the arguments are a) 
individuals and b) no individual is clearly the "subject". 

We resolved to take the question as homework.  Suggestions welcome.

We discussed the "unintended models" point as well.  It turns out that
the 
comment about RDF treating two triples with the same S,P,O as "the same"

is not accurate.  As a result, the point is more general than just n-ary

relations, and is also more complicated than the bullet describes. We 
resolved to remove this bullet and move that point to the "pitfalls"
note, 
with perhaps a forward reference to it.

Finally, we discussed the proposed standard vocabulary for reified 
relationships.  Natasha suggested that specific vocabulary for mapping
OWL 
to other languages does not belong in this note, in particular the 
"argNum" property in the proposed vocabulary is for mapping n-ary 
relations to languages that use argument position to encode the role.
The 
"use cases" for this standard vocabulary were 1) tools that treat
reified 
n-ary relationships in some special way and thus need to know which ones

they are, and 2) translating OWL & RDF to other languages that support 
n-ary relations in the syntax.  Chris claimed the vocabulary, with the 
argNum property, enabled translation to any other language.  Natasha and

Evan suggested that UML "association classes" 
[http://www.agilemodeling.com/style/classDiagram.htm#Figure2] may
require 
something different as well.  This wasn't clear.

We resolved to continue this discussion by email.  The general issue is 
whether the proposed standard vocabulary should be part of the N-ary
note, 
or a separate note, and whether issues of language translation are in 
scope for the n-ary relations note. Someone (Evan?  Natasha?) will post 
something describing UML association classes in more detail (or more 
formally).  Aldo made some points about QCRs, but he had a bad
connection 
and it was difficult to understand - he also promised to post something
to 
the list.

Thanks all for the productive discussions.

Cheers,
Chris

Dr. Christopher A. Welty, Knowledge Structures Group
IBM Watson Research Center, 19 Skyline Dr., Hawthorne, NY  10532     USA

 
Voice: +1 914.784.7055,  IBM T/L: 863.7055, Fax: +1 914.784.7455
Email: welty@watson.ibm.com, Web: 
http://www.research.ibm.com/people/w/welty/

Received on Thursday, 26 May 2005 22:33:57 UTC