W3C home > Mailing lists > Public > public-swbp-wg@w3.org > March 2005

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

From: Natasha Noy <noy@smi.stanford.edu>
Date: Tue, 8 Mar 2005 13:45:44 -0800
Message-Id: <87dad643c3193fde6f53ca4760d90f17@smi.stanford.edu>
Cc: "Christopher Welty" <welty@us.ibm.com>, <public-swbp-wg@w3.org>
To: "Uschold, Michael F" <michael.f.uschold@boeing.com>

These look good -- I would probably change "Use" in pattern 3 for 
"Create".

They are not particularly short and catchy names though, so I don't 
think they will actually serve the purpose you had in mind originally. 
But I am happy to change to these.

Natasha

On Mar 8, 2005, at 12:47 PM, Uschold, Michael F wrote:

> 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 21:45:50 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:31:07 UTC