The mapping tool is hard-coded with the 5 SKOS mappings. Some users need to create other mappings on a regular basis. This task is to create the ability for a user to manage their own custom mappings.
The ideal scenario would be transferrable to other users, either within the tool or by exporting to a text file (JSON fine) then importing it. (This would also let a user just edit their mapping options offline, then re-import.
I think the key fields are 'symbol', property definition (full IRI), short label (?), and description (which goes in the pop-up tip). (Would we need to include the originating property vocabulary and term ID for anything?)
The 'symbol' could at first be a letter or special character. A significant improvement is to allow any Unicode, or any emoji, or an icon representation.
We need this rather badly, because right now some users are creating 'false mappings' using our 5 SKOS mappings, then mapping those properties to their own (very different) concepts in their own tools. We need to get them to use our tool to do their mappings the right way, or all the other users will be very confused.
Reference the last comment of #79, which alludes to this desire:
A general ability to adapt a mapping interface to any kind of properties (not just SKOS properties) would be pretty slick. But is a different topic then we've initially addressed. (Actually, I think this may have been driven originally by the desire to easily add mapping relations to the VINE interface. But this request deserves a separate issue.)
The mapping tool is hard-coded with the 5 SKOS mappings. Some users need to create other mappings on a regular basis. This task is to create the ability for a user to manage their own custom mappings.
The ideal scenario would be transferrable to other users, either within the tool or by exporting to a text file (JSON fine) then importing it. (This would also let a user just edit their mapping options offline, then re-import.
I think the key fields are 'symbol', property definition (full IRI), short label (?), and description (which goes in the pop-up tip). (Would we need to include the originating property vocabulary and term ID for anything?)
The 'symbol' could at first be a letter or special character. A significant improvement is to allow any Unicode, or any emoji, or an icon representation.
We need this rather badly, because right now some users are creating 'false mappings' using our 5 SKOS mappings, then mapping those properties to their own (very different) concepts in their own tools. We need to get them to use our tool to do their mappings the right way, or all the other users will be very confused.
Reference the last comment of #79, which alludes to this desire: