search

gbv / cocoda

A web-based tool for creating mappings between knowledge organization systems.
https://coli-conc.gbv.de/cocoda/
MIT License
39 stars 5 forks source link

Support custom/semantic mapping types #577

Open nichtich opened 4 years ago

nichtich commented 4 years ago

The mapping types should be configurable to support custom mapping types, e.g. "followed by". A custom mapping vocabulary would best be mapped by itself to SKOS mapping types for interoperability. A mapping type must have at least a label, an URI, and an Icon (in form of a Unicode character).

nichtich commented 4 years ago

See https://github.com/gbv/jskos-tools/blob/master/lib/mapping-types.json for default SKOS mapping types, harvested from Wikidata for translations.

stefandesu commented 4 years ago

I have several questions in this context:

  1. JSKOS' type property is currently only an array of strings (URIs). Would it make sense to change this to objects, so that we have more flexibility when it comes to mapping relations?

  2. It feels like it makes sense that different Cocoda instances, or even different combinations between vocabularies inside a single instance, have different options when it comes to the mapping type. This might lead to issues with interoperability though, in case one instance doesn't understand the mapping type of some mapping which was created on a different instance. One way to mitigate is to have the type as an array of objects and then add a SKOS mapping type in addition, as you have suggested. In that case we would have to show some indicator that the type was actually more specific, but isn't supported in the current instance. Alternatively, if we don't want to change the array to objects, we could add SKOS types as the second element of the array, so if an instance doesn't understand the first element, it can fall back to the other. (Although this won't work for current clients because they were hardcoded to use the first element of the array. But the same problem is with the other solution, rather more of a problem even, because older clients expect a string, not an object.)

  3. As far as I understood today's discussion, it might even be necessary to have more complicated relationships than simply "a relation of type XYZ", i.e. mapping types could have something like parameters, for example a date or date range. It might make sense to look at how Wikidata implemented this, AFAIK Wikidata has support for more complicated relationships like that.

nichtich commented 4 months ago

The use case is to extend the list of SKOS mapping types with more types from this list. Corresponding issue: https://github.com/gbv/jskos-tools/issues/42

I think that mapping type as array of URIs is enough. For specific, extened types the first value will always be http://www.w3.org/2004/02/skos/core#mappingRelation for instance:

["http://www.w3.org/2004/02/skos/core#mappingRelation,","http://example.org/special-type-whatever"]

If the Cocoda instance does not know http://example.org/special-type-whatever there should be a special indicator, indeed. This Unicode character may be used:

⇴ extended mapping type: http://example.org/special-type-whatever

  1. [...] more complicated relationships

That's more a acadmic discussion. We had a use case in our collaboration with Dagobert Soergel but is was more theoretic, so not needed for now.