Recommend mappings via hierarchical links

[nichtich]

Different to #35 but similar use case:

In der GND ist Fußball Unterbegriff von Ballsport (4004363-0) was wiederum Unterbegriff von Sportspiel (4056422-8) ist. Wir brauchen eine Funktion, so dass ausgehend von Fußball in der GND Ballsport in der BK empfohlen wird, auch wenn Fußball selbst nicht damit verlinkt ist.

[stefandesu]

Isn't this related to https://github.com/gbv/cocoda/issues/512? I'm not sure whether this should be implemented in jskos-server. I guess what we could do is to add a parameter in /mappings which is something like fromRelated and Cocoda provides the related concepts (like parent concept). But I think this should just be implemented in Cocoda with a separate mapping request. There could be a setting with options "off", "always", and "only fallback" or something like that.

[nichtich]

This could be implemented in the client (Cocoda) but then requires a loop with multiple queries. For cocoda this would be ok.

The use case of this feature however is to directly get "corresponding" concepts in concept scheme B from a given concept in concept scheme A. This issue is more related to #35 and to be used in cocoda-winibw and at http://uri.gbv.de/terminology/. But it may make sense to first implement it in a client.

[zuphilip]

[Reacting on this Tweet]: My use case is the new functionality in malibu where I visualize the DDC tree and try to find a mapping to the RVK with the coli-conc API, e.g.

All but the last DDC notation 518.64 is found in a mapping to the RVK. However, I would also be happy to have the first ancestor of 518.64 with a mapping to the RVK, i.e. 518 -> SK 900 (as also 518.6 has no mapping).

Would you consider to add a parameter to find either the direct mapping or the first mapping among its ancestors in the hierarchical order?

[stefandesu]

• Any suggestions for a parameter name to enable this functionality?
• If enabled, should this only be done in case that there are no direct mappings (basically a fallback)? And should it go up the hierarchy only until a mapping is found?
  • I could imagine having three modes: Default is only direct mappings, one mode is to fall back on indirect mappings via ancestor concepts in case there are no direct mappings (and then only go up the hierarchy until a mapping is found), and another mode is to return all direct and indirect mappings (all the way up until the top concept).

[nichtich]

Any suggestions for a parameter name to enable this functionality?

How about expand=up (try anchestors) and expand=down (try children)? We only need the first case by now and document that proper functionality is only guaranteed for mono-hierarchies.

At the /mappings endpoint parameter expand=up will only have an effect of no explicit mapping was found. In this case:

• Iterate the ancestors going up the hierarchy to find a mapping
• If a mapping m is found, return a newly constructed mapping
  • with no creator, time etc.
  • with mapping type derived from m's mapping type as discussed at #35 (this should become part of jskos-tools):
    • if type of m is exactMatch or narrowMatch match the new mapping will also be narrowMatch
    • if type of m is relatedMatch, new mapping type will also be relatedMatch
    • if type of m is closeMatch, broadMatch or mappingRelation, new mapping type will be mappingRelation

In addition it would make sense to link the newly constructed mapping to m but there is no JSKOS field for this yet.

[nichtich]

This is a duplicate of #177 except the GND use case requires traversal of broader (bread-first-search) instead of ancestors.

[nichtich]

@zuphilip We've implemented a feature covering your example, try https://coli-conc.gbv.de/api/mappings/infer?from=518.64&fromScheme=http://bartoc.org/en/node/241&toScheme=http://bartoc.org/en/node/533 to get inferred mappings from BK 518.64 to RVK. This won't work for GND so far as we don't have the hierarchy, but closing this issue unless GND is needed as well.