[New metadata element]: MappingSet.curie_map

[joeflack4]

Element id (e.g. creator_id, mapping_tool_version):
curie_map

curie_map:
    OMIM: http://www.omim.org/something/something

Value data type (e.g. URI, URL, text, xsd:boolean):

map

Description
A map of CURIEs. CURIE maps already exist in the SSSOM metadata and many files that are currently in use, so strange for it not to be in the spec. It is also commonly called prefix_map.

[jamesamcl]

Would it be mandatory for all CURIE prefixes to be in the CURIE map?

We have been using Bioregistry (tagging @cthoyt) to map "curies" (or at least prefix:localPart database IDs) to URLs, which are not always IRIs and therefore sometimes have complex formats e.g. Chemspider:4481878 to http://www.chemspider.com/Chemical-Structure.4481878.html.

Because these are not prefixes there's nothing I can put in the prefix map. But I still want to be able to put Chemspider:4481878 in the mappings table even if Chemspider can't be in the CURIE map.

Also @matentzn there are a lot examples in the OLS extraction like this, and in many cases it's valuable data so I don't think we should omit.

[cthoyt]

I think there are a few issues conflated in your comment @udp

inside SSSOM, everything is represnted by CURIEs, so if you have a CURIE appearing anywhere in an SSSOM document with a prefix that's not in the prefix map, then your document is not semantically sound (for lack of a correct technical word)

the issue of URLs vs IRIs doesn't really matter since for all semantic web stuff, you don't actually care if something is a URL

when it comes to CURIEs with weird URI format strings that don't end in the $1, one solution is to just use the bioregistry URL, which does behave nicely

[jamesamcl]

@cthoyt thanks, this makes sense; I think one of the problems is that bioregistry doesn't differentiate between IRIs and URLs. If it was clear that a mapping was to an URL I would use the bioregistry prefix for the IRI instead.

[cthoyt]

Can you elaborate a bit more? I’m not quite sure i understand what your needs are with differentiating between URL and IRIs. This probably is related to some other requests for making PURLs more carefully annotated. We can move discussion onto slack or a
Different issue if this getting off topic

[matentzn]

Everything is slightly off topic here, can we open https://github.com/mapping-commons/sssom/discussions for all unanswered questions and I will answer them?

[matentzn]

The big question at the moment is if this can be represented in LinkML by requesting a new primitive type (Dict[String,String]) or some other means. I reached out to @cmungall to hear his position on this.

[cmungall]

Of course! LinkML schemas are full of such things, including the prefix map at the top of every LinkML schema! The meta model is just another schema. This is covered in the spec but we need to add to the faq and here https://linkml.io/linkml/schemas/inlining.html#inlining-a-single-valued-object TLDR just create a class with two slots, declare one a key. If a multi valued reference to this is inlined it can be inlined as a SimpleDict, ie key val pairs

…

On Mon, Feb 5, 2024 at 4:22 AM Nico Matentzoglu ***@***.***> wrote: The big question at the moment is if this can be represented in LinkML by requesting a new primitive type (Dict[String,String]) or some other means. I reached out to @cmungall <https://github.com/cmungall> to hear his position on this. — Reply to this email directly, view it on GitHub <#225 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAMMOIMDHRPRGQYR3RYU33YSDFGTAVCNFSM575YCZTKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOJSGY4DOMZSHE3A> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[matentzn]

I am looking a bit at https://github.com/linkml/linkml-model/blob/aab9842be0e230c0040688dfc6ffa26696c97827/linkml_model/model/schema/meta.yaml#L2180

But not yet 100% clear how this works

[gouttegd]

I think I got it. Basically it would be something like:

prefix_name:
  key: true
  range: ncname

prefix_url:
  range: uri

prefix:
  slots:
    - prefix_name
    - prefix_url

curie_map:
  range: prefix
  multivalued: true
  inlined: true

The key part (pun intended) being the key field in the declaration for the prefix_name slot. This is what indicates than the curie map should be serialised as

curie_map:
  <prefix_name>: <prefix_url>

rather than

curie_map:
  - prefix_name: <prefix_name>
    prefix_url: <prefix_url>

[cthoyt]

Extended prefix maps already fit the bill for this!

https://curies.readthedocs.io/en/latest/struct.html#extended-prefix-maps

Let's reuse that rather than defining a new ad-hoc thing

is there a way we can make a resuable linkml model inside the curies package that can be reused everywhere?

[matentzn]

Let's reuse that rather than defining a new ad-hoc thing

This is not inventing anything new, just trying to add the existing curie_map to the model. No changes at all.

is there a way we can make a resuable linkml model inside the curies package that can be reused everywhere?

We should 100% add a small model for EPMs! But this is not related to this issue here, which is only to define what is already there.

[matentzn]

@gouttegd this needs works in terms of docs etc, but I implemented what you suggested:

#349