- From: Antoine Isaac <aisaac@few.vu.nl>
- Date: Mon, 18 Feb 2008 15:59:47 +0100
- To: SWD WG <public-swd-wg@w3.org>, SKOS <public-esw-thes@w3.org>
Dear Simon, Michael (I'm forwarding this thread to the SWD list as well) Thanks for the discussion! Notice that Simon's items 1-2-3 overlaps with the discussions the SWD working group is about to conclude on in the coming days. http://lists.w3.org/Archives/Public/public-swd-wg/2008Feb/0053.html To sum up, we say that some SKOS concept can be also considered as RDFS classes but this is not always the case, some skos Concepts will not be RDFS classes. This can be confusing but we have to deal with applications which have different requirements. The fundamental understanding of skos:Concept is the one underlying the metamodelling thoughts of the old SKOS Guide [2] SKOS Concepts are defined in a quite pragmatic way: as the SKOS Reference [2] puts it, > A conceptual resource can be viewed as an idea or notion; a unit of > thought. However, what constitutes a "unit of thought" is subjective, > and this definition is meant to be suggestive, rather than restrictive. > > The notion of a conceptual resource is useful when describing the > conceptual or intellectual structure of a knowledge organization > system, and when referring to specific ideas or meanings established > within a KOS. > So SKOS concepts are representation of things in a conceptual vocabulary. In this repect, I guess they are similar to the Subject Terms of Svenonius. Except that I don't get it when you say that this make them fundamentally different from "concepts" :-( What is a concept for you, that would make it essentially incompatible with the idea of a subject? To me it is rather the notion of Term that is not adapted here: a term is essentially linked to (a specific) natural language, while a "concept" can be abstracted (at least a bit) from it, consider for instance classes in classification schemes. But this is for the fundamental interpretation. It happens that some applications require these concepts/subjects to be considered also as RDFS classes, with extension relating to individual in the "real world" (as in the triple: ex:simon rdf:type ex:Person). Now, as Michael puts it, this stance allow for having mixes of 3 and 1 (see mail below). Honnestly I'm not sure that what this would mean in terms of interpretation for such mixed objects. For the moment it would be up to individual application designers to cope with such problems if they decided to mix SKOS and OWL worlds. Alistair and I had actually gathered some proposals to link concept/subject to classes while keeping them distinct, but they did not really provoke huge enthusiasm in SWD crowds. But there will be more discussion on that when we'll have time to cope with ISSUE-80 [5] Note that I would however consider that the mixing stops here, that is, between Michall's 1 and 3 solutions: I disagree with considering 2, or at least with the following assumption that Michael makes > 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 Let me clarify: to me it is also clear that concept/subject can be associated to some sort of extension, namely the documents that have them as subject. But such a link should be represented by a proper property (skos:subject or dc:subject) and not by rdf:type. So, SKOS concepts are not essentially RDFS/OWL classes. Notice that my argument would be more practical than formal : it's just because people have started to use rdf:type in a categorial way. If ex:bible has to be linked via rdf:type to a class related to the idea of religion, SW designers would expect it to be ex:ChristianBook rather than ex:Christianism. Or with another example, if you have ex:Wheel which is both an OWL class and a SKOS subject, you would expect it to participate in the following triples that I hope will make some sense (I really don't have time to write a lot these days) - ex:theBookOfWheels skos:subject ex:Wheel - ex:theLeftFrontWheelOfMyCar rdf:type ex:Wheel But I will stop here, there was a lot of discussion (cf references of [3]) in the past years over this on the SKOS list... Best, Antoine [1] http://www.w3.org/TR/swbp-skos-core-guide/#secmodellingrdf [2] http://www.w3.org/TR/skos-reference/#L1289 [3] http://www.w3.org/2006/07/SWD/wiki/SkosDesign/ConceptSemantics [4] http://www.w3.org/TR/skos-reference/#skos-owl-patterns [5] http://www.w3.org/2006/07/SWD/track/issues/80 > > > > -------- Message d'origine-------- > De: public-esw-thes-request@w3.org de la part de Mikael Nilsson > Date: lun. 18/02/2008 09:13 > À: Simon Spero > Cc: SKOS > Objet : Re: Broader, collections and the difference between SKOS and OWL > > > 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. > [...] > > > > > 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 >
Received on Monday, 18 February 2008 14:59:53 UTC