Facilitate use of custom mapping vocabularies in Mapping Manager

[lewismc]

Q: I like SKOS, but are you able to create custom mapping terms? Or load a custom mapping terminology? I think ‘sameas' only holds between individuals in OWL. You need ‘equivalentClass’ for classes.
A: We have long considered support for custom mapping terminologies, and this would not be hard, but more hard than we’ve ever had time for. You are correct that other terms are desirable to have.

@lewismc also notes that essentially the Mapping Manager is unable to support the basic use case which is mapping authoring/creation. The SKOS mapping vocabulary predicates are too limited in scope.

[lewismc]

Linking mmisw/orr-portal#7

[lewismc]

Here's what we've stated will be do

1. Gather user stories for vocabulary creation, this will ensure that the feature matches community need(s).
2. Derive functional and non-functional requirements statements from the user user stories. These requirements will define specifically and clearly how the implementation will meet the user stories.
3. Based on the requirements, implement the feature and accommodating unit tests.
4. Launch the feature as an official part of COR.

[graybeal]

Re item 1, 'vocabulary creation' is not the same as this ticket originally described. The original ticket was to add (or allow the user to add) enough terms to support more complete vocabulary mappings. (The existing terms ARE 'able to support the basic use case which is mapping authoring/creation', but they only do so for the primitive SKOS mappings. That was the basic use case, at least at that time.

I believe the fix for this ticket is to make it possible for users to add their own mapping properties to the list supported by the mapping tool (in the most simple way possible), no more and no less. I don't think the steps listed here are necessary, but of course if you have a use case that isn't satisfied by that fix, describing it here would be helpful. (Potential use cases that come to mind include making the mapping tool reflect any mapping property which is in any of the files—which could be a way to configure the solution to this ticket—and making the tool display mappings better or differently. But both of those are definitely hard.)

Obviously adding use cases to this ticket makes it harder to get this ticket done, so that's a tradeoff should we decide to add them.

[lewismc]

Hi @graybeal I don't disagree with anything you say 👍

I think gathering use cases would be useful. We could for example spend around 2-4 weeks doing this. We could start by generating a use case template, review it at the next COR telecon and then get it out to the masses at the next opportunity.

Any thoughts?

[graybeal]

So I agree that gathering use cases is always useful. The question is whether it's the best use of time. The answer depends strongly on who plans to make use of them: if there is a person who will apply them to solve "the problem at hand"—perhaps more fully solving the problem because people want more features, or better solving it because the original needs were poorly understood—that is a great application.

If we're talking about this ticket as our "problem at hand", I think we have enough understanding of the basic need to formulate a reasonable MVP, though even for that we'd need someone willing to really think through the design appropriately, and then someone to implement the result. So if there isn't anyone (or group) in that category, there's no point even in further analysis.

If we're talking about a larger problem—either solving these needs thoroughly, or adding 'vocabulary creation' to the list of possible needs, I worry about whether you can get a large enough sample of users to do a robust needs analysis. (The question of whether there are enough users to merit the work is arguably moot, because the stronger driver on what gets done is "who is willing to get/contribute the resources to make it happen?") This is similar to the first round of evaluation use cases—they were a good start and very useful for their purpose, but didn't illuminate the true scope of features in systems this complex.

It may be that gathering the use cases will generate the enthusiasm needed to create the support for the development. I've seen you pull this off on multiple occasions, so if you want to give it a go, I'll try to get my basic 'requirements' into the mix for sure! Even if having the use cases doesn't result in the work getting done, it will help many of us understand more how people want to use the system, which is always good. (Returning to my first point!)