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

3-way telecon not possible, so I called Chris.

This is what we came up with:

1. Use classes directly as property values.
2. Create special instances of the class to be used as property values 
3. Use a parallel hierarchy of instances as property values
4. Create a special restriction in lieu of using a specific value.
5. Use classes directly as annotation property values.

I don't really like having 'property' everywhere, but I put it in so that the relationship between 1 and 5 is more obvious. I changed 'individuals' to 'instances', but we could use 'individuals' everywhere, if that worked. Should be consistent if possible.

Natasha, can you accept or fiddle with these to come up with what you like?

Mike


-----Original Message-----
From: Natasha Noy [mailto:noy@smi.stanford.edu] 
Sent: Tuesday, March 08, 2005 12:06 PM
To: Christopher Welty
Cc: Uschold, Michael F
Subject: Re: [OEP] naming CaV patterns [was: new Editor's draft of classes as valuesavailable]


2:30 works for me as well, but I can't do a conf call either. Mike -- 
you are the only hope :) My phone number is xxx-xxx-xxxx

Natasha

On Mar 8, 2005, at 12:03 PM, Christopher Welty wrote:

>
> 2:30 PST is fine with me.  I can't do a conference call from here,
> though (I'm not in the office).  Mike, can you?
>
> -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/
>
>
>
>
> Natasha Noy <noy@smi.stanford.edu>
>
> 03/08/2005 02:45 PM
>
> To
> "Uschold, Michael F" <michael.f.uschold@boeing.com>
>
> cc
> Christopher Welty/Watson/IBM@IBMUS
>
> Subject
> Re: [OEP] naming CaV patterns [was: new Editor's draft of classes as
> valuesavailable]
>
>
>
>
>
>
>
> I tend to agree with Chris -- having names would be great, but I doubt  
> we will come up with ones that are any shorter than what is there now  
> and that we all agree one. I am willing to spend 15 minutes of a phone  
> call on this, but not more, since I really do think it would be 
> futile.  Unfortunately though, I am at a conference in SF for most of 
> the day  today and tomorrow. The only time that looks open today is 
> 2:30 to 3:30
>  my time, but this maybe too late for Chris. Is it? Perhaps we can have
>  a brief chat 2:30-2:45 if we think we can achieve something. 
> Otherwise,
>  let's just drop it.
>
>  Natasha
>
>  On Mar 8, 2005, at 10:06 AM, Uschold, Michael F wrote:
>
>  > What you don't like my names :-)
>  >
>  > Although they are far from great, I could live with them. Ideally,
>  > they should be a convenient handle so when people hear the name, the
>  > [key aspects of the] approach comes to mind. The names I suggested
>  > have two things in their favor: accuracy and they all address a 
> single
>  > issue, and so are more easily compared.   If they are confusing or
>  > ambiguous, we can try and fix that.
>  >  
>  > If we think it is worth having good names, I suggest a quick 10-15 
> min
>  > telecon with you, me and Natasha to see if we can come up with
>  > anything. Email back/forth WILL take too long. If we can't get
>  > anywhere, then we can drop it.
>  >  
>  > If neither of you can be bothered, then lets just drop it now.
>  >   
>  > M.
>  > -----Original Message-----
>  > From: Christopher Welty [mailto:welty@us.ibm.com]
>  >  Sent: Tuesday, March 08, 2005 7:05 AM
>  > To: Uschold, Michael F
>  > Cc: Natasha Noy; swbp; public-swbp-wg-request@w3.org
>  > Subject: RE: [OEP] naming CaV patterns [was: new Editor's draft of
>  > classes as valuesavailable]
>  >
>  >
>  > 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 20:48:10 UTC