Support for skos:collection

[solth]

This pull request adds support for skos:collection as described in #159 (comment)

Link from concept to collection:

Collection page linking to all contained concepts:

Since SKOS does not provide an inverse for the skos:member relation, collection membership of concepts is determined and stored manually during page creation.

Fixes #159

[acka47]

@sroertgen will do the code review next week, I will do a functional review.

[acka47]

From a functional view, this already looks very good.

Since SKOS does not provide an inverse for the skos:member relation, collection membership of concepts is determined and stored manually during page creation.

IMO, it remains to be dicussed whether we could/should also include the inverse of skos:member in the JSON-LD by defining memberOf with @reverse in the JSON-LD context, see #159 (comment) for details.

[sroertgen]

Thanks for that one :)

[sroertgen]

looks goot to me, just added a key to the li element in Collection.js

[sroertgen]

@acka47 you did not approve yet.

From my side everything is good. At some point in the future, we might have to think about if we want to display the collection also elsewhere, so users can navigate them. But that is out of scope here

[acka47]

@acka47 you did not approve yet.

Yes, because we still have to discuss #200 (comment). What do you think?

[sroertgen]

Yes, because we still have to discuss #200 (comment). What do you think?

Do you have a specific use-case in mind for this? Since this is no SKOS property I think people are not expecting it and would rather use a CONSTRUCT SPARQL query if they would need it. On the other hand, the more links the better (?)

One other thing I just noticed: If the skos:member contains an URI that is not a Concept of the current Concept Scheme it won't be displayed in the SKOS-Collection and the JSON-LD . Is this what we want? I could also imagine that we show the URI (since we don't have the prefLabel) and also show in the JSON-LD. What do you think, @acka47 ?

[acka47]

Do you have a specific use-case in mind for this?

No, I haven't. I am just concerned about consistency. Until now, everything that you can see in the HTML is also available as structured data. It might lead to confusion when this is changed. On the other hand, adding a relation that is not part of SKOS will also confuse some users. As there is no perfect solution, I am ok with leaving it as is.

Since this is no SKOS property I think people are not expecting it

I would not assume that a SkoHub Vocabs user is savvy about all the SKOS properties.

One other thing I just noticed: If the skos:member contains an URI that is not a Concept of the current Concept Scheme it won't be displayed in the SKOS-Collection and the JSON-LD . Is this what we want? I could also imagine that we show the URI (since we don't have the prefLabel) and also show in the JSON-LD. What do you think, @acka47 ?

Interesting. I assumed skos:Collections are used for grouping concepts within a concept scheme and if I understand correctly, this is also the original use case by @schlawiner. I don't think we need to enable adding "external" concepts by now and can open another issue when the requirement is raised. (And then we can also think about fetching the label for display.)

[sroertgen]

Interesting. I assumed skos:Collections are used for grouping concepts within a concept scheme and if I understand correctly, this is also the original use case by @schlawiner. I don't think we need to enable adding "external" concepts by now and can open another issue when the requirement is raised. (And then we can also think about fetching the label for display.)

Yes, I also thought so, but the SKOS-Primer and the SKOS-Reference don't seem to prohibit that a skos:Collection can also contain members from other Concept Schemes.

[...] I am ok with leaving it as is.

Well then, I think we are good to go

[acka47]

+1

[acka47]

@dr0i Please deploy the changes to production.

[dr0i]

Deployed to production.