Re: [OPEN] and/or [PORT] : a practical question

Jeremy wrote on 03/24/2004 04:24:16 AM:

> 
> Yes, like Bernard, I have been thinking more about this, and about Ian's 

> insistence in WebOnt that classes-and-instances was almost always raised 
by 
> people wanting to mismodel their world. (cc Ian, wondering if I have 
learnt 
> my lessons well!, or misrepresented him)

Well, "mismodelling their world" is not limited to classes as instances. I 
find it rather dangerous to make such statements.  People use subclass 
incorrectly, too, but that wasn't a reason to remove that axiom from OWL 
DL.  People just mismodel their worlds, I hope we can offer some advice on 
both how to do some of these things and how NOT to do it.

Anyway, your analysis exposed some important misconceptions, espcially 
regarding so-called "subject hierarchies" and class hierarchies.  I've 
written a paper or two about the problem, in this one: 
[http://dx.doi.org/10.1016/S0169-023X(99)90021-6] I basically show that 
subject taxonomies are actually "part"onomies, or more precisely spatial 
containment,  not subclass (in fact, etymologically, "subject" means to 
throw under, "topic" is a region, and "about" means near).  Some of the 
initial problems of representing subject taxonomies in DLs are discussed 
in a paper in the first FOIS conference, which may be hard to find.  I 
can't seem to find a softcopy myself.

> The class hierarchy in RDFS/OWL is there to describe hierarchies of 
classes 
> of resources. Just because you have a hierarchy of subject descriptors 
> doesn't make it a class hierarchy.
> 
> It seems to be confusing the human way of thinking of analogy and 
metaphor 
> (any hierarchy can act as a metaphor for any other hierarchy) with what 
is 
> a logical and implementation issue about how to say what we want to say 
> about our knowledge of our world in a way that machines can process it.
> 
> Thus if PhDThesis is an owl:Class what are the resources that we intend 
to 
> belong to it? Probably my PhD Thesis with title "Graph Grammars: an 
> approach to transfer based MT; exemplified by a Turkish-English system" 
is 
> one such resource, but the copy sitting on my bookshelf is probably not.
> 
> Then if that is the case what would we mean by dc:subject linking the 
> resource of my thesis with this class .... hmmm ... we mean my thisis 
> belongs to that class, i.e. rdf:type.
> So if we want to treat this subject hierachy as classes we really also 
want
> 
> dc:creator rdf:subPropertyOf rdf:type .
> 
> or perhaps
> 
> eg:creator rdf:subPropertyOf rdf:type .
> eg:creator rdf:subPropertyOf dc:creator .
> 
> But if we click on dc:creator we get to:
> http://purl.org/dc/elements/1.1/subject
> 
> <rdf:Property rdf:about="http://purl.org/dc/elements/1.1/subject">
> <rdfs:label xml:lang="en-US">Subject and Keywords</rdfs:label>
> <rdfs:comment xml:lang="en-US">The topic of the content of the 
> resource.</rdfs:comment>
> <dc:description xml:lang="en-US">
> Typically, a Subject will be expressed as keywords,
> key phrases or classification codes that describe a topic
> of the resource.  Recommended best practice is to select
> a value from a controlled vocabulary or formal
> classification scheme.</dc:description>
> <rdfs:isDefinedBy rdf:resource="http://purl.org/dc/elements/1.1/"/>
> <dcterms:issued>1999-07-02</dcterms:issued>
> <dcterms:modified>2002-10-04</dcterms:modified>
> <dc:type 
> 
rdf:resource="http://dublincore.org/usage/documents/principles/#element"/>
> <dcterms:hasVersion 
> rdf:resource="http://dublincore.org/usage/terms/history/#subject-004"/>
> </rdf:Property>
> 
> and we see that dc:subject should typically be a string from a 
controlled 
> vocabulary. Thus it seems particularly poor practice to deviate from the 

> preferred usage of dc:subject in order to (over-)simplify our model.
> 
> This points to the solution I was earlier advocating of using such 
strings, 
> using hasValue restrictions to map the strings into classes and then 
using 
> the class hierachy on those restrictions to show the hierarchical 
> relationships between the subject vocab terms. To do this well, we 
probably 
> want to specialise the dc:subject property with a subproperty 
eg:subject, 
> specify its range with an owl:Datarange explicitly enumerating the 
> controlled vocabulary, and for each term create a class using a hasValue 

> restriction.
> For further clarity and usablility we might want to create two related 
> properties, one indicating the (single) intended subject code, and the 
> other indicating all implicit subject codes formed from the class 
hierachy.
> The former would be a subproperty of both the latter and dc:subject; the 

> latter would be used to create the hasValue restrictions.
> 
> Hmmm ... quite a lot of work initially, but the end result is that the 
> subject indicators are marked up using text strings from an explicit 
> controlled vocab; we conform with the defn of dc:subject, even with the 
> advertised best practice; we fall within OWL DL with the expectation 
that 
> this will give us better reasoning performance, and we have been clearer 

> about we are trying to say. I think the complexity can be hidden from 
the 
> end users.
> 
> Jeremy
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Bernard Vatant wrote:
> > 
> > *BV
> > 
> >>>- Is it worth the trade-off to switch one's ontology (otherwise DL)
> >>>to OWL-Full, just to
> >>>allow its classes to be used as objects in 'dc:subject' predicates?
> > 
> > 
> > *Jim
> > 
> >>That's a weird way to ask the question.  You mean, is it worth doing
> >>the extra work to break your naturally occuring model just so that
> >>you can be in DL?
> > 
> > 
> > The way I put it might seem weird indeed, but it's the way it was set 
in the real project
> > context (real world is weird). We had an OWL-DL ontology, and wanted 
to keep it so, and
> > suddenly after six months or so some user wants to be able to use a 
class as a subject of
> > a document ... which is one case out of one thousand, the 999 others 
using 'regular'
> > subjects. So using a class as subject of a document is not exactly 
'naturally occuring'.
> > It's a borderline case - not to say a weird one :))
> > 
> > *Jim
> > 
> >>I would argue this is indeed a BP issue, but probably for WORLD not
> >>for OPEN... we need to explain why and when you would do the extra
> >>work (and in every case we have explored it is extra work) to make
> >>sure your ontology is in the DL profile of OWL.
> > 
> > 
> > I suggested it might be in PORT scope, because it deals with the 
terminology vs ontology
> > general issue. For me the heart of the question is to know what it 
means to 'use a
> > concept' defined in a terminology (glossary, thesaurus, subject 
headings, index...) as a
> > class (or a property) in an ontology.
> > 
> > Is 'PhD Thesis' class the same 'subject' (using TM language here, 
sorry) or 'resource'
> > than the original concept? The more I think about it, the more I have 
to deal with it, and
> > the more I tend to say that they are distinct animals. Jim's PhD 
Thesis is an instance of
> > the class, but not of the concept. One subject of 'Social Functions of 
PhD Thesis in
> > Occidental University during 20th century', is the concept of PhD 
Thesis, not the class.
> > 
> > So it's not just an issue of OWL-DL vs OWL-Full, it's also an issue of 
making distinct or
> > not those two 'things'. This is a core issue in porting thesaurus to 
the SW, related to
> > others of the same kind, like if concepts A and B are interpreted as 
classes, and there is
> > a Broader-Narrower relationship between A and B in the Thesaurus, has 
it to be interpreted
> > as a class-subclass relationship in the ontology etc.
> > 
> > So I think in that case a BP definition would be two-fold
> > 
> > 1. Is it generally a BP to make terminology concepts distinct from 
ontology classes (and
> > properties)?
> > 2. If agnostic about 1, what is the trade-off when choosing to make 
them distinct or to
> > merge them ?
> > 
> > FWIW, having tried both terms of the alternative in the course of 
time, my personal view,
> > for above quoted reasons, is that they shoud be kept separate, and 
it's worth the extra
> > work (even before being aware of the DL vs Full issue)
> > 
> > Are there other concrete experience on that, not only theoretical 
considerations? Seems
> > like there are not so many people exploring the terminology-ontology 
interoperability. Or
> > are they?
> > 
> > Bernard Vatant
> > Senior Consultant
> > Knowledge Engineering
> > Mondeca - www.mondeca.com
> > bernard.vatant@mondeca.com
> > 
> > 
>