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

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