RE: domain/range for skos props & 'skos:denotes'

Hi Bernard, all,

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

I think Bernard makes a crucial point here as yet not mentioned, which is
that a skos:Concept may have a mapping to an rdf:Property, as well as the
other sorts of thing (RDFS/OWL Class, RDFS/OWL Individual, TM Role Type
etc.)

I am arriving at the following points of view wrt this discussion and
Bernard's suggestion below:

(1) It is perfectly reasonable for someone to mix SKOS, RDFS and OWL within
a single scheme.  So a resource may be both a skos:Concept and an
rdfs/owl:Class, or both a skos:Concept and an rdf:Property, or both a
skos:Concept and an owl:ObjectProperty/owl:DatatypeProperty.

(2) In the case of *mapping* between a pure SKOS concept scheme and an
RDFS/OWL ontology, it is desirable to capture the fact that the mapping is
directional (i.e. from skos:Concept to rdfs:Class or rdf:Property or
whatever).  

(3) The former 'skos:denotes' proposal and all following suggestions
(including Bernard's 'formalMatch' suggestion below) live firmly in the
space of *SKOS Mapping* and NOT in SKOS Core (Danbri how do you feel about
that?)

(4) SKOS Mapping needs to be completely rethought ;)  (Mainly because there
are multiple axes along which a set of mapping constructs can be divided:
the degree of overlap; inclusion/generality (i.e. broadMatch, narrowMatch);
the types of entities ...)

That's all for now.

Al.





> -----Original Message-----
> From: public-esw-thes-request@w3.org
> [mailto:public-esw-thes-request@w3.org]On Behalf Of Bernard Vatant
> Sent: 21 October 2004 19:03
> To: public-esw-thes@w3.org
> Subject: 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 Friday, 22 October 2004 11:16:30 UTC