Re: Dinamic hasTopConcept property

Juan, Thomas,

We've noted that "convention", because many times it is indeed the case that the declared top concepts and the one you could infer from your procedure will be the same.

But as Thomas noted, assigning top concepts is also an editorial issue. You might find yourself "infering top concepts" from concepts that have missing broader links, if the KOS is not perfectly maintained.
There are also many cases of KOSs where the very notion of top concept is almost useless. Consider vocabularies like LCSH: I don't remember the exact figure, but if you apply your procedure to it, you will obtain dozens of thousands of top concepts, which is pretty much useless for users. And in fact I guess the editors of the KOS would disagree with considering that what they have built over decades can be used for hierarchical browsing (at least, not for the one where you start from a top-level root). It was just not conceived like that.

So having your procedure available would make sense, especially if you are targetting a known set of well-structured vocabularies. But if you are to ingest many KOSs of various forms in your tool, be sure that you are not making the procedure mandatory, or that at least you can deal with the consequences of applying it, when it is not so useful.

Cheers,

Antoine


> Hi Juan,
> 
> as far as I see you are perfectly right as long as you have only one
> skos:ConceptScheme, and as long as you just think about it.
> 
> In an open world there are many skos:ConceptScheme instances.
> 
> If you make use of the skos:inScheme property for each of your
> skos:Concept instances, you might say something like:
> 
> "Any concept within my scheme which has no broader in the same scheme is
> a topConcept of this scheme."
> 
> (Someone might state that your concept has a broaderMatch to another
> concept in a different scheme, why not? remember broaderMatch is
> subProptery of broader ...)
> 
> I think the difference is about whether you have a decision that some
> concepts shall be the top concepts of your scheme, or you just leave
> this to the editor (who might accidently forget to add some broader to a
> concept ... never trust in editorial staff too much ... ;-)
> 
> In the first case, link from your scheme to some dedicated topConcepts
> just to make sure about this.
> In the second case, you may be right, but there is no explicit inference
> rule in the current skos rec which would safely result in some tops.
> 
> Looking forward to discussion, as I think Juan is basically right, and
> this has not been clarified so far.
> 
> Kind regards,
> Thomas
> 
> 
> Juan Antonio Pastor Sánchez schrieb:
>> Hello everyone,
>>
>> I am developing an application to manage concept schemes, based on
>> SKOS. My question is about the hasTopConcept property. In my opinion
>> this property should be generated dynamically (by inference) during
>> the query of the concept scheme (only for viewing and browsing
>> purposes). As indicated in SKOS-Reference:
>>
>> "The property skos: hasTopConcept is, by convention, used to link a
>> concept to the SKOS concept scheme (s) which are topmost in the
>> hierarchical relations for that scheme."
>>
>> That is, a Top concept would be a concept of a hierarchy that did not
>> have any one broader concept. Therefore, It is not necessary to
>> explicitly define a concept such as Top concept. Thus, the tasks of
>> managing the scheme concept could be simplified.
>>
>> This interpretation would be correct?
>>
>> Regards
>>
>> -- 
>> Ph.D. Juan Antonio Pastor Sánchez
>> Senior Lecturer - Dep. Information and Documentation
>> Faculty Communication and Documentation
>> University of Murcia
>> phone: +34 868 88 8780
>> http://webs.um.es/pastor - http://skos.um.es/
>> pastor@um.es <mailto:pastor@um.es>
>>
> 
>

Received on Friday, 4 December 2009 10:01:49 UTC