Support skos:Collection

[schlawiner]

Our organization has classification system where Concepts are grouped by topic, but the grouping topic itself shouldn't be a Concept. I use skos:Collection to reflect this (as opposed to making the grouping topics themselves broader concepts in the hierarchy).
However, skohub-vocabs doesn't display the collection groups in the left sidebar, only the "true" concept hierarchy as defined by broader/narrower.

Example

"History" and "Resources" are collections.

Expected display

History

• biography
• historical source
  • reprint
  • selected readings
• historical study

Resources

• bibliography
  • link collection
• dictionary
• directory

What SkoHub Vocabs displays

• biography
• historical source
  • reprint
  • selected readings
• historical study
  • bibliography
  • link collection
  • dictionary
  • directory

To see this in action, look at my test instance: http://zpidvokabulare.surge.sh/psyndex.de/vocab/methods/index.en.html

[acka47]

Thanks for the feature request, @schlawiner. We will gladly discuss your use case and how to best display skos:Collections with SkoHub Vocabs and then hopefully implement a good solution. I must admit, I haven't used skos:Collection myself until now and do not have a clear idea on how to best implement it.

I think you proposal makes sense for your use case but I am not sure whether it would work for a differing use of skos:Collection. There are two questions that directly come to mind:

• What if concepts are in more than one collection?
• What if not all concepts are part of a collection?

There is probably more to be considered here. Here are two approaches how we could deal with this:

• SKOSMOS has a tabbed sidebar to switch between alphabetical index, hierarchy and group (= skos:Collection) index. We could add something like this to switch between hierarchy and collections.
• I think we should add features step by step starting by adding collection pages and links between concepts and collections: We'd add a page for each collection where all the grouped concepts are listed and linked. In the detail view of a concept would add a link to the collection. This would mean that collections wouldn't be shown in the left sidebar but it might make sense for a start as I think we will need this information anyhow.

The second option would also take into account that we currently don't have a lot of resources to work on SkoHub (which will likely change in the future). What do you think?

[anarchivist]

Hi @acka47 - I also have an interest in being able to use skos:Collection as a grouping method, as the groupings themselves are not concepts for a vocabulary that I have in mind. The SKOS Primer is a good source of reference for this.

Speaking from my standpoint, the second approach might be a reasonable starting point. Thanks for considering.

[acka47]

Thanks for the feedback, @anarchivist . (I am curious: (where) are you using SkoHub Vocabs?)

The SKOS Primer says:

URIs may be allocated to collections, but usually this is not necessary.

I assume it would be much easier to implement skos:Collections in Skohub Vocabs when Collections had URIs so we might require this. Should we?

Furthermore, I'd say that OrderedCollections are out of scope of this issue.

If we agreed on this, this issue could be clarified as follows, ok?

Scope:

• Require a skos:Collection being identified by a URI
• Add collection pages that lists and links to all concepts that are member of the collection.
• Add name of and link to a collection in the detail view of a concept that is member of a collection.

Non-scope:

• Not support OrderedCollections for now.

[anarchivist]

Thanks for the feedback, @anarchivist . (I am curious: (where) are you using SkoHub Vocabs?)

I am experimenting it (privately at the moment) for a couple of small and simple vocabularies - so nothing to see live yet!

I assume it would be much easier to implement skos:Collections in Skohub Vocabs when Collections had URIs so we might require this. Should we?

+1 for me; at least in my case, URIs have been mminted for the cllections

Furthermore, I'd say that OrderedCollections are out of scope of this issue.

+1 for me as well.

Scope:

• Require a skos:Collection being identified by a URI
• Add collection pages that lists and links to all concepts that are member of the collection.
• Add name of and link to a collection in the detail view of a concept that is member of a collection.

Non-scope:

• Not support OrderedCollections for now.

This looks great - thank you for considering.

[acka47]

@solth will now start working on this. For reasons of clarity I sum up the things to be done in this issue:

1. Support SKOS files that contain a skos:Collection with skos:member statements. (I added an according statement to one of my SkoHub Vocabs test files with https://github.com/acka47/testing-skohub-vocabs/commit/81a99dae0af2b498c6bbf8313e90d43efb7b2971).
2. The JSON-LD containing the member statements must be generated from the turtle.
3. An HTML page should be built for each collection with the prefLabel and a list of the member concepts (as a label linke to the concept pager.
4. For concepts that are skos:member of the collection, a "in Collection" statement should be added to the HTML. (As there is no inverse for skos:member we will not be adding it to the concept's JSON-LD.)

Requirements:

• We will only support skos:Collections that are identified by a URI.
• We will not support skos:OrderedCollections for now.

@solth please let me know if anything ist still unclear and don't hesitate to ask question here during the implementation process.

[acka47]

I know, there is already a PR at #200 but I have to add some information her efor the sake of completeness.

As there is no inverse for skos:member we will not be adding it to the concept's JSON-LD.

In a direct correspondence with @solth, I hinted to a solution for this but missed to post it here. Generally, I assumed that the HTML is built from the underlying JSON so that we might need the JSON-LD statement at skos:Concept pages that a concept ist memberOf a collection. We could add this as JSON-LD supports reverse properties. Basically, we could add to the JSON-LD context something like this:

{
   "@context":{
      "memberOf":{
         "@reverse":"skos:member"
      }
   }
}

This would enable adding those statements to the JSON-LD, e.g. in https://test.skohub.io/acka47/testing-skohub-vocabs/heads/master/w3id.org/kim/hcrt/assessment.json:

{
   "id":"https://w3id.org/kim/hcrt/assessment",
   "memberOf":"https://w3id.org/kim/hcrt/test_collection"
}