RE: domain/range for skos props

Benjamin

> A basic thing I like about SKOS is that I could easily understand and implement
> the core part of it. so adding complexity to the spec may have a negative
> effect on its success/deployment (?).

Sure enough. Count me in early adopters of easy-to-understand specs !!

> Is there another (indirect) way to create a link between rdfs classes and skos
> concepts, that could be used as an alternative, or a property with
> domain=rdfs:Class and range=skos:Concept?

I tried without success to found out my earlier suggestions in this forum archive, so it
was probably somewhere else ... anyway, those suggestions had never much response wherever
that was, so I will have another try :))

I figure an instance of "skos:Concept" as something more generic, less
constrained/specified/formal than any formal match like some "rdfs:Class". IOW a Class is
a specification of a Concept in some formal scheme (ontology). The same skos:Concept,
given its very genericity, can be formalized in many different formal schemes, and in many
ways. For example the concept of "Composer" can be formalized in some ontology as a Class
(with instances "Mozart", "Bach", ...), and in another one as an ObjectProperty (linking
"Don Giovanni" to "Mozart"), or a DatatypeProperty (if the composer is not enough
identified to be an individual), in a Topic Map ontology as a Role Type used in a
"Composition" Association Type, etc ...

Now from where is it easier to declare the relationship between a skos:Concept and one of
its many formal matches? Not easy from the formal side, since the relationship itself is
quite informal, and to make it more formal implies to consider e.g. the formal OWL entity
(class or property) as an individual ... which some folks will not like.

So I would suggest to do it from the unformal side. Let me have a try at it:

skos:formalMatch  a  rdf:Property;
	rdfs:domain  skos:Concept;
	rdfs:range   skos:formalConcept.

skos:formalConcept being defined as superClass of whatever formal animals live in RDF
land, like:

rdfs:Class  	rdfs:subClassOf  	skos:formalConcept
rdf:Property 	rdfs:subClassOf  	skos:formalConcept

Not sure about ...

skos:formalConcept	rdfs:subClassOf  	skos:Concept

Since all the above would entail the provocative

rdfs:Class  	rdfs:subClassOf  	skos:Concept
rdf:Property 	rdfs:subClassOf  	skos:Concept

hmmm ...

Anyway, applications would be like

a:Composer  a  skos:Concept
b:Composer  a  rdfs:Class
c:Composer  a  owl:ObjectProperty

a:Composer  skos:formalMatch  b:Composer
a:Composer  skos:formalMatch  c:Composer

Those declarations are non-intrusive wrt the formal vocabulary, but allow to somehow
"federate" the various formal "flavours" of a non-formal concept.

How does that sound?

Bernard


**********************************************************************************

Bernard Vatant
Senior Consultant
Knowledge Engineering
bernard.vatant@mondeca.com

"Making Sense of Content" :  http://www.mondeca.com
"Everything is a Subject" :  http://universimmedia.blogspot.com

**********************************************************************************

> -----Message d'origine-----
> De : public-esw-thes-request@w3.org
> [mailto:public-esw-thes-request@w3.org]De la part de Benjamin Nowack
> Envoyé : jeudi 21 octobre 2004 18:19
> À : Miles, AJ (Alistair)
> Cc : 'public-esw-thes@w3.org'
> Objet : Re: domain/range for skos props
>
>
>
>
> On 21.10.2004 13:01:53, Miles, AJ (Alistair) wrote:
> ...
> >Relating back to Benjamin's initial point: if we decide that
> >skos:broader/narrower/related should only be used with skos:Concepts, then
> >this behaviour seems appropriate; however if we decide that it's OK to use
> >skos:broader/narrower/related with any type of resource, then this behaviour
> >seems inappropriate (??).
> >
> >An alternative would be to remove domain/range statements on
> >skos:semanticRelation, but to introduce OWL restrictions on the skos:Concept
> >class, e.g.
> >
> ><rdfs:Class rdf:about="#Concept">
> >  <rdfs:subClassOf>
> >    <owl:Restriction>
> >      <owl:onProperty rdf:resource="#broader" />
> >      <owl:allValuesFrom rdf:resource="#Concept" />
> >    </owl:Restriction>
> >  </rdfs:subClassOf
> ></rdfs:Class>
> >
> >This means that skos:broader/narrower/related could be used with any type of
> >resource, but when used on a skos:Concept must point to another
> >skos:Concept.  (Is this the type of constraint we want?)
> Not sure. I heard that restrictions should primarily be used to infer class
> memberships by looking at the props, instead of using them to define
> constraints on explicitly typed individuals, but I may well be wrong (or
> under-informed).
> A basic thing I like about SKOS is that I could easily understand and implement
> the core part of it. so adding complexity to the spec may have a negative
> effect on its success/deployment (?). Although I'd really like to use skos
> terms on classes, SKOS' ease of use could be more important (broadening the
> domain of skos:example and skos:definition, i.e. the datatype properties,
> is probably ok, I'd assume).
> Is there another (indirect) way to create a link between rdfs classes and skos
> concepts, that could be used as an alternative, or a property with
> domain=rdfs:Class and range=skos:Concept?
>
> Dunno, but is this a topic the SWBPD WG's vocabulary management TF could help
> clarify? I'm currently trying to build support for both skos and rdfs in my
> vocab editor, but I don't know (yet) how to link from terms to skos concepts. (I
> can simply add skos:prefLabel to classes but does that really allow me to
> identify the related concept?) I didn't read all of the available skos
> material, though. maybe I just have to read more carefully.
>
> regards,
> benjamin
>
> --
> Benjamin Nowack
>
> Kruppstr. 100
> 45145 Essen, Germany
> http://www.appmosphere.com/
>
> >> >Al.
> >> >
> >> >---
> >> >Alistair Miles
> >> >Research Associate
> >> >CCLRC - Rutherford Appleton Laboratory
> >> >Building R1 Room 1.60
> >> >Fermi Avenue
> >> >Chilton
> >> >Didcot
> >> >Oxfordshire OX11 0QX
> >> >United Kingdom
> >> >Email:        a.j.miles@rl.ac.uk
> >> >Tel: +44 (0)1235 445440
>
>

Received on Thursday, 21 October 2004 18:03:24 UTC