- From: Bernard Vatant <bernard.vatant@mondeca.com>
- Date: Thu, 21 Oct 2004 19:46:34 +0200
- To: <public-esw-thes@w3.org>
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