- From: Jane Greenberg <janeg@ils.unc.edu>
- Date: Mon, 18 Feb 2008 06:57:45 -0500 (EST)
- To: Mikael Nilsson <mikael@nilsson.name>
- cc: Simon Spero <ses@unc.edu>, SKOS <public-esw-thes@w3.org>
- Message-ID: <Pine.LNX.4.64.0802180643270.14060@ruby.ils.unc.edu>
Hello Mikael, I'll need to read through your below email in more detail, but a brief comment here... Your statement of SKOS lacking a theoretical foundation reminds me of the DCMI, which is now making headway in w/the application profile (although I believe the DCMI is grounded in various historical developments...) Is not SKOS grounded, at least to some degree, in thesauri standards, such as Z39.19, ISO 5964, ISO 2788..and general controlled vocabulary practices of for named entity systems? (Doris Clack is a genius here.) If not, why not? My understanding is that these standards have played a role in the development of SKOS. best wishes, jane On Mon, 18 Feb 2008, Mikael Nilsson wrote: > > 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 11:58:09 UTC