Re: skos:hasTopConcept mandatory?

Dear Oreste,

skos:hasTopConcept is not mandatory. Especially, if you have a flat list of terms in your original data, it's not super-interesting to mark them all as top concepts (though it would be right from a theoretical perspective). The idea of hasTopConcept was to ease navigation by providing entry points in a hierarchy. But here all your concepts would qualify as equal entry points, if I understand well.

Your issue is that the tools you've used are rather accustomed to hierarchical vocabularies. They can't tell from the data whether it's a flat list or a hierarchical thesaurus, where one would have expected to find top concepts. So it complains, in case it would be really wrong. And in the case of Poolparty, the tools adds statements. As said above is not theoretically wrong, but it may be surprising indeed. I believe Poolparty like these link because it uses them in their software later!

Best,

Antoine


> This mail is to clarify an issue about SKOS and validation
>
> The matter.
> I'm following a project aiming to publish as LOD some existing data, stored in a relational database.
> In exporting data in RDF, we remained strictly adherent to the original database structure. This has been an implementation choice, to be compliant with possible future changes (the underlying applications will still be managed by the legacy software, which could anyway evolve)
> Some fields in the relational tables have values taken from some "dictionary tables".
> In exporting, we could have resolved the joins, but we preferred to keep the original structure, converting the "dictionary tables" into SKOS files.
> Representing terms as concepts, we will get even the multilingualism, useful for future developments.
> The option of having a single SKOS, with as many ConceptScheme as were the dictionary tables, was also considered, but finally implementors preferred to have a single SKOS file, with a single ConceptScheme, for each dictionary table, even if the number of entries is very low (from 5-6 to about 100 entries).
> These controlled vocabularies were obviously totally unstructured, just a flat list of values.
>
> All values have been modeled as skos:Concept, and assigned to a skos:ConceptScheme.
>
>
> As stated in: http://www.w3.org/TR/skos-reference/#L2446, "The property |skos:hasTopConcept| is, by convention, used to link a concept scheme to the SKOS concept(s) which are topmost in the hierarchical relations for that scheme."
> Also. in: http://www.w3.org/TR/skos-primer/#secscheme :"In order to provide an efficient access to the entry points of broader/narrower concept hierarchies, SKOS defines a |skos:hasTopConcept <http://www.w3.org/TR/skos-reference#hasTopConcept>| property. This property allows one to link a concept scheme to the (possibly many) most general concepts it contains"
> To my understanding, the property |skos:hasTopConcept| (and the inverse skos:topConceptOf ) is needed just for efficient access to the concept hierarchies. No need to specify such relations for a simple list of terms/concepts.
>
>
> 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.
>
> There are several way to workaround the error messages, anyway.
>
> 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.
>
> 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?
> Is it acceptable that a TopConcept is narrower than another Concept/TopConcept?
> 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.
>
> I hope you can give me some advice as the matter, IMHO is common in representing controlled vocabularies.
>
> Thank you in advance.
> Best
> oreste
>
>
>
> --
> dott. Oreste Signore
> CNR-ISTI
> cell. +39-348-3962627
> Skype: orestesignore
> home page:http://www.weblab.isti.cnr.it/people/oreste/
>

Received on Tuesday, 3 September 2013 15:50:14 UTC