Re: skos:hasTopConcept mandatory?

Hello


> Validating (with Poolparty and Skosify)  the resulting controlled
> vocabularies (namely, the various SKOS files) we had the warning that there
> where "loose concepts".
> In some papers this is considered a symptom of poor quality.
> Poolparty just gave this warning (test not passed).
> Skosify says: "Marking loose concept http://...#xxx  as top concept of
> scheme http://...#<ConceptSchemeName>"
> These results seem imply that it is mandatory to express the semantic
> relationship skos:topConceptOf<http://www.w3.org/TR/skos-reference/#topConceptOf> for
> every Concept in the Vocabulary, even if none of them is the root of
> hierarchical relations.
>
>
As an example of an application reading/consuming SKOS, SKOS Play [1] tries
hard to determine the top-level concepts by first looking for
hasTopConcept/isTopConceptOf explicit predicates, but, if none is found,
queries for all the Concepts without a broader property, and not subject of
a narrower property.



>
> A possibility is to create a fake concept who will be the
> skos:topConceptOf, and all the other concepts will be its narrower concept.
> This is working, but is, in my opinion, semantically unsatisfactory.
>
>
Agreed, I would advice against this.


>  Another possibility is to state that every modeled concept is a
> topConcept.
>  If, in the future,would we upgrade the controlled vocabulary to a
> thesaurus (for example, roles as: FullProfessor, Professor, Secretary,
> Accountant, Student, Fellow, etc. could be grouped as narrower of more
> general concepts like: TeachingPersonnel, AdministrativePersonnel,
> PersonsInEducation, and so on) what will we have to do?
>

Update the topConceptOf/hasTopConcept properties to refer to the new root
concepts.


>  Is it acceptable that a TopConcept is narrower than another
> Concept/TopConcept?
>

Certainly not. If a top-level concept is moved down the hierarchy, its
topConceptOf/hasTopConcept properties should be deleted.


>  Or we will have to move the present TopConcepts to Concepts, and
> introduce as TopConcept the more general classes as in the example before?
> For the applications nothing will change, as Concept URIs will remain the
> same.
>
> I think that, as skos:topConceptOf  is a sub-property of skos:inScheme<http://www.w3.org/TR/skos-reference/#inScheme>just stating
> <http://www.w3.org/TR/skos-reference/#inScheme>that a skos:Concept is
> belonging to a Scheme should make it not a loose concept.
>
>
It all depends on how you define a "loose concept"...

Marking every Concept as a topConcept in a flat list does not hurt if you
can easily do it and it does put a burden on future evolution of the
vocabulary. Otherwise you have to trust that consuming applications will
interpret your skos file correctly.

Thomas

[1] SKOS Play : http://labs.sparna.fr/skos-play/

-- 
*
*
*Thomas Francart* - Sparna
Consultant Indépendant
Data, Sémantique, Contenus, Connaissances
web : http://sparna.fr, blog : http://francart.fr
Tel :  +33 (0)6.71.11.25.97
Fax : +33 (0)9.58.16.17.14
Skype : francartthomas