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

Hi Brian,

>>> 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.

Ok, will do. Pardon my ignorance (and I am writing this on-line), what 
is the significance of @@

So, for the moment I understand that there is nothing I need to do to 
change the document format. I'll leave it at that until someone else 
points out what should be done.

> 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.

Actually, this is a good idea and may eliminate some of the confusion. 
Anyone else has thoughts on this?

> Do we have consensus on what we think is the 'best' approach.

we certainly don't :)

>  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.

I don't think that's an option here. If you have any doubt, see the 
discussion about a month back on "philosophy of swbp"...

>>> 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?

seeAlso is an annotation property, so it would be fine. I've added it.

>
> 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.

Thanks for the explanation, Brian. I don't think there are b-nodes 
involved here though. We are saying there are *some* lions there about 
which this book is about, but we are not creating any nodes -- blank or 
otherwise-- to represent those lions.

>>
>> 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.

I disagree. If I want to use a DL reasoner on my ontology but am 
willing not to have it do anything about the subjects, this option is a 
feasible one. As far as I know, all (at least most) DL reasoners that 
exist today will simply refuse to do anything with an OWL Full 
ontology. (Please correct me if I am wrong)

>>>   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.

I'd rather not, in particular since sometimes it may be hard to 
separate the two (when you use classes as instances). What is gained by 
the separation here (given that examples are tiny)?

>> 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.

Natasha

Received on Wednesday, 19 May 2004 22:31:11 UTC