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.

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

@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.

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

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?

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.

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

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>

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?

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.

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

#349