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

RE: [Proposal][SKOS-Core] handling top concepts

From: Miles, AJ (Alistair) <A.J.Miles@rl.ac.uk>
Date: Wed, 4 Aug 2004 16:49:56 +0100
Message-ID: <350DC7048372D31197F200902773DF4C05E50B78@exchange11.rl.ac.uk>
To: "'Supekar, Kaustubh S.'" <Supekar.Kaustubh@mayo.edu>
Cc: "'public-esw-thes@w3.org'" <public-esw-thes@w3.org>

OK here goes at the compelling argument ...

So you've got a concept A and two concept schemes X and Y.

Concept A is in scheme X and also in scheme Y.

Concept A is a top concept in scheme X, but not in scheme Y.

Using the current version of SKOS Core this is written as (assuming standard
namespaces) ...

<rdf:RDF>

	<skos:TopConcept rdf:about="http://example.org#A">
		<skos:inScheme rdf:resource="http://example.org#X"/>
		<skos:inScheme rdf:resource="http://example.org#Y"/>
	</skos:TopConcept>

</rdf:RDF>

So now a program wants to identify all the top concepts from scheme Y, and
applies the query ...

SELECT ?x
WHERE
(?x rdf:type skos:TopConcept) (?x skos:inScheme http://example.org#Y) 

... and will get back concept A included in the result set, which is
incorrect.

I.e. the true semantics of the top concept idea are not properly expressed
in the current SKOS Core vocab.  We need to be able to express unambiguously
which scheme a concept is a top concept in.  

Hence the proposal for a skos:hasTopConcept property.

So under the new proposal, the above scenario would expressed as follows ...

<rdf:RDF>

	<skos:Concept rdf:about="http://example.org#A">
		<skos:inScheme rdf:resource="http://example.org#X"/>
		<skos:inScheme rdf:resource="http://example.org#Y"/>
	</skos:Concept>

	<skos:ConceptScheme rdf:about="http://example.org#X">
		<skos:hasTopConcept rdf:resource="http://example.org#A"/>
	</skos:ConceptScheme>

	<skos:ConceptScheme rdf:about="http://example.org#Y">
	</skos:ConceptScheme>

</rdf:RDF>

This removes the ambiguity. 

Am I getting there yet?

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



> -----Original Message-----
> From: public-esw-thes-request@w3.org
> [mailto:public-esw-thes-request@w3.org]On Behalf Of Miles, AJ 
> (Alistair)
> 
> Sent: 04 August 2004 15:44
> To: 'Supekar, Kaustubh S.'
> Cc: 'public-esw-thes@w3.org'
> Subject: RE: [Proposal][SKOS-Core] handling top concepts
> 
> 
> 
> Another issue that bears on this proposal, that I missed in the wiki
> writeup, relates to whether or not some inferencing is required.
> 
> Under the current system of using the skos:TopConcept class, 
> an RDF toolkit
> needs to have some inference capability before a list of all 
> concepts in a
> model can be obtained, because it needs to infer that if (x rdf:type
> skos:TopConcept) then (x rdf:type skos:Concept) because 
> (skos:TopConcept
> rdfs:subClassOf skos:Concept)*.
> 
> If we get rid of skos:TopConcept and move to using a 
> skos:hasTopConcept
> property, then all the really basic operations required e.g. 
> for simple
> rendering can be performed without needing an RDF 
> toolkit/repository that
> does any inferencing (i.e. you could use Redland).
> 
> So I do think this proposal has definite value, and can 
> improve simplicity
> and convenience in both documentation and implementation. 
> 
> Al.
> 
> 
> * Actually in the SKOS Core schema currently skos:TopConcept 
> isn't stated as
> a subclass of skos:Concept, but that is an error of omission.
> 
> 
> ---
> 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 Supekar, 
> > Kaustubh S.
> > Sent: 04 August 2004 14:52
> > To: 'public-esw-thes@w3.org'
> > Subject: RE: [Proposal][SKOS-Core] handling top concepts
> > 
> > 
> > 
> >  
> > Dear Alistair,
> > 
> > As you ritely identified, it doesn't make much of a 
> > difference. Is it sound
> > to make modifications to the core model for trivial requirements.
> > 
> > Regards,
> > Kaustubh Supekar
> > 
> > -----Original Message-----
> > From: public-esw-thes-request@w3.org 
> > [mailto:public-esw-thes-request@w3.org] On Behalf Of Miles, 
> > AJ (Alistair) 
> > Sent: Wednesday, August 04, 2004 8:46 AM
> > To: 'Supekar, Kaustubh S.'; 'public-esw-thes@w3.org'
> > Subject: RE: [Proposal][SKOS-Core] handling top concepts
> > 
> > 
> > In an effort to further explain the top concepts problem I 
> > wrote some stuff up on the wiki ... see 
> > http://esw.w3.org/topic/SkosDev/SkosCore/TopConcepts
> > which tries to explain the issue from a programmatic point of view.
> > 
> > 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
> > 
> > 
> > 
> > > -----Original Message-----
> > > From: public-esw-thes-request@w3.org
> > > [mailto:public-esw-thes-request@w3.org]On Behalf Of 
> > Supekar, Kaustubh 
> > > S.
> > > Sent: 03 August 2004 18:15
> > > To: 'public-esw-thes@w3.org'
> > > Subject: RE: [Proposal][SKOS-Core] handling top concepts
> > > 
> > > 
> > > 
> > > 
> > > Few Questions on the proposal note.
> > > 
> > > Can we attribute narrower and broader concepts specific to 
> > a *scheme*
> > > 
> > > For e.g. 
> > > I have relationship
> > > C
> > > |
> > > A
> > > |
> > > B
> > > In another scheme say A is a topConcept according to your 
> > requirement, 
> > > that indicates, if I am not mistaken A doesn't have a 
> broader term.
> > > A
> > > |
> > > B
> > > 
> > > I think the SKOS Schema currently handles participation of 
> > a concept 
> > > in a particular scheme. Can we specify position of a 
> > concept respect 
> > > to a scheme.
> > > 
> > > <skos:concept rdf:about="http://a.com/Concept/001">
> > > <skos:prefLabel>A</skosprefLabel>
> > > <skos:inScheme rdf:resource="http://a.com/scheme/1"/>
> > > <skos:broader>C</skos:broader>
> > > <skos:narrower>B</skos:narrower>
> > > </skos:concept>
> > > 
> > > How do you represent the alternative hierarchy as mentioned 
> > above and 
> > > attribute it to scheme 2.
> > > The Question is not limited to TopConcepts. We may have a 
> > possibility 
> > > where the position of a concept in an hierarchy might vary across 
> > > schemes.
> > > 
> > > Am I missing something here?
> > > 
> > > Regards,
> > > Kaustubh Supekar
> > > Research Intern
> > > Division of BioMedical Informatics
> > > Mayo Clinic
> > > 
> > > -----Original Message-----
> > > From: public-esw-thes-request@w3.org
> > > [mailto:public-esw-thes-request@w3.org] On Behalf Of Miles, AJ 
> > > (Alistair)
> > > Sent: Tuesday, August 03, 2004 11:32 AM
> > > To: 'public-esw-thes@w3.org'
> > > Subject: [Proposal][SKOS-Core] handling top concepts
> > > 
> > > 
> > > This is a proposal in relation to the requirement outlined in [1].
> > > 
> > > To support identification of top concepts in situations 
> > where concepts 
> > > may be members of more than one concept scheme, I suggest the 
> > > following actions:
> > > 
> > > 1. The skos:TopConcept class be deprecated. 
> > > 2. A new property skos:hasTopConcept be added, with domain 
> > > skos:ConceptScheme and range skos:Concept.
> > > 
> > > See also [2].
> > > 
> > > Al.
> > > 
> > > [1]
> > > 
> > 
> http://lists.w3.org/Archives/Public/public-esw-thes/2004Aug/0001.html
> > > [2] http://esw.w3.org/topic/SkosDev_2fSkosCore_2fTopConcepts
> > > 
> > > ---
> > > 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 Wednesday, 4 August 2004 11:50:31 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:38:52 GMT