search

skohub-io / skohub-vocabs

A lightweight tool to publish SKOS Vocabularies
https://skohub.io/
Apache License 2.0
34 stars 25 forks source link

Support for skos:collection #200

Closed solth closed 1 year ago

solth commented 1 year ago

This pull request adds support for skos:collection as described in https://github.com/skohub-io/skohub-vocabs/issues/159#issuecomment-1293141778

Link from concept to collection:

Bildschirmfoto 2022-10-27 um 18 19 37

Collection page linking to all contained concepts:

Bildschirmfoto 2022-10-27 um 18 19 46

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 commented 1 year ago

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

acka47 commented 1 year ago

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 https://github.com/skohub-io/skohub-vocabs/issues/159#issuecomment-1294562475 for details.

sroertgen commented 1 year ago

@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 commented 1 year ago

@acka47 you did not approve yet.

Yes, because we still have to discuss https://github.com/skohub-io/skohub-vocabs/pull/200#issuecomment-1294750669. What do you think?

sroertgen commented 1 year ago

Yes, because we still have to discuss https://github.com/skohub-io/skohub-vocabs/pull/200#issuecomment-1294750669. 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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

@dr0i Please deploy the changes to production.

dr0i commented 1 year ago

Deployed to production.