W3C home > Mailing lists > Public > public-esw-thes@w3.org > October 2004

RE: [Proposal][SKOS-Core] skos:denotes

From: NJ Rogers, Learning and Research Technology <Nikki.Rogers@bristol.ac.uk>
Date: Thu, 14 Oct 2004 21:31:26 +0100
To: "Miles, AJ (Alistair)" <A.J.Miles@rl.ac.uk>, public-esw-thes@w3.org
Message-ID: <7325283.1097789486@82-32-26-103.cable.ubr04.azte.blueyonder.co.uk>

Hi Al,

I was coming to some - almost! - similar conclusions to you when I came 
back to reflect on the debate this week.

I think that schema definitions for how concepts within the same conceptual 
scheme relate to each other are best placed in SKOS Core.
And I think that schema definitions for how concepts within different 
conceptual schemes relate to each other, AND relationships between concepts 
and other RDF resources, belong in SKOS Mapping.

I think that for SKOS Mapping the "mappingRelation" property could be used 
as appropriate for the latter:
	<rdf:Property rdf:ID="mappingRelation">
super-property of all properties expressing information about how to create 
mappings between concepts frmo different conceptual schemes [sic]. 


Let's look at some use cases to see how that mappingRelation property might 
need to be "specialised" (sub-property'd) for various use cases:

1) Al's intial use case:

my:conceptA		a	skos:Concept;
	skos:prefLabel	'Alistair Miles';
	skos:denotes	[	a	foaf:Person;
<mailto:a.j.miles@rl.ac.uk>	].

Here Al wants to relate some SKOS concept to some RDF resource.
So the domain of the "mappingRelation" property needs to be skos:Concept 
and the range rdf:Resource (in order to allow aggregators, reasoners, 
applications layered over RDF to make good use of the underlying data etc 
So, with these domain and range constraints, I would specify a sub-property 
of skos-map:mappingRelation and call it say

2) Danbri's use case
(quoting from Al)
"He and some other guys have weblog categories that represent the same 
Rather than writing mappings between each of the pairwise combinations,
Danbri wants some facility by which each of the blog owners can say e.g. 'my
blog category X denotes the foaf:Person with mbox foo@bar.com'.  If a bunch
of different blog categories all 'denote' the same resource, then you can
aggregate them."

sounds like he needs to define how some RDF resource "corresponds" - maps? 
- to a SKOS concept.
So the domain of the "mappingRelation" property needs to be rdf:Resource 
and the range skos:Concept (ie the reverse of 1) above).

So, with these domain and range constraints, I would specify a sub-property 
of skos-map:mappingRelation and call it say

3) Well, so it goes on  ....
Suppose I generally want to map a skos concept to an owl Thing (leaving 
aside OWL individuals and classes for further mapping specialisations at 
some point ...), this implies domain and range constraints. So with these 
constraints I would again specifiy a sub-property of 
skos-map:mappingRelation and call it say

and so on .....  Do you see what I mean?

4) I even think one should even be able to use the super-property 
<skos:mappingrelation> to imply a loose corrrespondance between *any* two 
rdf:Resource's (and not necessarily a skos:Concept). Or is that just plain 
Anarchy on the Semantic Web? ;-)  The reason I think that SKOS 'stuff' is 
different to OWL 'stuff' (and in particular the owl:sameAs business) is 
because whereas OWL has the notion of classes and individuals and has to 
specify different levels at which decidability can be employed, SKOS is not 
constrained in this way.

Anyway, it's late so I'll sign off now. But as you can see, Al, I was 
thinking similarly to you along the lines of property "directionality", but 
with the difference that I want to loose the terminology "denotes" (because 
I do not find it intuitive) and stick all mapping type stuff (with which I 
think all these use cases belong) in SKOS Mapping.


--On 14 October 2004 15:49 +0100 "Miles, AJ (Alistair) " 
<A.J.Miles@rl.ac.uk> wrote:

