- From: Mikael Nilsson <mikael@nilsson.name>
- Date: Mon, 18 Feb 2008 09:13:24 +0100
- To: Simon Spero <ses@unc.edu>
- Cc: SKOS <public-esw-thes@w3.org>
Simon, SKOS does indeed lack a theoretical foundation, I'm glad you proposed one! If a theory is agreed upon, the theory can be used to answer many of the difficult questions we're asking. I don't fully agree with the path your model took, so let's see where I land when I try... fre 2008-02-15 klockan 18:04 -0500 skrev Simon Spero: > > 3: The extension of a SKOS Concept is the set of all documents which > have that SKOS Concept as a subject; compare with the definition of an > rdfs class in RDF Semantics (Hayes 2004) I have sympathy with this model. This would make skos:Concepts also rdfs:Classes (i.e. skos:Concept rdfs:subClassOf rdfs:Class), something that has been avoided to far. > > 4: Concept schemes are defined in the context of a specific domain > (which may be general). Relationships need not be valid outside that > domain (Turbine/Fan/Blades ISO; Parrots BT Pets in a pet shop > thesaurus). That's reasonable enough. So, to understand the Class that Parrots refers to, we can for the purpose of this discussion, call the class "Petshop-Parrot-Document" - i.e. the set of documents, in a Pet shop context, indexed by "Parrot". Generally, the label [Scheme]-[Term]-Document is descriptive of the class. > > > 5: Relationships between SKOS Concepts are relationships between > Subject Terms, not Classes. These relationships entail a different > set of relationships between the Classes associated with those > Subject Terms. That is strange in light of the above. If a SKOS concept is the class of all indexed documents, it *is* a class. Alternatively, you are arguing that the *is* an implicit class involved, but it's not the skos:Concept. Why is that level of indirection necessary in this model? I don't think that's right. > > 7: A skos:broader B means: every document ( within the domain of > the concept scheme) about A must also be about B. In the above model: Doc_A is indexed as A <=> Doc_A rdf:type A Doc_B is indexed as B <=> Doc_B rdf:type B so the above statement "A BT B" is "all A are also B", namely: A rdfs:subClassOf B > Thus: > > > Wheels BT Cars == Every document about wheels is also a > document about cars. > Cars BT Vehicles == Every document about cars is also a > document about vehicles. > |---------------------------------------------------------------------------------------------------------------- > Wheels BT Vehicles == Every document about wheels is also a > document about vehicles > > It is incorrect to infer any relationship between the class of > Wheels and the class of Vehicles given only a plain broader/BT > assertion Oh, but the class in question is not the class of Wheels, it's the class I call "MyScheme-Wheels-Documents". Nobody said anything about the class of wheels in this model, did we? So you indeed have MyScheme-Wheels-Documents rdfs:subClassOf MyScheme-Cars-Documents MyScheme-Cars-Documents rdfs:subClassOf MyScheme-Vehicles-Documents ==> MyScheme-Wheels-Documents rdfs:subClassOf MyScheme-Vehicles-Documents which makes all sorts of sense. > 8: A BTG B means: every document about A must also be about B > because the class of As is a subclass of the class of Bs. > > > Cars BTG Vehicles == Every document about cars is also about > vehicles, because a car is-a vehicle. > Convertibles BTG Cars == Every document about convertibles is > also about cars, because a convertible is a car > |---------------------------------------------------------------------------------------------------------------------------------------------------- > Convertibles BTG Vehicles == Every document about > convertibles is also about vehicles, because a convertible is > a vehicle In my model, A BTG B means that there is a class of Wheels and of Cars, with a subclass relation. Those classes are implicit - and *not* the same as the skos:Concepts. Are you suggesting that in in this case, the skos:Concept Wheels is the class of Wheels? I think that is never a good idea. > 9: A BTP B means: every document about A must also be about B, > because every A is in some sense part of a B. > > > Fingers BTP Hands == Every document about fingers is also > about Hands, because every finger is part of a hand. > Hands BTP People == Every document about hands is also about > People, because every hand is part of a person. > |---------------------------------------------------------------------------------------------------------------------------------------------------- > Fingers BTP People == Every document about fingers is also > about People, because every finger is part of a person. > > > 10: The exact relationship between the classes of two SKOS Concepts > that are BTP depends on the nature of partitive relationship. Some > subtypes of BTP may allow a more precise transitive semantics for the > related Classes. Agree. In my model, this would mean (replace skos:BTP with the right property) Anatomy-Fingers-Documents skos:BTP Anatomy-Hands-Documents ===> There are implicit classes Finger and Hand, and a Finger is somehow part of a Hand. and, naturally Anatomy-Fingers-Documents rdfs:subClassOf Anatomy-Hands-Documents etc. > > 11: A BTI B means: every document about the individual A is also > about B, because A is an instance of B. BTI is subset of BTG; > thus transitivity is maintained for the underlying classes > > > My S2000 BTI Convertibles == Every document about my S2000 is > also about Convertibles, because my S2000 is-a convertible > Convertibles BTG Cars == Every document about convertibles is > also about cars, because a convertible is-a car > |---------------------------------------------------------------------------------------------------------------------------------------------------- > My S2000 BTI Cars == Every document about my S2000 is also > about cars, because my S2000 is-a car Again, I don't think you want to say that MyScheme-MyS2000-Documents is an *instance* of MyScheme-Convertibles-Documents. Rather, there is an implicit class Convertibles, and a resource MyS2000, and the latter is an instance of the former. This one is tricky, however. I think there are several modeling choices here. We have as a fact MyScheme-MyS2000-Documents skos:BTI MyScheme-Convertibles-Documents We also have MyScheme-Convertibles-Documents skos:BTG MyScheme-Cars-Documents We can surely conclude MyScheme-MyS2000-Documents rdfs:subClassOf MyScheme-Cars-Documents But you're saying we can additionally infer MyScheme-MyS2000-Documents skos:BTI MyScheme-Cars-Documents Maybe so... > > 12: SKOS Collections correspond to arrays, and to what Svenonius > termed "perspective hierarchies". These types of hierarchies are > useful for representing classificatory structures; it might be > possible to infer quasi-facets , or specific properties. No opinion at this stage. This is all very interesting. We can model a skos:Concept as one of a number of entities in this world. Think of the skos:Concept "Wheels". Here are a few options: 1 "Wheels" is the set of wheels. This is the OWL approach, and not taken by SKOS. 2 "Wheels" is the set of documents indexed by "Wheels" (my approach above). 3 "Wheels" is a Subject, disjoint from the two above, but with relationships to both of the above classes. This is Simon's approach. I think both 2 and 3 work. 2 is simpler, but suffers from being closely intermingled with RDF schema. The most critical thing is that we choose *one* of the models and stick with it. In the above, I've tried to explain where I believe Simon starts mixing 3 and 1, and I think that's really counterproductive. Keep the entities disjoint. Sorry, this reply didn't turn out as readable as I had hoped. Hope someone finds a use for it :-) /Mikael > > > More to come > > > Simon > > > > References > Hayes, Patrick (2004). RDF Semantics. Recommendation. World Wide Web > Consortium. > URL: http://www.w3.org/TR/2004/REC-rdf-mt-20040210/ > > > Milstead, Jessica L. (2001). “Standards for Relationships between Sub > ject Indexing Terms”. In: Relationships in the Organization of > Knowledge. Ed. by Carol A Bean and Rebecca Green. Information science > and knowledge management. Dordrecht: Kluwer Academic Publishers. Pp. > 53–66. ISBN: 0792368134. > > > Svenonius, Elaine (2000). The Intellectual Foundation of Information > Organization. Cambridge, Mass.: MIT Press. ISBN: 0262194333 (hc : alk. > paper). > URL: http://www.netlibrary.com/AccessProduct.aspx?ProductId=39954. > > -- <mikael@nilsson.name> Plus ça change, plus c'est la même chose >
Received on Monday, 18 February 2008 08:13:28 UTC