W3C home > Mailing lists > Public > public-swbp-wg@w3.org > January to March 2004

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

From: Ian Horrocks <horrocks@cs.man.ac.uk>
Date: Sat, 27 Mar 2004 12:22:10 +0000
Message-ID: <16485.29170.859539.179629@merlin.horrocks.net>
To: Christopher Welty <welty@us.ibm.com>
Cc: Bernard Vatant <bernard.vatant@mondeca.com>, Jeremy Carroll <jjc@hplb.hpl.hp.com>, SWBPD <public-swbp-wg@w3.org>, public-swbp-wg-request@w3.org

On March 25, Christopher Welty writes:
> Ian Horrocks <horrocks@cs.man.ac.uk> wrote on 03/24/2004 04:05:53 PM:
> 
> > > 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.
> > 
> > I would say that there is a big difference. Like any part of the
> > language, subClass may occasionally be abused, but it is used very
> > widely and most people seem able to use it more or less
> > correctly. 
> 
> It is very widely used, yes, but people get it wrong about as much as they 
> get it right. Since it's transitive, get one wrong near the "top" and your 
> whole ontology will be off.
> 
> > Moreover, subClass fits into a family of logics which are
> > theoretically well understood and for which there is considerable
> > implementation experience.
> 
> Yes! THAT is the reason the choice was made for OWL DL, not:
> 
> > In contrast, classes as instances are relatively rarely used (most
> > forms of conceptual modelling, databases etc., seem to have managed
> > perfectly well without them), and hardly ever used
> > "correctly". 
> 
> Well, I'm not surprised that a DL person would have this view.  However 
> the statement is simply false.  Databases have had this since at least the 
> mid-80s (see "Two Stage ER Diagrams" e.g.), and possibly earlier. Of 
> course they don't do reasoning so they don't have the kinds of problems 
> with their implementations that we do.
> 
> THe issue was also recognized quite early on in object-oriented modeling, 
> as well, and both Smalltalk and CLOS had "meta object" facilities for 
> handling it.
> 
> Outside the DL world, people building Knowledge-based systems use it all 
> the time, and I would say that the per-capita misuse is about the same as 
> it is for any other part of the language.  Clearly if you go counting 
> relations, subclass wins in sheer volume, but I can't say I have ever done 
> a serious ontology without encountering a need to model this correctly, 
> and in fact my experience is that systems like DLs actually encourage 
> people to get it wrong by forcing them to ignore the distinction.
> 
> > Moreover, the resulting logics are much less well
> > understood 
> 
> That's not true at all, unless you are conflating "understood" with:
> 
> > and there is little implementation experience.
> 
> There is less, for sure, I'm not sure I would say "litte".  There has also 
> been far less formal study of the complexity of reasoning algorithms for 
> languages that have this expressiveness but not others.  Peter and I 
> looked at this in the early 90s for neo-classic, but we never followed 
> through.  The question was, like any language feature: what would you have 
> to give up to have complete and decidable reasoning if you allowed 
> instances to have instances.  This is an open problem.  Many people just 
> throw up their hands prima facie because "2cnd order logic is incomplete 
> and undecidable".  However, it's not that simple - you can subset it just 
> as we have been doing for FOL to find decidable fragments.

You seem to agree that we know little about the complexity,
decidability or implementation of such languages. This was exactly
what I intended by "much less well understood".

Ian

