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