RE: [OEP] Close to final draft of "classes as values" note

Hi Natasha,

Thank you for the response. 

> -----Original Message-----
> From: public-swbp-wg-request@w3.org 
> [mailto:public-swbp-wg-request@w3.org] On Behalf Of Natasha Noy
> Sent: Friday, May 14, 2004 1:44 AM
> To: McBride, Brian
> Cc: swbp
> Subject: Re: [OEP] Close to final draft of "classes as values" note
> 
> 
> Brian,
> 
> here is my take on the rest of the comments in your email.
> 
> > I note that rdf/xml-abbrev examples are not being served 
> with the RDF
> > mimetype.  Is this fixable?
> 
> I have no idea what this means, but I suppose the answer is "yes", if 
> you tell me how.

When a web server serves a document, it attaches a 'tag' that indicates the
type of the document.  This 'tag' is the mime-type of the document.  The
mime-type for RDF documents should be application/rdf-xml, if I remember
correctly, but we should check.

You would need to talk to the web master of the web site.  I imagine we can
fix this as part of the publication process.  Might be a good idea to
include an @@ comment in the doc to remind us.

> 
> > Approach 2 confuses me.  It seems to say that a LionSubject 
> is of type 
> > lion,
> > which I interpret to mean it's the sort of individual with 
> claws that I
> > don't want to meet close up when its hungry.
> 
> That's one interpretation. If I don't care for lions with claws, but 
> have this sticky issue of having to be in OWL DL, I may 
> define my class 
> Lion as essentially a singleton, containing exactly one instance: 
> LionSubject. This class has nothing to do with the class of 
> Lions with 
> claws.

It is really not clear from the document that the class Lion in this
approach is different to the class Lion in approach 1.  I had missed the
significance of 

[[
We can treat the hierarchy of animal species as a hierarchy of subjects,
]]

However, I suggest on the web you should not do that.  If somone were to
merge instance data from approach 1 and approach 2 then one would get a
pretty confused result.  At least it would confuse me.  The class Lion would
contain both Lions, and LionSubjects.  I guess formally that might work, but
I'm not sure that is what was intended.

If you want to express this, would it not be better have the class hierarchy
consist of AnimalSubject, LionSubject and AfricanLionSubject to make the
distinction between this approach and approach 1 clear.

> 
> I am not a big fan of this solution, but I've seen it often as a 
> workaround for staying in OWL DL, and felt that it was necessary to 
> bring it up, if only to discuss the trade-offs. I was hoping that the 
> points in the "consideration" section make the trade-off clear. 
> Perhaps, not quite.

Do we have consensus on what we think is the 'best' approach.  If so, I
don't think we should hold back in saying so.  A document that clearly said,
if you are in RDFS or Owl Full we recommend aproach X, if in Owl DL we
recommend approach Y and here are some other approaches you might consider
also.

> 
> > Approach 3:  There is presumably a relation between LionSubject and 
> > Lion.
> > Do we have any vocabulary to describe it?
> 
> We may or may not, depending on a particular application and 
> domain. On 
> second thought, perhaps adding rdfs:seeAlso to instances of Subject 
> pointing to the classes in the hierarchy would make sense?

Yes I think it would, in the absence of a more specific relation.  Ah, oops,
did I just miss the point.  Would that take us back out of Owl DL?  Is
seeAlso an annotation property so that we are ok?

> 
> > Approach 4 looks like we are back to RDFS.  Again, the Owl stuff is 
> > needed
> > for defining classes such as BookAboutLions, but that seems 
> to me to be
> > beyond the point of the note - which I may be missing.  Do 
> you really 
> > mean
> > that you are using a specific instance of the class as the 
> value of the
> > dc:subject property, i.e. you have to give it a URI, or are 
> you using a
> > b-node - in which case its inaccurate to say that you are using a 
> > member of
> > the class - you are using an existential variable.
> 
> what's a b-node?

Ah, how long have you got?

You can think of a b-node as an existential variable over resources.  It is
typically represented as a resource, but just leaving out the URI. 

Oops I just noticed also that some of the diagram mix up literals and
resources.  "Lions: Life in the Pride" does not have a dc:subject of Lion,
the book with title "Lions: Life in the Pride" has dc:subject ...

This is the sort of thing you use bnodes for.  So the instance data in
approach 4 might look like:

  <rdf:Description>
    <dc:title>Lions: Life in the Pride</dc:title>
    <dc:subject>
      <rdf:Description>
        <rdf:Type rdf:resource="&ex;Lion"/>
      </...
    </...
  </...

The two rdf:Description elements are bnodes.

Maybe I can do something constructive instead of just moaning by helping out
on writing up the instance data examples.

> 
> 
> >  Looking at the n3 code
> > for this approach, there is no dc:subject property on the 
> examples so I
> > can't tell.
> 
> Exactly, there isn't: they are instances of a class where the 
> value of 
> dc:subject is some lion, but something we can't identify or 
> give a URI 
> to. Again, it's an approximation of a solution, but one that many 
> people use.

Ah, I looked at the rdf/xml code this time and I see what you are doing now.
I was silly.

I feel this really makes my point about needing to show how to do this in
RDFS as well.  You have defined a class BookAboutLions using Owl.  If I want
to say that a film is about lions I have to define a class FilmsAboutLions.
If I want to say a picture is about lions I have to define a class
PicturesAboutLions, ditto poems, murals, stories, ...

I note also that with this approach if I say that the the book title "Elsa"
is about lions, and the book "Children of Elsa" is about lions, I will say
that they are about the same lion.  I don't think you mean that, and I now
find this example misleading.

> 
> > Approach 5 looks like a minor variation on approach 1.  
> Given that it
> > doesn't really let one take advantage of Owl DL reasoning, 
> I'd suggest 
> > it be
> > presented as such, i.e. you can make approach 1 syntactically 
> > compatible
> > with Owl DL, but the cost of losing the subsumption 
> reasoning.  In rare
> > cases this might be useful.
> 
> Isn't that what the last bullet point says? 

Yes, and given its near to useless, I'm suggesting that it not be given
equal status with the other approaches.

(And, yes, it may 
> be useful 
> if you are not going to use DL reasoners, but for one reason 
> or another 
> your ontology must check as OWL DL. One possible example is when you 
> want to use DL reasoning on the rest of your ontology: many (all?) 
> classifiers would reject an OWL Full ontology and not perform any 
> reasoning at all. So, "faking" it with annotation properties can make 
> sense in this situation.
> 
> > I don't have time to check more examples.  The one I have looked at 
> > seems
> > incomplete.
> 
> Could you be more specific?

I meant the previous reference to the example in approach 4.  My comment was
wrong, but unfortunately, now that I've understood the example, I think it
is wrong in a different way.

> 
> >   I wonder about separating ontology examples from instance
> > examples.
> 
> I am not sure what you mean here.

Just showing the ontology spec separately from the instance data.  Here is
the ontology.  Here is the instance data.
> 
> > When this document is described as nearly final, do we mean 
> ready for 
> > wider
> > review, or do we mean final final?
> 
> Well, my view on this is that it is not going to be "final 
> final" until 
> we have more of these specific notes and write some introductory 
> document/FAQ for them as the result of the TF work. As we are writing 
> that document, we may find it necessary to update individual notes.
> 
> I thought the idea was to put something out to have people comment on 
> it (and use it, in fact).

Ok, putting it out for comment sounds good.  I've missed a few telecons and
am not clear about the process.  I'm more used to terms like publishing a
draft for comment than 'final'.  Please forgive my confusion.

Brian


> 
> Natasha
>

Received on Friday, 14 May 2004 06:55:09 UTC