Re: skos:hasTopConcept mandatory?

Regarding this issue my OPINION is as follows:

1) The nature of each KOS/controlled vocabulary will determine the use of
certain properties. In a "flat" glossary (without hierarchical structure)
of terms may not be necessary to specify the properties skos:hasTopConcept
/ skos:topConceptOf.

2) Under certain circumstances, the publication of a KOS as Linked Open
Data may require an explicit link from the Concept Scheme to Top Concepts
as the way to explore the hierarchical structures of KOS. For example, for
any RDF client that retrieves information from a resource of type
skos:ConceptScheme (using content negotiation) the only way to get to the
concepts of KOS (without using SPARQL, since not SKOS vocabularies have an
SPARQL Endpoint) is following the "links" defined by the skos:hasTopConcept
property.

3) I do not see the above case as a lack of SKOS, since it is possible to
define ex:hasConcept as owl:inverseOf of skos:inScheme. Similar situations
can be found to determine the collections belonging to one concept or the
impossibility of defining the concepts that are points of access to
collections. The solution (for now) is to define custom properties like
ex:hasConcept. It might be interesting to explicitly include certains new
properties in possible future revision of the SKOS recommendation, in order
to SKOS achieve greater semantic interoperability in the LOD context
(without losing the sense of the first "S" of SKOS: "Simple").

4) In my opinion, although the SKOS recommendation does not indicate
anything about, a concept with a property skos:topConceptOf should not to
have any property skos:broader.

Regards,
Juan


2013/9/3 Oreste Signore <oreste@w3.org>

>  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 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
> W3C Italy - Office manager
> cell. +39-348-3962627
> Skype: orestesignore
> home page: http://www.weblab.isti.cnr.it/people/oreste/
>
>


-- 
Dr. Juan Antonio Pastor Sánchez
Dep. de Información y Documentación
Facultad de Comunicación y Documentación
Universidad de Murcia
Tel: +34 868 88 7252
http://webs.um.es/pastor
pastor@um.es

Juan Antonio Pastor Sánchez, Ph.D.
Dep. of Information and Documentation
Faculty of Communication and Documentation
University of Murcia
phone: +34 868 88 7252
http://webs.um.es/pastor
pastor@um.es