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