— the global portal for all things SBML

unique model links


Global IDs across models

It is probably not possible to use annotations as global identifiers across several models. There is no means to control that.

However, the question here seemed to be (at least for us): Is there a way of referring from within an annotation to a model element in another model in an unambiguous way?

  • urn:miriam:BM0015:version:element will be unambiguous

Problem: how to specify the version?

  • possible solutions: create a DOI for each uploaded model version, e.g. using OR using the time stamps

Unique links (use cases)

Referencing things that do not carry a URI

  • references to models can be done using a MIRIAM URN
  • non-URI references inlude web addresses - URLs - local directories

Self reference

  • We'd need something like an XPath here, or a possibility to link from the rdf:resource element to a metaID inside the document.
  • Also, using the proposed urn:miriam:bmdb:BIOM15:version:element link would work, but using this link will loose the information that it is a self-reference.
  • Conlusion: refer to an element in the same document by rdf:resource="self#metaID" where 'self' is a reserved key word.

stable IDs for (local) models and data

  • Decided not be relevant, despite a short "best practice" if we wanted to provide that.


We may want to do this with rdf:IDs as long as we made the specification rule that all rdf:IDs had to be unique within an SBML document.

DW@WOLF: Is this still a relevant comment? Cannot remember what it was referring to.

Linking from model elements to elements of a data file

Regarding the question of linking data to a model in an annotation, the google doc already suggested that

"There does not seem to be any defined MIRIAM uri for that sort of link."

Why not have a best practice saying that the preferred way is to register a resource with MIRIAM, if possible. E.g. if there was an SBRML result repository.

All other solutions, e.g. referring to files on a local repository, or referring to files on an inconsistent URL is nothing stable.

Retrieved from ""

This page was last modified 15:44, 8 June 2010.

Please use our issue tracking system for any questions or suggestions about this website. This page was last modified 15:44, 8 June 2010.