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.
> 
> 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