RE: ISSUE-160: Allowing collections in semantic relationships

Hello all,

Sorry to jump in here late, but I've only just had a moment to properly work through this thread, and I can't resist throwing a couple of observations on the pile...

Since I've been experimenting with SKOS, I've wondered just *what* it intends to exchange.  Does it exchange a 'tool' for organising resources or 'data' about such a tool?  My impression, which has largely been confirmed by this thread, is that it is the latter.    If so, then it seems to me that the use of semantic terms like collection, broader than, narrower than *are* primarily to be used to articulate documentary (and therefore presentational) information about KO systems, and that labels for these concepts may have only a tenuous link to what these concepts mean or how they behave in the actual KOS itself.

Is my understanding correct?

If so, my second question is , what uses should these SKOS representations be expected to support? We've seen some examples of linking to create a network of sorts between similiarly pre-synthesized concepts in other schemes (I'm primarily referring to the gene database). These networks are formed between the URIs, and do not seem to be doing very much with the relationships expressed in the SKOS (if my understanding is correct).  What is the depth of such a network, and doesn't it depend quite heavily on tacit agreement between different organisations' interpretation of 'Concept'?

Can a SKOS file be used  as Christophe Dupriez suggested for distributed (I assume machine) indexing and retrieval?  My impression is no.  In my own use of the standard for a simple indexing/retrieval system[1], it was the unformalised principles of how the tool worked that needed to be exchanged (even between areas of our application stack) in order to digitally recreate the KOS.

In our implementation, a lot of the 'knowledge' remained in our heads, was tacitly expressed via material aspects of the format[2] or was written into surrounding software.  In fact, as Aida has suggested, we primarily used our SKOS as an artifact of modeling - a diagram of sorts that people could quickly grasp and talk (or write) around while implementing algorithms that employed various principles of the taxonomy.  In fact it worked well in this role, but I didn't finish the project feeling that the SKOS we had produced was a tool, nor that it alone could be shared in a meaningful way with others who wanted to use it for a similar purpose[3].

If my observer take on the situation is correct, then I'd just like to conclude by agreeing with the sentiments expressed in this thread  about the need to look at older forms and systems for some guidance as SKOS moves forward and to suggest that the primer should carefully communicate  the utility of the standard to potential adopters.

Regards,
Tamara

[1] built using an earlier version of the Primer and Recommendation and expressed using SKOS RDF/XML.  Indexers were applying pre-coordinated subject strings via notation to resources, strings were composed of three terms, second and third level terms could belong to more than one 'class', and in retrieval, the class order was not fixed - users could access the hierarchy from any point.
[2] the presence of children or parents, idiosyncratic use of attributes, and even the direction in which we designed the SKOS  tree to be processed.
[3] And this was partly due, I'm sure, to weaknesses in our interpretation of the standard- not to weaknesses in the standard itself.

--
Tamara Lopez
Centre for Computing in the Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL (UK)
Tel: +44 (0)20 78481237
http://www.kcl.ac.uk/cch

Received on Thursday, 18 December 2008 17:09:14 UTC