- From: Johannes Busse <busse@ontoprise.de>
- Date: Mon, 02 Feb 2009 15:49:02 +0100
- To: "public-esw-thes@w3.org" <public-esw-thes@w3.org>
Hi all, I'm a lurker in this discussion, but nevertheless pretty interested. Allow me a suggestion in order to undestand the problem better. ;-) Isn't the problem we are discussing here narrowly related to an expressive shortcoming in RDF or OWL w.r.t. multiple subclassing? In philosophy the issue is known and addressed in the http://en.wikipedia.org/wiki/Porphyrian_tree (sad page), i.e. the distinction between genus proximum and differentia specifica http://de.wikipedia.org/wiki/Genus_proximum (German, more explicit). Example: While in RDF a "brown dog" is both a narrower term of "brown" and a narrower term of "dog" (and there in principle is no distinction between the classes "brown" and "dog"), a human ontology modeller would prefer to speak of one large *primary tree* of (living > mammal > dog) and several modifier trees (color > brown > dark brown, toy > pet > dog). The difference? And a human reader rather would speak of a dog which is somewhat brown than speak of a brown thing that is somewhat doggish. "Dog" then is the genus proximum of "brown dog", and "brown" is it's specific characteristics. Aren't some aspects of our discussion about concept schemes related to this distinction? Then a solution to the issue could be to subclass the skos:broader relationship i.e. with - skos:GenusProximum (skos:GP) and - skos:DifferentiaSpecifica (skos:DS) Having this it would be feasible in the schema to allow a skos:concept only to have one skos:GP, but many skos:DS. However, a concept which is used as a DS itself also might have a GP and DS in turn. (And I'd suggest not to allow cycles.) Such a solution would not only allow for powerful visualization and inferencing possibilities. It also would provide for free the respective information you need if you want to combine skos with faceted classification / browsing technologies. yours Johannes Stephen Bounds wrote: > > Hi Christophe, Antoine and all, > > Personally I'm a fan of keeping SKOS terminology self-describing where > possible (and therefore would argue against using "BT"/"NT"/"RT" within > SKOS). > > A thought -- what about simply using: > > skos:broadInScheme > skos:narrowInScheme > skos:relatedInScheme > > This would then follow a construction similar to skos:broadMatch and > match the terminology of existing vocab terms such as skos:inScheme. > > Regards, > -- Stephen. > > Christophe Dupriez wrote: >> Dear Antoine, >> >> Reading this (and seing my (reasonable) difficulties to apply SKOS to >> real life problems), I would like to insist that the frame defined by >> previous ISO standards for thesauri be kept and supplemented. This may >> seem bottom-up compared to the apparent top-down process to define >> SKOS: it is alway better when stalagmites join stalagtites ! >> >> For my own stuff, I will implement: >> >> skos:semanticRelation >> | >> +- skos:related >> | | >> | +- ???:RT >> | | (disjoint from) >> | +- skos:relatedMatch >> | >> +- skos:broaderTransitive (disjoint from related and narrowerTransitive) >> | | >> | +— skos:broader >> | | >> | +- ???:BT >> | | (disjoint from) >> | +- skos:broadMatch >> | >> +— skos:narrowerTransitive (disjoint from related and broaderTransitive) >> | >> +- skos:narrower >> | >> +- ???:NT >> | (disjoint from) >> +- skos:narrowMatch >> >> >> Please note that "BT <union> broadMatch" does not cover "broader" >> because "broader" may cross scheme boundaries and "BT" cannot. >> If you add the concept of "subScheme" (micro-thesaurus), "BT" should >> not cross micro-thesaurus borders. >> >> With "RT", you can cross micro-thesaurus borders but not scheme >> boundaries. >> > > -- Dr. Johannes Busse, Senior Researcher An der RaumFabrik 29, D-76227 Karlsruhe Reg. Office: Karlsruhe, Amtsger. Mannheim, HRB 109540 Managing Directors: Prof.Dr.J.Angele, H.P.Schnurr http://www.ontoprise.de | phone x49(721) 509 809-62 mailto:busse@ontoprise.de | mobile x49(163) 509 80-62
Received on Monday, 2 February 2009 14:45:29 UTC