user-customizable mappings in mapping tool

[carueda]

Entry in old system: https://github.com/mmisw/mmiorr/issues/380

One possible approach:

• Define a specific vocabulary for the default mapping relations; currently
  • skos:{exact/close/narrow/broad/related}Match
  • owl:sameAs
• the mapping editor exposes the relations in that vocabulary

(so, the above would be a general improvement to the tool)

• for new, user-given relations, allow to capture those in the mapping ontology itself. Ideally, the "new" relation for purposes of the mapping tool should actually be some standard one in the semantic community. As part of the relation specification, the user would enter the predicate URI along with additional, pre-establish set of attributes needed by the tool (desired symbol, tooltip, etc.)

[carueda]

@graybeal Any further reactions on this?

[graybeal]

I added some comments.

[carueda]

Can you please add those comments in this ticket (mmiorr is the "old" system, where I have a label Addressed_in_ORR3 for issues addressed here and in orr-ont). Thanks!

[graybeal]

Oh, right. Sorry!

I would not suggest capturing user-given relations in a single mapping ontology. They are much more likely to be used across multiple ontologies, or all ontologies (and maybe not even with an MMI mapping ontology, if they map external to external.

Some updated thoughts. (I still think this is pretty essential.)

The symbol is maybe not so critical, given we've moved away from them. But I think they are valuable.

It is a requirement to indicate the unique identifier for the concept, and that this be discoverable by users. The source ontology where it is defined is a plus.

I think it's pretty important to make it possible to share these config files/specifications. Even if we don't build a framework for keeping them (i.e., a library of mapping configs), I think it would be really helpful to have an 'export to JSON/import from JSON' capability for them. At minimum, just storing the configuration as JSON (hmm, not sure where -- I guess associated with their profile) would let us move them around for people. But easier for them would be to surface the JSON in their profile, where they could edit it or copy it to send to someone else.

[lewismc]

Hi @carueda @graybeal I am VERY interested in this issue. Now that I have started working on the WIndEnergyMapping. Put simply, skos:{exact/close/narrow/broad/related}Match are simply not substantive enough to capture what I need to express. I found two locations which need to be augmented in order to facilitate use of user-defined predicates within a mapping ontology.

@graybeal if you are interested, I would like to work with you on flushing out (some of) this wind energy glossary mapping ontology. This is an excellent way to demonstrate the usefulness of so much of the software and data semantics we have within COR.

[carueda]

@lewismc One not-very-difficult solution:

Capture the set of possible mapping predicates in the general configuration

• the default object for such new entry is the current set of mapping as defined in m2r.js
• so we are addressing this at the configuration step for an ORR instance
• the default value can of course be expanded as needed/convenient to propagate the "best-practice" for any ORR instance in general

I know you are looking into other improvements as well (thanks!) , so I could take a closer look at this if you'd like..

[graybeal]

I feel obligated to point out my dream solution here (because in a way, it also is not very difficult):

If the user simply has a config file of any sort in their home directory—or perhaps better, if COR/ORR gives them the ability to manually edit this particular configuration in their user preferences—they could list whatever mappings they need for their purposes.

Then COR could just read that profile and add those mappings to the end of the existing list in that user's UI. I can't think of any reason to constrain the available mappings to a fixed set.

I guess one problem is that COR/ORR has to be capable of handling every mapping in every file, so it has to also read the mappings in a file, and make all those available. But not impossible.

And a second problem is that my mapping is your object property relation. So really people could subvert the mappings editor into a property relation editor, and COR/ORR would have no way to tell which of the properties in a file were or were not mappings, unless we used the configuration file(s) to declare what the 'legitimate' mappings were.

Well, that was fun. Back to whatever approach you think best. ;-)

@lewismc Let's talk about wind energy glossary mappings off-github :-)

[lewismc]

Hi @carueda @graybeal I would really like to discuss the solution at our next COR telecon. We do however have an awful lot of information to distill from the ESIP meeting. Maybe we could have a 2hr telecon next time around so that we can give adequate thought to these issues?

[graybeal]

Robert has an OWL file on metadata that may be helpful here.