> Hi,
> Although Danbri had me convinced [1], I found Dave R's argument compelling
> [2].  Both points of view seem good to me, or at least appropriate under a
> particular set of circumstances.
> So here's an attempt to accommodate both points of view ... what if we do
> the following:
> (1) Add a new property 'skos:denotesSameAs' to SKOS Core, which is
> *symmetric* and which carries essentially the same semantics as
> skos-map:exactMatch.
> (2) Add a new property 'skos:denotesClass' to SKOS Core, with domain
> skos:Concept and range rdfs:Class, *as a sub-property of
> skos:denotesSameAs*.
> (3) Add a new property 'skos:denotesIndividual' to SKOS Core, with domain
> skos:Concept and range rdf:Resource, *as a sub-property of
> skos:denotesSameAs*.
> So (1) establishes the underlying ontological commitment that a
> skos:Concept sits at the same level of abstraction as an RDFS/OWL
> Class/Individual. However, (2) and (3) allow the *directionality* of such
> a relationship to be captured, where that is required.
> Er, re-reading that it back to myself, it sounds potentially a little
> shaky, but I'll post this anyway, and hopefully it will stimulate more
> ideas.
> Al.
> [1] http://lists.w3.org/Archives/Public/public-esw-thes/2004Sep/0067.html
> [2] http://lists.w3.org/Archives/Public/public-esw-thes/2004Oct/0005.html
> ---
> 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
>> -----Original Message-----
>> From: public-esw-thes-request@w3.org
>> [mailto:public-esw-thes-request@w3.org]On Behalf Of Miles, AJ
>> (Alistair)
>> Sent: 14 October 2004 15:25
>> To: 'Leo Sauermann'; public-esw-thes@w3.org
>> Subject: RE: [Proposal][SKOS-Core] skos:denotes
>> Hi Leo,
>> To answer the easiest question first, the 'traditional' way
>> to use SKOS
>> concepts is as the values in a subject-based index of
>> documents.  There is a
>> proposal on the table [1] for a 'skos:subject' property,
>> which basically
>> behaves in the same way to the 'dc:subject' property, i.e.
>> you will be able
>> to state:
>> <rdf:RDF /*standard namespaces*/>
>>   <rdf:Description rdf:about="http://foo.com/somedoc.html">
>>     <skos:subject rdf:resource="http://bar.com/some#concept"/>
>>   </rdf:Description>
>> </rdf:RDF>
>> Of course, there are many other scenarios emerging in which
>> SKOS concepts
>> can be used (and your use case is expanding the set I had
>> imagined so far
>> :).  For example, a SKOS concept can be depicted by an image,
>> or a SKOS
>> concept could be a topic of interest or expertise for a person ...
>> Anyway.  Another set of scenarios (including yours I think)
>> requires us to
>> be able to express a relationship between a SKOS concept and
>> an RDFS/OWL
>> Class/Individual that 'intends'/'represents'/'denotes' the
>> same (or similar)
>> thing.  This requirement was the basis for the original 'skos:denotes'
>> proposal [2] which has been argued for by danbri (see e.g. [3]).
>> However, others have argued that a relationship of meaning
>> between a SKOS
>> concept and an RDFS/OWL Class/Individual is essentially the same as a
>> mapping relationship between two SKOS concepts (see e.g.
>> [4]).  Or in other
>> words, there is no difference in the level of abstraction
>> between a SKOS
>> concept and an RDFS/OWL Class/Individual.  Hence a
>> 'skos:denotes' property
>> is not appropriate.
>> So this debate is currently poised :)
>> I'm just thinking, perhaps a more detailed description of
>> your requirements
>> here could help us with this problem ... could you expand a
>> little on these
>> for us?
>> Thanks,
>> Alistair.
>> [1]
>> http://lists.w3.org/Archives/Public/public-esw-thes/2004Oct/0081.html
>> [2]
>> http://lists.w3.org/Archives/Public/public-esw-thes/2004Sep/0041.html
>> [3]
>> http://lists.w3.org/Archives/Public/public-esw-thes/2004Sep/0067.html
>> [4]
>> http://lists.w3.org/Archives/Public/public-esw-thes/2004Oct/0005.html
>> -----Original Message-----
>> From: public-esw-thes-request@w3.org
>> [mailto:public-esw-thes-request@w3.org]On Behalf Of Leo Sauermann
>> Sent: 14 October 2004 09:46
>> To: public-esw-thes@w3.org
>> Subject: Re: [Proposal][SKOS-Core] skos:denotes
>> Danbri:
>> > RDF tries to impose some basic design constraints across
>> all projects
>> > that use it, to make things easier for data-merging, extensibility
>> > etc. What we're doing with skos:represents (or whatever it gets
>> > called) is coming up with a little add-on that helps SKOS-based RDF
>> > data work better with non-SKOS RDF data.
>> I could not follow the whole discussion, because I began
>> thinking about skos
>> a week ago
>> http://leobard.twoday.net/stories/360443/
>> My Goal is:
>> I want to build stuctures that are independent of nromal RDF
>> instances, that
>> means: I want to model things like "Job"
>> "Private" "ProjectX" and form these things as SKOS:Concepts
>> then I have emails, files, photos, websites, etc that I want
>> to add to these
>> SKOS:concepts
>> Ideal:
>> SKOS concepts
>> REAL LIFE Resources
>> JOB
>>  - Project X
>>      - Meeting 23.10.2004
>>  - Project Y
>> Email "skos;denoites"
>> File "skos image"
>> Website "skos website"
>> Website "http://www.w3.org/2001/sw"
>> now I want
>> <meeting 23.10.2004> <????> <http://www.w3.org/2001/sw>
>> the problem:
>> You forgot to add somehting to skos that allows to acutally USE skos.
>> A thesaurus /taxonomy/  whatever is only useful when I can link it to
>> external RDF resources,
>> All predicates in SKOS are having domain/range skos Concepts,
>> but SKOS concepts are a closed thing and I want to create
>> triples from skos
>> to the outer world.
>> The "real" resources out there in the world are of type
>> email, file, person,
>> vcard, vEvent
>> So, please,
>> tell me which property I have to use to hang real resources to a SKOS
>> concept.
>> is this SKOS:denotes?
>> is it dc:hasPart ?
>> cheers
>> Leo

NJ Rogers, Technical Researcher
(Semantic Web Applications Developer)
Institute for Learning and Research Technology (ILRT)
Tel: +44(0)117 9287096 (Direct)
Tel: +44(0)117 9287193 (Office)
Received on Thursday, 14 October 2004 20:31:43 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:45:16 UTC