- From: Mark van Assem <mark@cs.vu.nl>
- Date: Wed, 24 Aug 2005 11:35:18 +0200
- To: Antoine Isaac <Antoine.Isaac@kb.nl>
- CC: public-esw-thes@w3.org
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