Re: ISSUE-160: Allowing collections in semantic relationships

Hi Alistair

> What I'm trying to say is, in my experience, for a thesaurus where
> node labels have been used, *either* of the above approaches could
> reasonably be taken. 

Yes!

But I tend to disagree with the fact that one should be always preferred 
over the second, and with the following:

> How the data is represented within whatever thesaurus management
> system is used to manage the thesaurus is essentially irrelevant,

Consider an example where the *only* thesaurus representation available 
uses exactly the same hierarchical relation. I think this is what 
happens at AAT [1]. Granted, the "guide terms" are of clearly different 
nature. But the hierarchical link itself (e.g. "preferred parent") is 
not different, whether you point to a normal concept or a guide term.

What if the access to the hierarchy was judged more important by AAT 
designers than the distinction between guide terms and concepts? Nothing 
in the representation (nor in the documentation [2], I would say) 
supports an explicit choice between the two. And there is no alphabetic 
display such as the one in your airplane example -- where the NT links 
nicely stand between "real" concepts -- which would help to make a choice.

I do believe that the Collection approach is conceptually cleaner. But 
it will often imply expliciting something that is only kept very 
implicit otherwise, which is altogether questionable. Especially when 
breaking the asserted hierarchical links cannot be easily compensated by 
some hierarchy generation algorithm -- indeed my examples for which 
Diego's algorithm had problems were coming from AAT.

As often in SKOS, the usefulness (of which "ease of use" is an important 
aspect) will be crucial in those conversion decisions. Hence my liking 
your sentence on "reasonable approaches" much more.
Indeed I'm confortable with saying that SKOS "offers the opportunity" to 
represent things in a relatively clean way. But not with saying that 
this opportunity is a best practice which should be preferred over 
simplicity, when there is doubt.

Cheers,

Antoine

[1] 
http://www.getty.edu/vow/AATFullDisplay?find=chairs&logic=AND&note=&page=1&subjectid=300037775
[2] 
http://www.getty.edu/research/conducting_research/vocabularies/aat/about.html

> Hi Doug,
>
> Thanks for your response. Further comments inline.
>
> On Sun, Nov 16, 2008 at 12:56:39PM -0000, Tudhope D S (AT) wrote:
> > Hi Al
> >  
> > thanks for getting back
> > I take your points about indexing and correspondence between SKOS and BSI.
> > However, they don't address the main issue I wanted to raise. I see your personal note deals with it more and I think indicates that this issue is still somewhat under consideration?
> >  
> > I may have confused things by suggesting a work around. Let's set aside the non-indexing issue for now.
> > I'll restate the issue:
> > Concern: Insufficient support/guidance for legacy systems wrt guide terms / facet indicators
> >  
> > My concern is that SKOS collections do NOT represent common practice in most existing thesauri
> > and (if this is true) there is a danger that they might constitute a significant barrier to take up of SKOS by vocabulary owners who would otherwise wish to do so, unless appropriate guidance/alternatives are available.
> >  
> > I think conversion of legacy thesauri to SKOS is an important application for SKOS and its wider take up.
> > Do we know how many thesauri actually follow the SKOS collections for such structures? 
> > I don't think I know of any though I expect a few exist.
> > Most that I know incorporate facet indicators as part of the hierarchy.  (I'm happy to be corrected if this not the case)
>
> I'm not sure what you mean by "part of the hierarchy".
>
> Consider the following example. The systematic display for my example
> aeroplane thesaurus looks like this:
>
> ---
> aeroplanes
> .<aeroplanes by wing number>
> ..monoplanes
> ..biplanes
> ..triplanes
> ---
>
> The alphabetic display for my thesaurus looks like this:
>
> ---
> aeroplanes
>   NT biplanes
>   NT monoplanes
>   NT triplanes
>
> biplanes BT aeroplanes
>
> monoplanes BT aeroplanes
>
> triplanes BT aeroplanes
> ---
>
> Now, is "aeroplanes by wing number" part of "the hierarchy"?
>
> My point is, for a thesaurus like this, you have an *open choice* about
> how to represent the underlying data using SKOS.
>
> The following choice would be compatible with the above displays,
> would be consistent with the SKOS data model, and in my opinion
> follows best practice (also consistent with BS8723-5):
>
> ---
> ex:aeroplanes rdf:type skos:Concept ;
>   skos:narrower ex:monoplanes, ex:biplanes, ex:triplanes .
>
> ex:aeroplanes_by_wing_number rdf:type skos:Collection ;
>   skos:member ex:monoplanes, ex:biplanes, ex:triplanes .
> ---
>
> The following choice would also be consistent with the SKOS data
> model, although in my opinion is not best practice:
>
> ---
> ex:aeroplanes rdf:type skos:Concept ;
>   skos:narrower ex:aeroplanes_by_wing_number .
>
> ex:aeroplanes_by_wing_number rdf:type skos:Concept ;
>   skos:narrower ex:monoplanes, ex:biplanes, ex:triplanes .
> ---
>
> What I'm trying to say is, in my experience, for a thesaurus where
> node labels have been used, *either* of the above approaches could
> reasonably be taken. 
>
> >  
> > What do we expect vocabulary owners who do not follow the SKOS collections semantics to do?
> > If we expect them to change their vocabulary structure is that a realistic expectation?
>
> Again, I'm not sure what you mean by "change their vocabulary structure"?
>
> For a thesaurus such as the example above, either choice could
> reasonably be made wrt to the SKOS representation. In either case, no
> change would be required to the systematic or alphabetic displays. 
>
> How the data is represented within whatever thesaurus management
> system is used to manage the thesaurus is essentially irrelevant, and
> need not be changed either. How you structure and manage your data
> within your systems, and how you expose your data to the rest of the
> world, need not be the same.
>
> > I personally like the SKOS collections semantics but the issue is a concern because I'd like to see wide take up of SKOS by existing vocabularies. Successful standards need to strike a balance between best practice and legacy practice. Antoine's extensions [your ref 6 below] seem to go towards meeting this issue thought I'm not sure what their status is?
> >  
> > I think though at least some guidance is needed in the primer with some suggestions for what to do if legacy vocabularies owners do not want to completely restructure for guide terms/facet indicators. Maybe this could be considered for final primer version?
>
> To reiterate, I don't believe that using the SKOS collections
> framework as illustrated in the first option above requires any legacy
> vocabularies to restructure anything. How they structure their data
> internally and how they expose their data to the world could be (and
> often are) different.
>
> Does this make sense? 
>
> Kind regards,
>
> Alistair
>

Received on Tuesday, 2 December 2008 15:43:18 UTC