RE: [OEP] naming CaV patterns [was: new Editor's draft of classes as values available]

I liked the idea of naming the patterns until I saw the suggested names. I 
suggest dropping this issue, I think it will take too long to come up with 
good names - I disagree with most of these (some are confusing and/or 
ambiguous).


-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/



"Uschold, Michael F" <michael.f.uschold@boeing.com> 
Sent by: public-swbp-wg-request@w3.org
03/07/2005 09:09 PM

To
"Natasha Noy" <noy@smi.stanford.edu>, "swbp" <public-swbp-wg@w3.org>
cc
Christopher Welty/Watson/IBM@IBMUS
Subject
RE: [OEP] new Editor's draft of classes as values available







Natasha, 

Thanks for having a go at naming the approaches. Tough job.  I looked at
my original review notes which focused on WHAT EXACTLY IS THE VALUE OF
WHAT PROPERTY.  This is the essential thing that distinguishes each
approach. So, my names suggest answers to that question for each.

And the NEW SUGGESTION IS:
1.               classes as values [the direct approach]
2.               class instances as values
3.               parallel classes instances as values
4.               implicit class instances as values
5.               classes as annotation property values

I think these are all accurate, getting to the heart of the matter, and
are reasonably short.
What do you think?

Your suggestions:

1. Classes directly as property values
2. Parallel set of individuals for property values
3. Parallel hierarchy of individuals for property values
4. Classes with value restrictions as types
5. Classes as values for annotation properties

My notes...

o                1:  the actual class, e.g. Lion
the relationship of this value to the class Lion is identity (it IS the
class)
o                2:  an instance (called LionSubject) of the class: Lion 
denoting
the subject of Lions. 
The relationship of this value to the class, Lion is: rdf:Type (or
instance)
o                3:  an instance (called LionSubject) of the class: 
Subject
denoting the subject of Lions. 
LionSubject is related to the class Lion via an rdf:seeAlso link.
o                4: an [implicit] unidentified instance of the class Lion.
The relationship of this [nonexistent implicit] value to the class Lion
is rdf:type
o                5: the actual class, e.g. Lion
the relationship of this value to the class Lion is identity (it IS the
class)
NB: this is identical to approach 1. The difference is that the property
is an annotation property.



-----Original Message-----
From: Natasha Noy [mailto:noy@smi.stanford.edu] 
Sent: Friday, March 04, 2005 4:48 PM
To: swbp
Subject: [OEP] new Editor's draft of classes as values available



The new version of the Editor's draft is available at the same location

[1] (also accessible from OEP page [2]).

I think we have converged on all the issues except for the abstract 
[3]. Chris, Mike, for the moment I conveniently assumed that you will 
agree with my last message [3], but we can still of course change it.

I went through the document and fixed most typos, references, etc. When

doing that I've also fixed a couple of extra issues that Mike brought 
up in his review and that I somehow missed (e.g., moving the SKOS 
discussion to a slightly different location).

Mike, I also edited your re-wording of approach 4 a bit, but I tried 
not to change the meaning or the order of sentences in your text to 
make it even more clear (I think). If you are going to re-read anything

in the document besides the abstract, this is the section to read.

Besides agreeing on the abstract, there is only one more thing 
remaining: shorter titles for the patterns, if we can come up with 
them. I've tried to come up with something, but I am not at all crazy 
about the result. It may not be that easy to do. Any thoughts on the 
list below?

1. Classes directly as property values
2. Parallel set of individuals for property values
3. Parallel hierarchy of individuals for property values
4. Classes with value restrictions as types
5. Classes as values for annotation properties

Other than that, I think we are done...

Natasha

[1] 
http://smi-web.stanford.edu/people/noy/ClassesAsValues/ClassesAsValues 
-2nd-WD.html
[2] http://www.w3.org/2001/sw/BestPractices/OEP/
[3] http://lists.w3.org/Archives/Public/public-swbp-wg/2005Mar/0053.html

Received on Tuesday, 8 March 2005 15:05:53 UTC