> 
> > 
> > Ian
> > 
> > 
> > 
> > 
> > >  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
> > > > > 
> > > > > 
> > > > 
> > > 
> > > <br><font size=2><tt>Jeremy wrote on 03/24/2004 04:24:16 AM:<br>
> > > <br>
> > > &gt; <br>
> > > &gt; Yes, like Bernard, I have been thinking more about this, and 
> about
> > > Ian's <br>
> > > &gt; insistence in WebOnt that classes-and-instances was almost always
> > > raised by <br>
> > > &gt; people wanting to mismodel their world. (cc Ian, wondering if I 
> have
> > > learnt <br>
> > > &gt; my lessons well!, or misrepresented him)<br>
> > > </tt></font>
> > > <br><font size=2><tt>Well, &quot;mismodelling their world&quot; is not
> > > limited to classes as instances. I find it rather dangerous to make 
> such
> > > statements. &nbsp;People use subclass incorrectly, too, but that 
> wasn't
> > > a reason to remove that axiom from OWL DL. &nbsp;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.</tt></font>
> > > <br>
> > > <br><font size=2><tt>Anyway, your analysis exposed some important 
> misconceptions,
> > > espcially regarding so-called &quot;subject hierarchies&quot; and 
> class
> > > hierarchies. &nbsp;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 &quot;part&quot;onomies, or more 
> precisely
> > > spatial containment, &nbsp;not subclass (in fact, etymologically, 
> &quot;subject&quot;
> > > means to throw under, &quot;topic&quot; is a region, and 
> &quot;about&quot;
> > > means near). &nbsp;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. &nbsp;I can't seem to find a softcopy 
> myself.</tt></font>
> > > <br>
> > > <br><font size=2><tt>&gt; The class hierarchy in RDFS/OWL is there to 
> describe
> > > hierarchies of classes <br>
> > > &gt; of resources. Just because you have a hierarchy of subject 
> descriptors
> > > <br>
> > > &gt; doesn't make it a class hierarchy.<br>
> > > &gt; <br>
> > > &gt; It seems to be confusing the human way of thinking of analogy and
> > > metaphor <br>
> > > &gt; (any hierarchy can act as a metaphor for any other hierarchy) 
> with
> > > what is <br>
> > > &gt; a logical and implementation issue about how to say what we want 
> to
> > > say <br>
> > > &gt; about our knowledge of our world in a way that machines can 
> process
> > > it.<br>
> > > &gt; <br>
> > > &gt; Thus if PhDThesis is an owl:Class what are the resources that we 
> intend
> > > to <br>
> > > &gt; belong to it? Probably my PhD Thesis with title &quot;Graph 
> Grammars:
> > > an <br>
> > > &gt; approach to transfer based MT; exemplified by a Turkish-English 
> system&quot;
> > > is <br>
> > > &gt; one such resource, but the copy sitting on my bookshelf is 
> probably
> > > not.<br>
> > > &gt; <br>
> > > &gt; Then if that is the case what would we mean by dc:subject linking
> > > the <br>
> > > &gt; resource of my thesis with this class .... hmmm ... we mean my 
> thisis
> > > <br>
> > > &gt; belongs to that class, i.e. rdf:type.<br>
> > > &gt; So if we want to treat this subject hierachy as classes we really
> > > also want<br>
> > > &gt; <br>
> > > &gt; dc:creator rdf:subPropertyOf rdf:type .<br>
> > > &gt; <br>
> > > &gt; or perhaps<br>
> > > &gt; <br>
> > > &gt; eg:creator rdf:subPropertyOf rdf:type .<br>
> > > &gt; eg:creator rdf:subPropertyOf dc:creator .<br>
> > > &gt; <br>
> > > &gt; But if we click on dc:creator we get to:<br>
> > > &gt; http://purl.org/dc/elements/1.1/subject<br>
> > > &gt; <br>
> > > &gt; &lt;rdf:Property 
> rdf:about=&quot;http://purl.org/dc/elements/1.1/subject&quot;&gt;<br>
> > > &gt; &lt;rdfs:label xml:lang=&quot;en-US&quot;&gt;Subject and 
> Keywords&lt;/rdfs:
> > label&gt;<br>
> > > &gt; &lt;rdfs:comment xml:lang=&quot;en-US&quot;&gt;The topic of the 
> content
> > > of the <br>
> > > &gt; resource.&lt;/rdfs:comment&gt;<br>
> > > &gt; &lt;dc:description xml:lang=&quot;en-US&quot;&gt;<br>
> > > &gt; Typically, a Subject will be expressed as keywords,<br>
> > > &gt; key phrases or classification codes that describe a topic<br>
> > > &gt; of the resource. &nbsp;Recommended best practice is to select<br>
> > > &gt; a value from a controlled vocabulary or formal<br>
> > > &gt; classification scheme.&lt;/dc:description&gt;<br>
> > > &gt; &lt;rdfs:isDefinedBy 
> rdf:resource=&quot;http://purl.org/dc/elements/1.
> > 1/&quot;/&gt;<br>
> > > &gt; &lt;dcterms:issued&gt;1999-07-02&lt;/dcterms:issued&gt;<br>
> > > &gt; &lt;dcterms:modified&gt;2002-10-04&lt;/dcterms:modified&gt;<br>
> > > &gt; &lt;dc:type <br>
> > > &gt; rdf:resource=&quot;http://dublincore.
> > org/usage/documents/principles/#element&quot;/&gt;<br>
> > > &gt; &lt;dcterms:hasVersion <br>
> > > &gt; rdf:resource=&quot;http://dublincore.
> > org/usage/terms/history/#subject-004&quot;/&gt;<br>
> > > &gt; &lt;/rdf:Property&gt;<br>
> > > &gt; <br>
> > > &gt; and we see that dc:subject should typically be a string from a 
> controlled
> > > <br>
> > > &gt; vocabulary. Thus it seems particularly poor practice to deviate 
> from
> > > the <br>
> > > &gt; preferred usage of dc:subject in order to (over-)simplify our 
> model.<br>
> > > &gt; <br>
> > > &gt; This points to the solution I was earlier advocating of using 
> such
> > > strings, <br>
> > > &gt; using hasValue restrictions to map the strings into classes and 
> then
> > > using <br>
> > > &gt; the class hierachy on those restrictions to show the hierarchical
> > > <br>
> > > &gt; relationships between the subject vocab terms. To do this well, 
> we
> > > probably <br>
> > > &gt; want to specialise the dc:subject property with a subproperty 
> eg:subject,
> > > <br>
> > > &gt; specify its range with an owl:Datarange explicitly enumerating 
> the
> > > <br>
> > > &gt; controlled vocabulary, and for each term create a class using a 
> hasValue
> > > <br>
> > > &gt; restriction.<br>
> > > &gt; For further clarity and usablility we might want to create two 
> related
> > > <br>
> > > &gt; properties, one indicating the (single) intended subject code, 
> and
> > > the <br>
> > > &gt; other indicating all implicit subject codes formed from the class
> > > hierachy.<br>
> > > &gt; The former would be a subproperty of both the latter and 
> dc:subject;
> > > the <br>
> > > &gt; latter would be used to create the hasValue restrictions.<br>
> > > &gt; <br>
> > > &gt; Hmmm ... quite a lot of work initially, but the end result is 
> that
> > > the <br>
> > > &gt; subject indicators are marked up using text strings from an 
> explicit
> > > <br>
> > > &gt; controlled vocab; we conform with the defn of dc:subject, even 
> with
> > > the <br>
> > > &gt; advertised best practice; we fall within OWL DL with the 
> expectation
> > > that <br>
> > > &gt; this will give us better reasoning performance, and we have been 
> clearer
> > > <br>
> > > &gt; about we are trying to say. I think the complexity can be hidden 
> from
> > > the <br>
> > > &gt; end users.<br>
> > > &gt; <br>
> > > &gt; Jeremy<br>
> > > &gt; <br>
> > > &gt; <br>
> > > &gt; <br>
> > > &gt; <br>
> > > &gt; <br>
> > > &gt; <br>
> > > &gt; <br>
> > > &gt; <br>
> > > &gt; <br>
> > > &gt; Bernard Vatant wrote:<br>
> > > &gt; &gt; <br>
> > > &gt; &gt; *BV<br>
> > > &gt; &gt; <br>
> > > &gt; &gt;&gt;&gt;- Is it worth the trade-off to switch one's ontology 
> (otherwise
> > > DL)<br>
> > > &gt; &gt;&gt;&gt;to OWL-Full, just to<br>
> > > &gt; &gt;&gt;&gt;allow its classes to be used as objects in 
> 'dc:subject'
> > > predicates?<br>
> > > &gt; &gt; <br>
> > > &gt; &gt; <br>
> > > &gt; &gt; *Jim<br>
> > > &gt; &gt; <br>
> > > &gt; &gt;&gt;That's a weird way to ask the question. &nbsp;You mean, 
> is
> > > it worth doing<br>
> > > &gt; &gt;&gt;the extra work to break your naturally occuring model 
> just
> > > so that<br>
> > > &gt; &gt;&gt;you can be in DL?<br>
> > > &gt; &gt; <br>
> > > &gt; &gt; <br>
> > > &gt; &gt; The way I put it might seem weird indeed, but it's the way 
> it
> > > was set in the real project<br>
> > > &gt; &gt; context (real world is weird). We had an OWL-DL ontology, 
> and
> > > wanted to keep it so, and<br>
> > > &gt; &gt; suddenly after six months or so some user wants to be able 
> to
> > > use a class as a subject of<br>
> > > &gt; &gt; a document ... which is one case out of one thousand, the 
> 999
> > > others using 'regular'<br>
> > > &gt; &gt; subjects. So using a class as subject of a document is not 
> exactly
> > > 'naturally occuring'.<br>
> > > &gt; &gt; It's a borderline case - not to say a weird one :))<br>
> > > &gt; &gt; <br>
> > > &gt; &gt; *Jim<br>
> > > &gt; &gt; <br>
> > > &gt; &gt;&gt;I would argue this is indeed a BP issue, but probably for
> > > WORLD not<br>
> > > &gt; &gt;&gt;for OPEN... we need to explain why and when you would do 
> the
> > > extra<br>
> > > &gt; &gt;&gt;work (and in every case we have explored it is extra 
> work)
> > > to make<br>
> > > &gt; &gt;&gt;sure your ontology is in the DL profile of OWL.<br>
> > > &gt; &gt; <br>
> > > &gt; &gt; <br>
> > > &gt; &gt; I suggested it might be in PORT scope, because it deals with
> > > the terminology vs ontology<br>
> > > &gt; &gt; general issue. For me the heart of the question is to know 
> what
> > > it means to 'use a<br>
> > > &gt; &gt; concept' defined in a terminology (glossary, thesaurus, 
> subject
> > > headings, index...) as a<br>
> > > &gt; &gt; class (or a property) in an ontology.<br>
> > > &gt; &gt; <br>
> > > &gt; &gt; Is 'PhD Thesis' class the same 'subject' (using TM language 
> here,
> > > sorry) or 'resource'<br>
> > > &gt; &gt; than the original concept? The more I think about it, the 
> more
> > > I have to deal with it, and<br>
> > > &gt; &gt; the more I tend to say that they are distinct animals. Jim's
> > > PhD Thesis is an instance of<br>
> > > &gt; &gt; the class, but not of the concept. One subject of 'Social 
> Functions
> > > of PhD Thesis in<br>
> > > &gt; &gt; Occidental University during 20th century', is the concept 
> of
> > > PhD Thesis, not the class.<br>
> > > &gt; &gt; <br>
> > > &gt; &gt; So it's not just an issue of OWL-DL vs OWL-Full, it's also 
> an
> > > issue of making distinct or<br>
> > > &gt; &gt; not those two 'things'. This is a core issue in porting 
> thesaurus
> > > to the SW, related to<br>
> > > &gt; &gt; others of the same kind, like if concepts A and B are 
> interpreted
> > > as classes, and there is<br>
> > > &gt; &gt; a Broader-Narrower relationship between A and B in the 
> Thesaurus,
> > > has it to be interpreted<br>
> > > &gt; &gt; as a class-subclass relationship in the ontology etc.<br>
> > > &gt; &gt; <br>
> > > &gt; &gt; So I think in that case a BP definition would be 
> two-fold<br>
> > > &gt; &gt; <br>
> > > &gt; &gt; 1. Is it generally a BP to make terminology concepts 
> distinct
> > > from ontology classes (and<br>
> > > &gt; &gt; properties)?<br>
> > > &gt; &gt; 2. If agnostic about 1, what is the trade-off when choosing 
> to
> > > make them distinct or to<br>
> > > &gt; &gt; merge them ?<br>
> > > &gt; &gt; <br>
> > > &gt; &gt; FWIW, having tried both terms of the alternative in the 
> course
> > > of time, my personal view,<br>
> > > &gt; &gt; for above quoted reasons, is that they shoud be kept 
> separate,
> > > and it's worth the extra<br>
> > > &gt; &gt; work (even before being aware of the DL vs Full issue)<br>
> > > &gt; &gt; <br>
> > > &gt; &gt; Are there other concrete experience on that, not only 
> theoretical
> > > considerations? Seems<br>
> > > &gt; &gt; like there are not so many people exploring the 
> terminology-ontology
> > > interoperability. Or<br>
> > > &gt; &gt; are they?<br>
> > > &gt; &gt; <br>
> > > &gt; &gt; Bernard Vatant<br>
> > > &gt; &gt; Senior Consultant<br>
> > > &gt; &gt; Knowledge Engineering<br>
> > > &gt; &gt; Mondeca - www.mondeca.com<br>
> > > &gt; &gt; bernard.vatant@mondeca.com<br>
> > > &gt; &gt; <br>
> > > &gt; &gt; <br>
> > > &gt; <br>
> > > </tt></font>
> 
> <br><font size=2><tt>Ian Horrocks &lt;horrocks@cs.man.ac.uk&gt; wrote on
> 03/24/2004 04:05:53 PM:<br>
> <br>
> &gt; &gt; Well, &quot;mismodelling their world&quot; is not limited to
> classes as instances. I <br>
> &gt; &gt; find it rather dangerous to make such statements. &nbsp;People
> use subclass <br>
> &gt; &gt; incorrectly, too, but that wasn't a reason to remove that axiom
> from OWL <br>
> &gt; &gt; DL.<br>
> &gt; <br>
> &gt; I would say that there is a big difference. Like any part of the<br>
> &gt; language, subClass may occasionally be abused, but it is used very<br>
> &gt; widely and most people seem able to use it more or less<br>
> &gt; correctly. </tt></font>
> <br>
> <br><font size=2><tt>It is very widely used, yes, but people get it wrong
> about as much as they get it right. Since it's transitive, get one wrong
> near the &quot;top&quot; and your whole ontology will be off.</tt></font>
> <br>
> <br><font size=2><tt>&gt; Moreover, subClass fits into a family of logics
> which are<br>
> &gt; theoretically well understood and for which there is considerable<br>
> &gt; implementation experience.<br>
> </tt></font>
> <br><font size=2><tt>Yes! THAT is the reason the choice was made for OWL
> DL, not:</tt></font>
> <br><font size=2><tt><br>
> &gt; In contrast, classes as instances are relatively rarely used (most<br>
> &gt; forms of conceptual modelling, databases etc., seem to have managed<br>
> &gt; perfectly well without them), and hardly ever used<br>
> &gt; &quot;correctly&quot;. </tt></font>
> <br>
> <br><font size=2><tt>Well, I'm not surprised that a DL person would have
> this view. &nbsp;However the statement is simply false. &nbsp;Databases
> have had this since at least the mid-80s (see &quot;Two Stage ER Diagrams&quot;
> e.g.), and possibly earlier. Of course they don't do reasoning so they
> don't have the kinds of problems with their implementations that we do.</tt></font>
> <br>
> <br><font size=2><tt>THe issue was also recognized quite early on in object-oriented
> modeling, as well, and both Smalltalk and CLOS had &quot;meta object&quot;
> facilities for handling it.</tt></font>
> <br>
> <br><font size=2><tt>Outside the DL world, people building Knowledge-based
> systems use it all the time, and I would say that the per-capita misuse
> is about the same as it is for any other part of the language. &nbsp;Clearly
> if you go counting relations, subclass wins in sheer volume, but I can't
> say I have ever done a serious ontology without encountering a need to
> model this correctly, and in fact my experience is that systems like DLs
> actually encourage people to get it wrong by forcing them to ignore the
> distinction.</tt></font>
> <br>
> <br><font size=2><tt>&gt; Moreover, the resulting logics are much less
> well<br>
> &gt; understood </tt></font>
> <br>
> <br><font size=2><tt>That's not true at all, unless you are conflating
> &quot;understood&quot; with:</tt></font>
> <br>
> <br><font size=2><tt>&gt; and there is little implementation experience.<br>
> </tt></font>
> <br><font size=2><tt>There is less, for sure, I'm not sure I would say
> &quot;litte&quot;. &nbsp;There has also been far less formal study of the
> complexity of reasoning algorithms for languages that have this expressiveness
> but not others. &nbsp;Peter and I looked at this in the early 90s for neo-classic,
> but we never followed through. &nbsp;The question was, like any language
> feature: what would you have to give up to have complete and decidable
> reasoning if you allowed instances to have instances. &nbsp;This is an
> open problem. &nbsp;Many people just throw up their hands prima facie because
> &quot;2cnd order logic is incomplete and undecidable&quot;. &nbsp;However,
> it's not that simple - you can subset it just as we have been doing for
> FOL to find decidable fragments.</tt></font>
> <br>
> <br><font size=2><tt>&gt; <br>
> &gt; Ian<br>
> &gt; <br>
> &gt; <br>
> &gt; <br>
> &gt; <br>
> &gt; &gt; &nbsp;People just mismodel their worlds, I hope we can offer
> some advice on <br>
> &gt; &gt; both how to do some of these things and how NOT to do it.<br>
> &gt; &gt; <br>
> &gt; &gt; Anyway, your analysis exposed some important misconceptions,
> espcially <br>
> &gt; &gt; regarding so-called &quot;subject hierarchies&quot; and class
> hierarchies. &nbsp;I've <br>
> &gt; &gt; written a paper or two about the problem, in this one: <br>
> &gt; &gt; [http://dx.doi.org/10.1016/S0169-023X(99)90021-6] I basically
> show that <br>
> &gt; &gt; subject taxonomies are actually &quot;part&quot;onomies, or more
> precisely spatial <br>
> &gt; &gt; containment, &nbsp;not subclass (in fact, etymologically, &quot;subject&quot;
> means to <br>
> &gt; &gt; throw under, &quot;topic&quot; is a region, and &quot;about&quot;
> means near). &nbsp;Some of the <br>
> &gt; &gt; initial problems of representing subject taxonomies in DLs are
> discussed <br>
> &gt; &gt; in a paper in the first FOIS conference, which may be hard to
> find. &nbsp;I <br>
> &gt; &gt; can't seem to find a softcopy myself.<br>
> &gt; &gt; <br>
> &gt; &gt; &gt; The class hierarchy in RDFS/OWL is there to describe hierarchies
> of <br>
> &gt; &gt; classes <br>
> &gt; &gt; &gt; of resources. Just because you have a hierarchy of subject
> descriptors <br>
> &gt; &gt; &gt; doesn't make it a class hierarchy.<br>
> &gt; &gt; &gt; <br>
> &gt; &gt; &gt; It seems to be confusing the human way of thinking of analogy
> and <br>
> &gt; &gt; metaphor <br>
> &gt; &gt; &gt; (any hierarchy can act as a metaphor for any other hierarchy)
> with what <br>
> &gt; &gt; is <br>
> &gt; &gt; &gt; a logical and implementation issue about how to say what
> we want to say <br>
> &gt; &gt; &gt; about our knowledge of our world in a way that machines
> can process it.<br>
> &gt; &gt; &gt; <br>
> &gt; &gt; &gt; Thus if PhDThesis is an owl:Class what are the resources
> that we intend <br>
> &gt; &gt; to <br>
> &gt; &gt; &gt; belong to it? Probably my PhD Thesis with title &quot;Graph
> Grammars: an <br>
> &gt; &gt; &gt; approach to transfer based MT; exemplified by a Turkish-English
> system&quot; <br>
> &gt; &gt; is <br>
> &gt; &gt; &gt; one such resource, but the copy sitting on my bookshelf
> is probably not.<br>
> &gt; &gt; &gt; <br>
> &gt; &gt; &gt; Then if that is the case what would we mean by dc:subject
> linking the <br>
> &gt; &gt; &gt; resource of my thesis with this class .... hmmm ... we mean
> my thisis <br>
> &gt; &gt; &gt; belongs to that class, i.e. rdf:type.<br>
> &gt; &gt; &gt; So if we want to treat this subject hierachy as classes
> we really also <br>
> &gt; &gt; want<br>
> &gt; &gt; &gt; <br>
> &gt; &gt; &gt; dc:creator rdf:subPropertyOf rdf:type .<br>
> &gt; &gt; &gt; <br>
> &gt; &gt; &gt; or perhaps<br>
> &gt; &gt; &gt; <br>
> &gt; &gt; &gt; eg:creator rdf:subPropertyOf rdf:type .<br>
> &gt; &gt; &gt; eg:creator rdf:subPropertyOf dc:creator .<br>
> &gt; &gt; &gt; <br>
> &gt; &gt; &gt; But if we click on dc:creator we get to:<br>
> &gt; &gt; &gt; http://purl.org/dc/elements/1.1/subject<br>
> &gt; &gt; &gt; <br>
> &gt; &gt; &gt; &lt;rdf:Property rdf:about=&quot;http://purl.org/dc/elements/1.1/subject&quot;&gt;<br>
> &gt; &gt; &gt; &lt;rdfs:label xml:lang=&quot;en-US&quot;&gt;Subject and
> Keywords&lt;/rdfs:label&gt;<br>
> &gt; &gt; &gt; &lt;rdfs:comment xml:lang=&quot;en-US&quot;&gt;The topic
> of the content of the <br>
> &gt; &gt; &gt; resource.&lt;/rdfs:comment&gt;<br>
> &gt; &gt; &gt; &lt;dc:description xml:lang=&quot;en-US&quot;&gt;<br>
> &gt; &gt; &gt; Typically, a Subject will be expressed as keywords,<br>
> &gt; &gt; &gt; key phrases or classification codes that describe a topic<br>
> &gt; &gt; &gt; of the resource. &nbsp;Recommended best practice is to select<br>
> &gt; &gt; &gt; a value from a controlled vocabulary or formal<br>
> &gt; &gt; &gt; classification scheme.&lt;/dc:description&gt;<br>
> &gt; &gt; &gt; &lt;rdfs:isDefinedBy rdf:resource=&quot;http://purl.org/dc/elements/1.1/&quot;/&gt;<br>
> &gt; &gt; &gt; &lt;dcterms:issued&gt;1999-07-02&lt;/dcterms:issued&gt;<br>
> &gt; &gt; &gt; &lt;dcterms:modified&gt;2002-10-04&lt;/dcterms:modified&gt;<br>
> &gt; &gt; &gt; &lt;dc:type <br>
> &gt; &gt; &gt; <br>
> &gt; &gt; rdf:resource=&quot;http://dublincore.org/usage/documents/principles/#element&quot;/&gt;<br>
> &gt; &gt; &gt; &lt;dcterms:hasVersion <br>
> &gt; &gt; &gt; rdf:resource=&quot;http://dublincore.org/usage/terms/history/#subject-004&quot;/&gt;<br>
> &gt; &gt; &gt; &lt;/rdf:Property&gt;<br>
> &gt; &gt; &gt; <br>
> &gt; &gt; &gt; and we see that dc:subject should typically be a string
> from a <br>
> &gt; &gt; controlled <br>
> &gt; &gt; &gt; vocabulary. Thus it seems particularly poor practice to
> deviate from the <br>
> &gt; &gt; <br>
> &gt; &gt; &gt; preferred usage of dc:subject in order to (over-)simplify
> our model.<br>
> &gt; &gt; &gt; <br>
> &gt; &gt; &gt; This points to the solution I was earlier advocating of
> using such <br>
> &gt; &gt; strings, <br>
> &gt; &gt; &gt; using hasValue restrictions to map the strings into classes
> and then <br>
> &gt; &gt; using <br>
> &gt; &gt; &gt; the class hierachy on those restrictions to show the hierarchical
> <br>
> &gt; &gt; &gt; relationships between the subject vocab terms. To do this
> well, we <br>
> &gt; &gt; probably <br>
> &gt; &gt; &gt; want to specialise the dc:subject property with a subproperty
> <br>
> &gt; &gt; eg:subject, <br>
> &gt; &gt; &gt; specify its range with an owl:Datarange explicitly enumerating
> the <br>
> &gt; &gt; &gt; controlled vocabulary, and for each term create a class
> using a hasValue <br>
> &gt; &gt; <br>
> &gt; &gt; &gt; restriction.<br>
> &gt; &gt; &gt; For further clarity and usablility we might want to create
> two related <br>
> &gt; &gt; &gt; properties, one indicating the (single) intended subject
> code, and the <br>
> &gt; &gt; &gt; other indicating all implicit subject codes formed from
> the class <br>
> &gt; &gt; hierachy.<br>
> &gt; &gt; &gt; The former would be a subproperty of both the latter and
> dc:subject; the <br>
> &gt; &gt; <br>
> &gt; &gt; &gt; latter would be used to create the hasValue restrictions.<br>
> &gt; &gt; &gt; <br>
> &gt; &gt; &gt; Hmmm ... quite a lot of work initially, but the end result
> is that the <br>
> &gt; &gt; &gt; subject indicators are marked up using text strings from
> an explicit <br>
> &gt; &gt; &gt; controlled vocab; we conform with the defn of dc:subject,
> even with the <br>
> &gt; &gt; &gt; advertised best practice; we fall within OWL DL with the
> expectation <br>
> &gt; &gt; that <br>
> &gt; &gt; &gt; this will give us better reasoning performance, and we have
> been clearer <br>
> &gt; &gt; <br>
> &gt; &gt; &gt; about we are trying to say. I think the complexity can be
> hidden from <br>
> &gt; &gt; the <br>
> &gt; &gt; &gt; end users.<br>
> &gt; &gt; &gt; <br>
> &gt; &gt; &gt; Jeremy<br>
> &gt; &gt; &gt; <br>
> &gt; &gt; &gt; <br>
> &gt; &gt; &gt; <br>
> &gt; &gt; &gt; <br>
> &gt; &gt; &gt; <br>
> &gt; &gt; &gt; <br>
> &gt; &gt; &gt; <br>
> &gt; &gt; &gt; <br>
> &gt; &gt; &gt; <br>
> &gt; &gt; &gt; Bernard Vatant wrote:<br>
> &gt; &gt; &gt; &gt; <br>
> &gt; &gt; &gt; &gt; *BV<br>
> &gt; &gt; &gt; &gt; <br>
> &gt; &gt; &gt; &gt;&gt;&gt;- Is it worth the trade-off to switch one's
> ontology (otherwise DL)<br>
> &gt; &gt; &gt; &gt;&gt;&gt;to OWL-Full, just to<br>
> &gt; &gt; &gt; &gt;&gt;&gt;allow its classes to be used as objects in 'dc:subject'
> predicates?<br>
> &gt; &gt; &gt; &gt; <br>
> &gt; &gt; &gt; &gt; <br>
> &gt; &gt; &gt; &gt; *Jim<br>
> &gt; &gt; &gt; &gt; <br>
> &gt; &gt; &gt; &gt;&gt;That's a weird way to ask the question. &nbsp;You
> mean, is it worth doing<br>
> &gt; &gt; &gt; &gt;&gt;the extra work to break your naturally occuring
> model just so that<br>
> &gt; &gt; &gt; &gt;&gt;you can be in DL?<br>
> &gt; &gt; &gt; &gt; <br>
> &gt; &gt; &gt; &gt; <br>
> &gt; &gt; &gt; &gt; The way I put it might seem weird indeed, but it's
> the way it was set <br>
> &gt; &gt; in the real project<br>
> &gt; &gt; &gt; &gt; context (real world is weird). We had an OWL-DL ontology,
> and wanted <br>
> &gt; &gt; to keep it so, and<br>
> &gt; &gt; &gt; &gt; suddenly after six months or so some user wants to
> be able to use a <br>
> &gt; &gt; class as a subject of<br>
> &gt; &gt; &gt; &gt; a document ... which is one case out of one thousand,
> the 999 others <br>
> &gt; &gt; using 'regular'<br>
> &gt; &gt; &gt; &gt; subjects. So using a class as subject of a document
> is not exactly <br>
> &gt; &gt; 'naturally occuring'.<br>
> &gt; &gt; &gt; &gt; It's a borderline case - not to say a weird one :))<br>
> &gt; &gt; &gt; &gt; <br>
> &gt; &gt; &gt; &gt; *Jim<br>
> &gt; &gt; &gt; &gt; <br>
> &gt; &gt; &gt; &gt;&gt;I would argue this is indeed a BP issue, but probably
> for WORLD not<br>
> &gt; &gt; &gt; &gt;&gt;for OPEN... we need to explain why and when you
> would do the extra<br>
> &gt; &gt; &gt; &gt;&gt;work (and in every case we have explored it is extra
> work) to make<br>
> &gt; &gt; &gt; &gt;&gt;sure your ontology is in the DL profile of OWL.<br>
> &gt; &gt; &gt; &gt; <br>
> &gt; &gt; &gt; &gt; <br>
> &gt; &gt; &gt; &gt; I suggested it might be in PORT scope, because it deals
> with the <br>
> &gt; &gt; terminology vs ontology<br>
> &gt; &gt; &gt; &gt; general issue. For me the heart of the question is
> to know what it <br>
> &gt; &gt; means to 'use a<br>
> &gt; &gt; &gt; &gt; concept' defined in a terminology (glossary, thesaurus,
> subject <br>
> &gt; &gt; headings, index...) as a<br>
> &gt; &gt; &gt; &gt; class (or a property) in an ontology.<br>
> &gt; &gt; &gt; &gt; <br>
> &gt; &gt; &gt; &gt; Is 'PhD Thesis' class the same 'subject' (using TM
> language here, <br>
> &gt; &gt; sorry) or 'resource'<br>
> &gt; &gt; &gt; &gt; than the original concept? The more I think about it,
> the more I have <br>
> &gt; &gt; to deal with it, and<br>
> &gt; &gt; &gt; &gt; the more I tend to say that they are distinct animals.
> Jim's PhD <br>
> &gt; &gt; Thesis is an instance of<br>
> &gt; &gt; &gt; &gt; the class, but not of the concept. One subject of 'Social
> Functions of <br>
> &gt; &gt; PhD Thesis in<br>
> &gt; &gt; &gt; &gt; Occidental University during 20th century', is the
> concept of PhD <br>
> &gt; &gt; Thesis, not the class.<br>
> &gt; &gt; &gt; &gt; <br>
> &gt; &gt; &gt; &gt; So it's not just an issue of OWL-DL vs OWL-Full, it's
> also an issue of <br>
> &gt; &gt; making distinct or<br>
> &gt; &gt; &gt; &gt; not those two 'things'. This is a core issue in porting
> thesaurus to <br>
> &gt; &gt; the SW, related to<br>
> &gt; &gt; &gt; &gt; others of the same kind, like if concepts A and B are
> interpreted as <br>
> &gt; &gt; classes, and there is<br>
> &gt; &gt; &gt; &gt; a Broader-Narrower relationship between A and B in
> the Thesaurus, has <br>
> &gt; &gt; it to be interpreted<br>
> &gt; &gt; &gt; &gt; as a class-subclass relationship in the ontology etc.<br>
> &gt; &gt; &gt; &gt; <br>
> &gt; &gt; &gt; &gt; So I think in that case a BP definition would be two-fold<br>
> &gt; &gt; &gt; &gt; <br>
> &gt; &gt; &gt; &gt; 1. Is it generally a BP to make terminology concepts
> distinct from <br>
> &gt; &gt; ontology classes (and<br>
> &gt; &gt; &gt; &gt; properties)?<br>
> &gt; &gt; &gt; &gt; 2. If agnostic about 1, what is the trade-off when
> choosing to make <br>
> &gt; &gt; them distinct or to<br>
> &gt; &gt; &gt; &gt; merge them ?<br>
> &gt; &gt; &gt; &gt; <br>
> &gt; &gt; &gt; &gt; FWIW, having tried both terms of the alternative in
> the course of <br>
> &gt; &gt; time, my personal view,<br>
> &gt; &gt; &gt; &gt; for above quoted reasons, is that they shoud be kept
> separate, and <br>
> &gt; &gt; it's worth the extra<br>
> &gt; &gt; &gt; &gt; work (even before being aware of the DL vs Full issue)<br>
> &gt; &gt; &gt; &gt; <br>
> &gt; &gt; &gt; &gt; Are there other concrete experience on that, not only
> theoretical <br>
> &gt; &gt; considerations? Seems<br>
> &gt; &gt; &gt; &gt; like there are not so many people exploring the terminology-ontology
> <br>
> &gt; &gt; interoperability. Or<br>
> &gt; &gt; &gt; &gt; are they?<br>
> &gt; &gt; &gt; &gt; <br>
> &gt; &gt; &gt; &gt; Bernard Vatant<br>
> &gt; &gt; &gt; &gt; Senior Consultant<br>
> &gt; &gt; &gt; &gt; Knowledge Engineering<br>
> &gt; &gt; &gt; &gt; Mondeca - www.mondeca.com<br>
> &gt; &gt; &gt; &gt; bernard.vatant@mondeca.com<br>
> &gt; &gt; &gt; &gt; <br>
> &gt; &gt; &gt; &gt; <br>
> &gt; &gt; &gt; <br>
> &gt; &gt; <br>
> &gt; &gt; &lt;br&gt;&lt;font size=2&gt;&lt;tt&gt;Jeremy wrote on 03/24/2004
> 04:24:16 AM:&lt;br&gt;<br>
> &gt; &gt; &lt;br&gt;<br>
> &gt; &gt; &amp;gt; &lt;br&gt;<br>
> &gt; &gt; &amp;gt; Yes, like Bernard, I have been thinking more about this,
> and about<br>
> &gt; &gt; Ian's &lt;br&gt;<br>
> &gt; &gt; &amp;gt; insistence in WebOnt that classes-and-instances was
> almost always<br>
> &gt; &gt; raised by &lt;br&gt;<br>
> &gt; &gt; &amp;gt; people wanting to mismodel their world. (cc Ian, wondering
> if I have<br>
> &gt; &gt; learnt &lt;br&gt;<br>
> &gt; &gt; &amp;gt; my lessons well!, or misrepresented him)&lt;br&gt;<br>
> &gt; &gt; &lt;/tt&gt;&lt;/font&gt;<br>
> &gt; &gt; &lt;br&gt;&lt;font size=2&gt;&lt;tt&gt;Well, &amp;quot;mismodelling
> their world&amp;quot; is not<br>
> &gt; &gt; limited to classes as instances. I find it rather dangerous to
> make such<br>
> &gt; &gt; statements. &amp;nbsp;People use subclass incorrectly, too, but
> that wasn't<br>
> &gt; &gt; a reason to remove that axiom from OWL DL. &amp;nbsp;People just
> mismodel their<br>
> &gt; &gt; worlds, I hope we can offer some advice on both how to do some
> of these<br>
> &gt; &gt; things and how NOT to do it.&lt;/tt&gt;&lt;/font&gt;<br>
> &gt; &gt; &lt;br&gt;<br>
> &gt; &gt; &lt;br&gt;&lt;font size=2&gt;&lt;tt&gt;Anyway, your analysis
> exposed some important misconceptions,<br>
> &gt; &gt; espcially regarding so-called &amp;quot;subject hierarchies&amp;quot;
> and class<br>
> &gt; &gt; hierarchies. &amp;nbsp;I've written a paper or two about the
> problem, in this<br>
> &gt; &gt; one: [http://dx.doi.org/10.1016/S0169-023X(99)90021-6] I basically
> show<br>
> &gt; &gt; that subject taxonomies are actually &amp;quot;part&amp;quot;onomies,
> or more precisely<br>
> &gt; &gt; spatial containment, &amp;nbsp;not subclass (in fact, etymologically,
> &amp;quot;subject&amp;quot;<br>
> &gt; &gt; means to throw under, &amp;quot;topic&amp;quot; is a region,
> and &amp;quot;about&amp;quot;<br>
> &gt; &gt; means near). &amp;nbsp;Some of the initial problems of representing
> subject<br>
> &gt; &gt; taxonomies in DLs are discussed in a paper in the first FOIS
> conference,<br>
> &gt; &gt; which may be hard to find. &amp;nbsp;I can't seem to find a softcopy
> myself.&lt;/tt&gt;&lt;/font&gt;<br>
> &gt; &gt; &lt;br&gt;<br>
> &gt; &gt; &lt;br&gt;&lt;font size=2&gt;&lt;tt&gt;&amp;gt; The class hierarchy
> in RDFS/OWL is there to describe<br>
> &gt; &gt; hierarchies of classes &lt;br&gt;<br>
> &gt; &gt; &amp;gt; of resources. Just because you have a hierarchy of subject
> descriptors<br>
> &gt; &gt; &lt;br&gt;<br>
> &gt; &gt; &amp;gt; doesn't make it a class hierarchy.&lt;br&gt;<br>
> &gt; &gt; &amp;gt; &lt;br&gt;<br>
> &gt; &gt; &amp;gt; It seems to be confusing the human way of thinking of
> analogy and<br>
> &gt; &gt; metaphor &lt;br&gt;<br>
> &gt; &gt; &amp;gt; (any hierarchy can act as a metaphor for any other hierarchy)
> with<br>
> &gt; &gt; what is &lt;br&gt;<br>
> &gt; &gt; &amp;gt; a logical and implementation issue about how to say
> what we want to<br>
> &gt; &gt; say &lt;br&gt;<br>
> &gt; &gt; &amp;gt; about our knowledge of our world in a way that machines
> can process<br>
> &gt; &gt; it.&lt;br&gt;<br>
> &gt; &gt; &amp;gt; &lt;br&gt;<br>
> &gt; &gt; &amp;gt; Thus if PhDThesis is an owl:Class what are the resources
> that we intend<br>
> &gt; &gt; to &lt;br&gt;<br>
> &gt; &gt; &amp;gt; belong to it? Probably my PhD Thesis with title &amp;quot;Graph
> Grammars:<br>
> &gt; &gt; an &lt;br&gt;<br>
> &gt; &gt; &amp;gt; approach to transfer based MT; exemplified by a Turkish-English
> system&amp;quot;<br>
> &gt; &gt; is &lt;br&gt;<br>
> &gt; &gt; &amp;gt; one such resource, but the copy sitting on my bookshelf
> is probably<br>
> &gt; &gt; not.&lt;br&gt;<br>
> &gt; &gt; &amp;gt; &lt;br&gt;<br>
> &gt; &gt; &amp;gt; Then if that is the case what would we mean by dc:subject
> linking<br>
> &gt; &gt; the &lt;br&gt;<br>
> &gt; &gt; &amp;gt; resource of my thesis with this class .... hmmm ...
> we mean my thisis<br>
> &gt; &gt; &lt;br&gt;<br>
> &gt; &gt; &amp;gt; belongs to that class, i.e. rdf:type.&lt;br&gt;<br>
> &gt; &gt; &amp;gt; So if we want to treat this subject hierachy as classes
> we really<br>
> &gt; &gt; also want&lt;br&gt;<br>
> &gt; &gt; &amp;gt; &lt;br&gt;<br>
> &gt; &gt; &amp;gt; dc:creator rdf:subPropertyOf rdf:type .&lt;br&gt;<br>
> &gt; &gt; &amp;gt; &lt;br&gt;<br>
> &gt; &gt; &amp;gt; or perhaps&lt;br&gt;<br>
> &gt; &gt; &amp;gt; &lt;br&gt;<br>
> &gt; &gt; &amp;gt; eg:creator rdf:subPropertyOf rdf:type .&lt;br&gt;<br>
> &gt; &gt; &amp;gt; eg:creator rdf:subPropertyOf dc:creator .&lt;br&gt;<br>
> &gt; &gt; &amp;gt; &lt;br&gt;<br>
> &gt; &gt; &amp;gt; But if we click on dc:creator we get to:&lt;br&gt;<br>
> &gt; &gt; &amp;gt; http://purl.org/dc/elements/1.1/subject&lt;br&gt;<br>
> &gt; &gt; &amp;gt; &lt;br&gt;<br>
> &gt; &gt; &amp;gt; &amp;lt;rdf:Property rdf:about=&amp;quot;http://purl.org/dc/elements/1.1/subject&amp;quot;&amp;gt;&lt;br&gt;<br>
> &gt; &gt; &amp;gt; &amp;lt;rdfs:label xml:lang=&amp;quot;en-US&amp;quot;&amp;gt;Subject
> and Keywords&amp;lt;/rdfs:<br>
> &gt; label&amp;gt;&lt;br&gt;<br>
> &gt; &gt; &amp;gt; &amp;lt;rdfs:comment xml:lang=&amp;quot;en-US&amp;quot;&amp;gt;The
> topic of the content<br>
> &gt; &gt; of the &lt;br&gt;<br>
> &gt; &gt; &amp;gt; resource.&amp;lt;/rdfs:comment&amp;gt;&lt;br&gt;<br>
> &gt; &gt; &amp;gt; &amp;lt;dc:description xml:lang=&amp;quot;en-US&amp;quot;&amp;gt;&lt;br&gt;<br>
> &gt; &gt; &amp;gt; Typically, a Subject will be expressed as keywords,&lt;br&gt;<br>
> &gt; &gt; &amp;gt; key phrases or classification codes that describe a
> topic&lt;br&gt;<br>
> &gt; &gt; &amp;gt; of the resource. &amp;nbsp;Recommended best practice
> is to select&lt;br&gt;<br>
> &gt; &gt; &amp;gt; a value from a controlled vocabulary or formal&lt;br&gt;<br>
> &gt; &gt; &amp;gt; classification scheme.&amp;lt;/dc:description&amp;gt;&lt;br&gt;<br>
> &gt; &gt; &amp;gt; &amp;lt;rdfs:isDefinedBy rdf:resource=&amp;quot;http://purl.org/dc/elements/1.<br>
> &gt; 1/&amp;quot;/&amp;gt;&lt;br&gt;<br>
> &gt; &gt; &amp;gt; &amp;lt;dcterms:issued&amp;gt;1999-07-02&amp;lt;/dcterms:issued&amp;gt;&lt;br&gt;<br>
> &gt; &gt; &amp;gt; &amp;lt;dcterms:modified&amp;gt;2002-10-04&amp;lt;/dcterms:modified&amp;gt;&lt;br&gt;<br>
> &gt; &gt; &amp;gt; &amp;lt;dc:type &lt;br&gt;<br>
> &gt; &gt; &amp;gt; rdf:resource=&amp;quot;http://dublincore.<br>
> &gt; org/usage/documents/principles/#element&amp;quot;/&amp;gt;&lt;br&gt;<br>
> &gt; &gt; &amp;gt; &amp;lt;dcterms:hasVersion &lt;br&gt;<br>
> &gt; &gt; &amp;gt; rdf:resource=&amp;quot;http://dublincore.<br>
> &gt; org/usage/terms/history/#subject-004&amp;quot;/&amp;gt;&lt;br&gt;<br>
> &gt; &gt; &amp;gt; &amp;lt;/rdf:Property&amp;gt;&lt;br&gt;<br>
> &gt; &gt; &amp;gt; &lt;br&gt;<br>
> &gt; &gt; &amp;gt; and we see that dc:subject should typically be a string
> from a controlled<br>
> &gt; &gt; &lt;br&gt;<br>
> &gt; &gt; &amp;gt; vocabulary. Thus it seems particularly poor practice
> to deviate from<br>
> &gt; &gt; the &lt;br&gt;<br>
> &gt; &gt; &amp;gt; preferred usage of dc:subject in order to (over-)simplify
> our model.&lt;br&gt;<br>
> &gt; &gt; &amp;gt; &lt;br&gt;<br>
> &gt; &gt; &amp;gt; This points to the solution I was earlier advocating
> of using such<br>
> &gt; &gt; strings, &lt;br&gt;<br>
> &gt; &gt; &amp;gt; using hasValue restrictions to map the strings into
> classes and then<br>
> &gt; &gt; using &lt;br&gt;<br>
> &gt; &gt; &amp;gt; the class hierachy on those restrictions to show the
> hierarchical<br>
> &gt; &gt; &lt;br&gt;<br>
> &gt; &gt; &amp;gt; relationships between the subject vocab terms. To do
> this well, we<br>
> &gt; &gt; probably &lt;br&gt;<br>
> &gt; &gt; &amp;gt; want to specialise the dc:subject property with a subproperty
> eg:subject,<br>
> &gt; &gt; &lt;br&gt;<br>
> &gt; &gt; &amp;gt; specify its range with an owl:Datarange explicitly enumerating
> the<br>
> &gt; &gt; &lt;br&gt;<br>
> &gt; &gt; &amp;gt; controlled vocabulary, and for each term create a class
> using a hasValue<br>
> &gt; &gt; &lt;br&gt;<br>
> &gt; &gt; &amp;gt; restriction.&lt;br&gt;<br>
> &gt; &gt; &amp;gt; For further clarity and usablility we might want to
> create two related<br>
> &gt; &gt; &lt;br&gt;<br>
> &gt; &gt; &amp;gt; properties, one indicating the (single) intended subject
> code, and<br>
> &gt; &gt; the &lt;br&gt;<br>
> &gt; &gt; &amp;gt; other indicating all implicit subject codes formed from
> the class<br>
> &gt; &gt; hierachy.&lt;br&gt;<br>
> &gt; &gt; &amp;gt; The former would be a subproperty of both the latter
> and dc:subject;<br>
> &gt; &gt; the &lt;br&gt;<br>
> &gt; &gt; &amp;gt; latter would be used to create the hasValue restrictions.&lt;br&gt;<br>
> &gt; &gt; &amp;gt; &lt;br&gt;<br>
> &gt; &gt; &amp;gt; Hmmm ... quite a lot of work initially, but the end
> result is that<br>
> &gt; &gt; the &lt;br&gt;<br>
> &gt; &gt; &amp;gt; subject indicators are marked up using text strings
> from an explicit<br>
> &gt; &gt; &lt;br&gt;<br>
> &gt; &gt; &amp;gt; controlled vocab; we conform with the defn of dc:subject,
> even with<br>
> &gt; &gt; the &lt;br&gt;<br>
> &gt; &gt; &amp;gt; advertised best practice; we fall within OWL DL with
> the expectation<br>
> &gt; &gt; that &lt;br&gt;<br>
> &gt; &gt; &amp;gt; this will give us better reasoning performance, and
> we have been clearer<br>
> &gt; &gt; &lt;br&gt;<br>
> &gt; &gt; &amp;gt; about we are trying to say. I think the complexity can
> be hidden from<br>
> &gt; &gt; the &lt;br&gt;<br>
> &gt; &gt; &amp;gt; end users.&lt;br&gt;<br>
> &gt; &gt; &amp;gt; &lt;br&gt;<br>
> &gt; &gt; &amp;gt; Jeremy&lt;br&gt;<br>
> &gt; &gt; &amp;gt; &lt;br&gt;<br>
> &gt; &gt; &amp;gt; &lt;br&gt;<br>
> &gt; &gt; &amp;gt; &lt;br&gt;<br>
> &gt; &gt; &amp;gt; &lt;br&gt;<br>
> &gt; &gt; &amp;gt; &lt;br&gt;<br>
> &gt; &gt; &amp;gt; &lt;br&gt;<br>
> &gt; &gt; &amp;gt; &lt;br&gt;<br>
> &gt; &gt; &amp;gt; &lt;br&gt;<br>
> &gt; &gt; &amp;gt; &lt;br&gt;<br>
> &gt; &gt; &amp;gt; Bernard Vatant wrote:&lt;br&gt;<br>
> &gt; &gt; &amp;gt; &amp;gt; &lt;br&gt;<br>
> &gt; &gt; &amp;gt; &amp;gt; *BV&lt;br&gt;<br>
> &gt; &gt; &amp;gt; &amp;gt; &lt;br&gt;<br>
> &gt; &gt; &amp;gt; &amp;gt;&amp;gt;&amp;gt;- Is it worth the trade-off
> to switch one's ontology (otherwise<br>
> &gt; &gt; DL)&lt;br&gt;<br>
> &gt; &gt; &amp;gt; &amp;gt;&amp;gt;&amp;gt;to OWL-Full, just to&lt;br&gt;<br>
> &gt; &gt; &amp;gt; &amp;gt;&amp;gt;&amp;gt;allow its classes to be used
> as objects in 'dc:subject'<br>
> &gt; &gt; predicates?&lt;br&gt;<br>
> &gt; &gt; &amp;gt; &amp;gt; &lt;br&gt;<br>
> &gt; &gt; &amp;gt; &amp;gt; &lt;br&gt;<br>
> &gt; &gt; &amp;gt; &amp;gt; *Jim&lt;br&gt;<br>
> &gt; &gt; &amp;gt; &amp;gt; &lt;br&gt;<br>
> &gt; &gt; &amp;gt; &amp;gt;&amp;gt;That's a weird way to ask the question.
> &amp;nbsp;You mean, is<br>
> &gt; &gt; it worth doing&lt;br&gt;<br>
> &gt; &gt; &amp;gt; &amp;gt;&amp;gt;the extra work to break your naturally
> occuring model just<br>
> &gt; &gt; so that&lt;br&gt;<br>
> &gt; &gt; &amp;gt; &amp;gt;&amp;gt;you can be in DL?&lt;br&gt;<br>
> &gt; &gt; &amp;gt; &amp;gt; &lt;br&gt;<br>
> &gt; &gt; &amp;gt; &amp;gt; &lt;br&gt;<br>
> &gt; &gt; &amp;gt; &amp;gt; The way I put it might seem weird indeed, but
> it's the way it<br>
> &gt; &gt; was set in the real project&lt;br&gt;<br>
> &gt; &gt; &amp;gt; &amp;gt; context (real world is weird). We had an OWL-DL
> ontology, and<br>
> &gt; &gt; wanted to keep it so, and&lt;br&gt;<br>
> &gt; &gt; &amp;gt; &amp;gt; suddenly after six months or so some user wants
> to be able to<br>
> &gt; &gt; use a class as a subject of&lt;br&gt;<br>
> &gt; &gt; &amp;gt; &amp;gt; a document ... which is one case out of one
> thousand, the 999<br>
> &gt; &gt; others using 'regular'&lt;br&gt;<br>
> &gt; &gt; &amp;gt; &amp;gt; subjects. So using a class as subject of a
> document is not exactly<br>
> &gt; &gt; 'naturally occuring'.&lt;br&gt;<br>
> &gt; &gt; &amp;gt; &amp;gt; It's a borderline case - not to say a weird
> one :))&lt;br&gt;<br>
> &gt; &gt; &amp;gt; &amp;gt; &lt;br&gt;<br>
> &gt; &gt; &amp;gt; &amp;gt; *Jim&lt;br&gt;<br>
> &gt; &gt; &amp;gt; &amp;gt; &lt;br&gt;<br>
> &gt; &gt; &amp;gt; &amp;gt;&amp;gt;I would argue this is indeed a BP issue,
> but probably for<br>
> &gt; &gt; WORLD not&lt;br&gt;<br>
> &gt; &gt; &amp;gt; &amp;gt;&amp;gt;for OPEN... we need to explain why and
> when you would do the<br>
> &gt; &gt; extra&lt;br&gt;<br>
> &gt; &gt; &amp;gt; &amp;gt;&amp;gt;work (and in every case we have explored
> it is extra work)<br>
> &gt; &gt; to make&lt;br&gt;<br>
> &gt; &gt; &amp;gt; &amp;gt;&amp;gt;sure your ontology is in the DL profile
> of OWL.&lt;br&gt;<br>
> &gt; &gt; &amp;gt; &amp;gt; &lt;br&gt;<br>
> &gt; &gt; &amp;gt; &amp;gt; &lt;br&gt;<br>
> &gt; &gt; &amp;gt; &amp;gt; I suggested it might be in PORT scope, because
> it deals with<br>
> &gt; &gt; the terminology vs ontology&lt;br&gt;<br>
> &gt; &gt; &amp;gt; &amp;gt; general issue. For me the heart of the question
> is to know what<br>
> &gt; &gt; it means to 'use a&lt;br&gt;<br>
> &gt; &gt; &amp;gt; &amp;gt; concept' defined in a terminology (glossary,
> thesaurus, subject<br>
> &gt; &gt; headings, index...) as a&lt;br&gt;<br>
> &gt; &gt; &amp;gt; &amp;gt; class (or a property) in an ontology.&lt;br&gt;<br>
> &gt; &gt; &amp;gt; &amp;gt; &lt;br&gt;<br>
> &gt; &gt; &amp;gt; &amp;gt; Is 'PhD Thesis' class the same 'subject' (using
> TM language here,<br>
> &gt; &gt; sorry) or 'resource'&lt;br&gt;<br>
> &gt; &gt; &amp;gt; &amp;gt; than the original concept? The more I think
> about it, the more<br>
> &gt; &gt; I have to deal with it, and&lt;br&gt;<br>
> &gt; &gt; &amp;gt; &amp;gt; the more I tend to say that they are distinct
> animals. Jim's<br>
> &gt; &gt; PhD Thesis is an instance of&lt;br&gt;<br>
> &gt; &gt; &amp;gt; &amp;gt; the class, but not of the concept. One subject
> of 'Social Functions<br>
> &gt; &gt; of PhD Thesis in&lt;br&gt;<br>
> &gt; &gt; &amp;gt; &amp;gt; Occidental University during 20th century',
> is the concept of<br>
> &gt; &gt; PhD Thesis, not the class.&lt;br&gt;<br>
> &gt; &gt; &amp;gt; &amp;gt; &lt;br&gt;<br>
> &gt; &gt; &amp;gt; &amp;gt; So it's not just an issue of OWL-DL vs OWL-Full,
> it's also an<br>
> &gt; &gt; issue of making distinct or&lt;br&gt;<br>
> &gt; &gt; &amp;gt; &amp;gt; not those two 'things'. This is a core issue
> in porting thesaurus<br>
> &gt; &gt; to the SW, related to&lt;br&gt;<br>
> &gt; &gt; &amp;gt; &amp;gt; others of the same kind, like if concepts A
> and B are interpreted<br>
> &gt; &gt; as classes, and there is&lt;br&gt;<br>
> &gt; &gt; &amp;gt; &amp;gt; a Broader-Narrower relationship between A and
> B in the Thesaurus,<br>
> &gt; &gt; has it to be interpreted&lt;br&gt;<br>
> &gt; &gt; &amp;gt; &amp;gt; as a class-subclass relationship in the ontology
> etc.&lt;br&gt;<br>
> &gt; &gt; &amp;gt; &amp;gt; &lt;br&gt;<br>
> &gt; &gt; &amp;gt; &amp;gt; So I think in that case a BP definition would
> be two-fold&lt;br&gt;<br>
> &gt; &gt; &amp;gt; &amp;gt; &lt;br&gt;<br>
> &gt; &gt; &amp;gt; &amp;gt; 1. Is it generally a BP to make terminology
> concepts distinct<br>
> &gt; &gt; from ontology classes (and&lt;br&gt;<br>
> &gt; &gt; &amp;gt; &amp;gt; properties)?&lt;br&gt;<br>
> &gt; &gt; &amp;gt; &amp;gt; 2. If agnostic about 1, what is the trade-off
> when choosing to<br>
> &gt; &gt; make them distinct or to&lt;br&gt;<br>
> &gt; &gt; &amp;gt; &amp;gt; merge them ?&lt;br&gt;<br>
> &gt; &gt; &amp;gt; &amp;gt; &lt;br&gt;<br>
> &gt; &gt; &amp;gt; &amp;gt; FWIW, having tried both terms of the alternative
> in the course<br>
> &gt; &gt; of time, my personal view,&lt;br&gt;<br>
> &gt; &gt; &amp;gt; &amp;gt; for above quoted reasons, is that they shoud
> be kept separate,<br>
> &gt; &gt; and it's worth the extra&lt;br&gt;<br>
> &gt; &gt; &amp;gt; &amp;gt; work (even before being aware of the DL vs
> Full issue)&lt;br&gt;<br>
> &gt; &gt; &amp;gt; &amp;gt; &lt;br&gt;<br>
> &gt; &gt; &amp;gt; &amp;gt; Are there other concrete experience on that,
> not only theoretical<br>
> &gt; &gt; considerations? Seems&lt;br&gt;<br>
> &gt; &gt; &amp;gt; &amp;gt; like there are not so many people exploring
> the terminology-ontology<br>
> &gt; &gt; interoperability. Or&lt;br&gt;<br>
> &gt; &gt; &amp;gt; &amp;gt; are they?&lt;br&gt;<br>
> &gt; &gt; &amp;gt; &amp;gt; &lt;br&gt;<br>
> &gt; &gt; &amp;gt; &amp;gt; Bernard Vatant&lt;br&gt;<br>
> &gt; &gt; &amp;gt; &amp;gt; Senior Consultant&lt;br&gt;<br>
> &gt; &gt; &amp;gt; &amp;gt; Knowledge Engineering&lt;br&gt;<br>
> &gt; &gt; &amp;gt; &amp;gt; Mondeca - www.mondeca.com&lt;br&gt;<br>
> &gt; &gt; &amp;gt; &amp;gt; bernard.vatant@mondeca.com&lt;br&gt;<br>
> &gt; &gt; &amp;gt; &amp;gt; &lt;br&gt;<br>
> &gt; &gt; &amp;gt; &amp;gt; &lt;br&gt;<br>
> &gt; &gt; &amp;gt; &lt;br&gt;<br>
> &gt; &gt; &lt;/tt&gt;&lt;/font&gt;<br>
> </tt></font>
Received on Saturday, 27 March 2004 07:27:40 EST

This archive was generated by hypermail pre-2.1.9 : Saturday, 27 March 2004 07:27:48 EST