Re: SKOS Extensions ... broaderDirect/narrowerDirect ... ?&In-Reply-To=<F5839D944C66C049BDB45F4C1E3D

Hi Antoine, all,

The question of distinguishing between immediate parents/children is 
also present for rdfs:subClassOf. It requires some calculation but 
it's possible to determine the direct relationships (see also the 
directSubclassOf operator in SeRQL [1]) by determining that there 
isn't an intermediate class Z between classes X and Y. So a "direct" 
relationship is not indispensible I think.

Of course it would be easier if the relationships were there 
explicitly from the start. If people think that's better to have then 
I would consider putting skos:directBroader/Narrower into the core and 
recommend its usage instead of putting it in the extensions [2], as 
you already say.

I couldn't come up with a use case in which it is *crucial* to make 
the distinction, but maybe some others on this list can?

Cheers,
Mark.

----
[1] http://www.openrdf.org/doc/sesame/users/userguide.html#d0e1658
[2]http://lists.w3.org/Archives/Public/public-esw-thes/2005Jun/0004.html


Antoine Isaac wrote:
> Hello,
>  
> I don't know if you are searching for beginners' (see end of the mail) 
> thoughts which might be redundant with previous talks.
>  
> If yes, then I would encourage Alistair's proposal [1] instead of 
> raising objections. By using a 'directBroader' we make a distinction 
> which is relevant from a 'representational' point of view. The distance 
> between a parent and a child is arbitrary, as Stella points out [2], but 
> this arbitrariness might be something to keep  trace of into a thesaurus 
> representation. Indeed not introducing such a 'direct' relationship may 
> imply loosing some valuable insight of the very context where the 
> thesaurus was built.
>  
> Considering that declaring such a property as a rdfs:subPropertyOf 
> skos:broader gives a semantics that is fully compliant with 
> 'broader-only' view (provided we use a proper RDFS engine), this direct 
> property is definitevely something to consider in SKOS extension, if not 
> in core itself.
>  
> Alistair's remark [3] about deciding whether
> - creating a new direct non-transitive subproperty of skos:broader and 
> keep the skos:broader property transitive or
> - modifying 'skos:broader' so as to make it non-transitive, and 
> introducing a new super-property which would be transitive
> is quite confusing at a first glance, since it is after all about 
> choosing names for people who'll try to get into the RDF representation 
> itself. If just use skos:meferfj for the first and skos:zflzefj for the 
> second then both will be unnatural and you might guide your users as you 
> want ;-)
> However I feel that this might not be a popular solution. In fact if the 
> aim is to attach SKOS notions to natural meanings by their names, then 
> it might be better to keep the first interpretation of broader (the one 
> of current SKOS) : its transitivity is quite natural for human users and 
> some document retrieval systems. And I don't feel that the distinction 
> between 'broader' considered as direct and 'undirectBroader' (the 
> possible transitive subproperty) is more natural than the one between 
> 'directBroader' and 'broader' considered as transitive.
>  
> The problem thereafter would be to urge people to use 'directBroader' 
> instead of 'broader' whenever they can. This might be done via the 
> introduction of 'directBroader' in the core itself, or the insertion put 
> a strong 'best practice advisement' in SKOS core refering to SKOS extension.
> But the first idea that people will spontaneously use the classical 
> broader property while encoding thesauri might be false :
> - if the thesaurus representation is created via automatic translation 
> means then it won't be difficult to change the procedures
> - if a human user want to create manually those representations, then it 
> is a easy way for him to have more value (even if potential) for his 
> money. At least compared to the effort of getting used to SKOS and use 
> it to create or modify resources that may be huge.
>  
> That being said, I would appreciate any counter-argument based on your 
> experience. We are a young and innocent team just beginning to work 
> about using semantic web techniques to access data that is indexed 
> against thesauri...
>  
> Best regards,
>  
> Antoine Isaac
>  
> [1] http://lists.w3.org/Archives/Public/public-esw-thes/2005Jun/0004.html
>  
> [2] http://lists.w3.org/Archives/Public/public-esw-thes/2005Jun/0006.html
>  
> [3] http://lists.w3.org/Archives/Public/public-esw-thes/2005Jun/0005.html

-- 
  Mark F.J. van Assem - Vrije Universiteit Amsterdam
        mark@cs.vu.nl - http://www.cs.vu.nl/~mark

Received on Wednesday, 24 August 2005 09:35:26 UTC