Re: [OEP] Classes as Values - A detailed review

Natasha,

THis reflects agreement between Mike and me (except where noted).   A 
version with these changes is attached for you to merge with the official 
editors draft:

Natasha Noy <noy@smi.stanford.edu> wrote on 03/04/2005 12:15:39 AM:
> [New abstract] "This document addresses the issue of using classes 
> as property values in OWL. It is often convenient to put a class (e.g., 
> Lion) as a property value (e.g., topic or book subject) when building an 

> ontology. While OWL Full and RDF Schema do not put any restriction on 
> using classes as property values, OWL DL and OWL Lite do not generally 
> allow this use."
> 
> Fine up to here. Then you removed:
> "In OWL DL and OWL Lite, most properties cannot have classes as their 
> values. "
> 
> Any particular reason you removed this sentence? This qualification is 
> important, otherwise the preceding statement is misleading: you CAN use 
> classes as valued in OWL DL, but only for a limited, pre-defined set of 
> properties (such as rdf:type)

Because the previous sentence says the same thing ("OWL DL and OWL Lite do 
not generally allow this use.").

OK?

> [New abstract] "We present various use cases to motivate the need for 
> representing classes as values."
> 
> I don't think the document does this, nor should it.

Neither of us feel that strongly about having this in the abstract, 
however we can't figure out why you think the document doesn't do this. It 
presents one use case in detail, under the section titled "USE CASE", 
which is then addressed in all the examples, and in addition there is a 
section "Other use case scenarios" which mentions other possible use 
cases, all in the context of motivating why you are doing this.

If you agree, maybe a slight re-wording would be acceptable, but if this 
will generate prolonged debate it's not worth it and you can remove it.

> [New abstract] "We examine several different approaches to using OWL and 

> RDF Schema, and suggest how we  might achieve the desired effect of 
> representing classes as values in OWL DL and OWL Lite."
> 
> I don't think that's correct -- we don't show how to represent classes 
> as values in OWL DL -- we can't. We show workarounds,  none of which 
> uses classes as values (except for approach 5). So, how about.
> 
> "We examine representation of this information in OWL and RDF Schema and 

> suggest different ways of capturing it in OWL DL and OWL Lite"

OK, we used yours.

> 
> >I added a paragraph on issues and considerations.
> > 
> >
> I am still uncomfortable with having this paragraph there. First, I 
> think it is more than an editorial change and has more of a feel of 
> value judgment than the rest of the document. Also adds new 
> information/opinions. Some examples:
> 
> "If inferencing is going to feature in a big way, this may require the 
> use of OWL-Lite or OWL-DL"
> This is just not true: you can do inferencing in OWL Full, it will be 
> different type of inferencining. I guess what you wanted to say was "If 
> automatic classification is required" or "If the use of a DL reasoner is 

> required" or something like that.
> 
> "Is the approach natural, succinct and easy to understand or is it 
> technically complex"
> The problem is that this is also a value judgment. To me, approach 4 is 
> technically complex, to Alan Rector, nothing could be more natural. Note 

> that consideration points talk about "Some may consider it to be..." It 
> really is subjective.
> 
> Also, technical complexity does not necessarily imply difficulty in 
> maintenance. The approaches that replicate information require 
> additional maintenance, but they may still be fairly simple (at least 
> for some).
> 
> "Does the approach entail changing the semantic interpretation of an 
> ontology that is being reused"
> What if you are reusing your own ontology that no one else uses?
> 
> You see where I am going here. For each issue--possible implication pair 

> that you have in that paragraph, the implication part is easily 
> controversial. We can keep arguing these points, but it's exactly 
> because they are not that objective.
> 
> Second, I think this paragraph is not terribly useful at the beginning 
> of the document anyway: it probably won't make much sense to someone who 

> hasn't read the document yet. Something like that would be more 
> appropriate in the summary, but that still doesn't allay my first 
concern.
> 
> So, Chris is the TF chair, so he can decide whether this indeed amounts 
> to more than an editorial change. If he thinks it can still be 
> classified as an editorial change, and you feel strongly about including 

> it, I am not going to argue and will include it. The issues I mentioned 
> above will still need to be ironed out -- should be possible.

Mike recognizes your points are valid and still thinks there would be 
value to adding a section like this. However, he reluctantly agrees to 
skip this. 

I removed the section.

> >I redid approach 4. See what you think. 
> >
> Looks fine to me. It presents essentially the same information, but if 
> you feel it is better understandable this way, I can easily go for it. I 

> would make some minor changes for style, but after you give me the 
> "lock" back, and definitely not today.

OK.

> >I think that the last sentence,
> >about inference does not fit there any more. I was not sure where it
> >should go. Does it apply to the case of the variant, or the original? 
Or
> >both simultaneously?
> >Please clarify. Maybe it could be merged into the considerations?
> > 
> >
> The last word should have been BookAbout Animals. it's a typo. Does it 
> make more sense then?

Yes. OK, fixed & now makes sense

> >I did not yet get to a conclusion section.
> > 
> >
> 
> Let me know what your timing is on that and if you still plan to do it. 
> Also let me know when you want me to "own" the document. I won't touch 
> it until you tell me it's ok to do so.

We decided to drop the conclusion.  I do not think it would be "editorial" 
and I am not convinced it would add any value anyway.

Mike had another point that I agreed with - it is easy to miss the 
sentence that makes clear that this document is not intended to be 
construed as a statement of how to represent subjects on the semantic web, 
rather it focuses on ways to represent classes as values.  To address 
this, in the "other use cases" section I added a little more description 
of a possible medical classes-as-values use case that specifically 
mentions another possible property name, moved the statement about this 
note to a new paragraph, and emboldened the statement. 


-Chris