Open Issue: What's in a name

Synopsis:
In BioPAX NAME, SHORT-NAME and SYNONYMS address related properties. Some improvements were proposed to make them more OWL compliant and generally more intuitive and clarify their usage.

Existing Documentation:
NAME: The preferred full name for this entity.

SHORT-NAME: An abbreviated name for this entity, preferably a name that is short enough to be used in a visualization application to label a graphical element that represents this entity. If no short name is available, an xref may be used for this purpose by the visualization application.

SYNONYMS: One or more synonyms for the name of this entity. This should include the values of the NAME and SHORT-NAME property so that it is easy to find all known names in one place.

Issues:

 * 1) The naming is confusing, and so far led to a lot of ( rather unnecessary ) semantic discussions ( Yes, I am talking about the name of the name. :) ) . A better naming would be :
 * 2) * a) NAME-> PREFERRED-NAME (DEFAULT-NAME? STANDARD-NAME?)
 * 3) * b) SHORT-NAME-> DISPLAY-NAME
 * 4) * c) SYNONYMS -> NAME ( I think we need to be consistent in using non-plural forms as property names)
 * 5) Why don't we use RDFS: Label instead of these properties?

This has the benefit of reasoning-wise more neutral and more friendly with RDF tools. There is already several existing discussion threads on this. However from the DX point of view, it still is very important to specify (i) what entities should an importer expect to have a semantically important name, (ii) to specify PREFERRED-NAME and DISPLAY-NAME are two special names. So I suggest we stick to the properties.


 * 1) What makes NAME and SHORT-NAME different from other NAMES ( synonyms)? I believe we need to specify in the documentation, whenever there is a standard authority ( such as HUGO) the preferred name should always match this one. If such and authority lacking, we might wish to leave this field empty ( just add your own database/tool specific name as a SYNONYMS). We can validate and even automatically fix this given that the proper unification xrefs are specified, or using existing name disambiguation services ( such as iHOP). As for the SHORT-NAME it should be considered more or less volatile, as many tools calculate their display names on-the-fly.

1.The latter aspect mentioned in the documentation of SYNONYMS could have been directly encoded in OWL by making NAME and SHORT-NAME sub-properties of SYNONYMS.

Proposed Solution:

 * a) Rename NAME-> PREFERRED-NAME
 * b) Rename SHORT-NAME-> DISPLAY-NAME
 * c) Rename SYNONYMS -> NAME
 * d) Make PREFERRED-NAME and DISPLAY-NAME sub properties of NAME
 * e) Make necessary documentation changes.

-

Feedback from Gary Bader
I agree and think these property name changes are a good idea. I also like the sub-property idea. I also think using rdfs:label would make BioPAX harder to use, since up until now we always use properties. This does not stop people copying information from the properties into rdfs:labels for use with other tools.

[Gary also responded to some feedback from Alan Ruttenberg, see below.] -

Feedback from Peter Karp
I really must request that we not make superficial changes like those below in BioPAX. It is not that these changes are not reasonable -- most of them are. However, making these kinds of changes decreases compatibility between successive versions of BioPAX, and creates a burden for BioPAX implementors to update their implementations. The cost is not worth the small benefit of these changes.

...Again, I have no objection to clarifying the documentation -- it could use improvement in many places.

Emek : I agree, but I am willing to provide converters from level 1 and level 2. But if you have some extra information in your internal representation system that could use new features in the next level, obviously you would need to update your exporters. But if that is the case, you need to modify your exporter anyway, and in my opinion the extra cost incurred by such namings would be relatively much less significant compared to adopting States/Generics, URI/CV or Gene Regulation.

Peter: As you say, converters don't help us. We still have to change our code.

Emek : If you have importers however, then such changes would definitely be costly. Is this the case?

Peter : We have an importer in progress.

Emek : As you said, these fixes are superficial, but nevertheless can be useful for decreasing the adoption curve for newcomers. So I still would like to argue in favor of making those changes. I would be more than willing to provide you with some documentation on how I would map level 2 to level 3, and what would be the possible issues. Please let me know if this sounds as a workable plan.

Peter: No, I stand by my position of requesting that only important changes be made to biopax, not minor changes like this.