Re: [Obi-devel] Comments on RuMetadataRefinedRefined

[Trish W. <wh...@pc...>]

>> Term information implemented through rdf elements in OBI: 
>> -identifier
>>> DS: Do we want to have IDs (an autoID plugin) also for properties ?
>> 
>> TW: That is a good point to bring up. My vote would be yes to have the 
>> properties follow the same naming as the classes, i.e. use the rdf:ID field 
>> to hold a semantically meaningless alphanumeric identifier while another 
>> field holds the human readable string for the name of the property. The 
>> same conversion trick can be done using the Protege configuration to 
>> display the human readable string name as with the classes.
>> 
>> A few reasons that this was not set-up from the beginning was that the code 
>> (AutoID plugin) we obtained was only set-up to handle this function for 
>> Classes and the main focus of development was the IS-A hierarchy so 
>> extending this code was not a priority at the time. It would be a nice 
>> addition for future development.
>> 
> O.K, if there is no technical problems with that, then let a programmer 
> modify the autoID plugin accordingly. In general I would like to remark that 
> we should try to model our ontology in a way most people and tools can handle 
> it. Ideally the ontology should be accessible through diverse standard tools 
> and not need any special add-ons or plugins. In general I think we should 
> keep it simple and use standard owl functionalities and try to avoid as many 
> special customized solutions as we can.
As a note, it was resolved at the developers call that its would be taken 
as an action item to modify the plugin to allow the automatic generation 
of identifiers for properties. No date was set as to when this is needed.

As for the comment on special add-ons or plugins, I believe it is the 
nature of Protege to be extended from the base functionality by the 
development of plugins generated by members of the user community. As long 
as the plugin is available for use by all then I don't see it as a 
problem. The feature to use this type of identifier is being built into 
Protege 4. Basically, I see the use of such an identifier as being ahead 
of the curve in helping software developers utilize the ontology. This is 
my 0.02 cents based on development/utilization of the MGED Ontology and 
discussions with the other developers of MO as to lessons learned etc.


>> -display_term
>> TW - I'm not clear as to what is written for this term. Is it saying that 
>> there should be another property called display_term or that the value of 
>> the rdfs:label is to be used for display of the term name and that this 
>> value will be the same as used for the preferred_term? Based on the section 
>> that it is in I assume that it is the latter, but wanted to check.
>> 
>> 
> I think that there could be further distinctions:
> *ID* (currently as rdf:ID/rdf:about)
> *preferred_name* (the term name most intuitive to the domain expert and with 
> the highest intradomain usage frequency, currently as rdfs:label)
> *display_name* (a very short name for display in large graphs (just to 
> visualize the nodes more clearly...)
> *formal_name* (a term name that adheres to defined syntactic and semantic 
> construction rules. The preferred term name can't be normalised in this way 
> without corrupting its definition. A syntactically and semantically unified 
> name could help to spot bugs in the hierarchy.
>
> To be not too contradictory to my own 'simplicity statement' above, I would 
> recommend that each term MUST  have (Mandatory) an ID and preferred_name and 
> COULD have (Optional)  a formal_name.
> **
There seems to be a bit of confusion on the information above. Did all of 
the above proposed annotation properties make the short list of what is 
critical to proceed with OBI development, e.g. display_term? In revewing 
the various diffs of the wiki page 
(https://www.cbil.upenn.edu/obiwiki/index.php/RuMetadataRefinedRefined) 
it seems as though display_term was added as a specific term (with a 
different definition than above) and then later removed so the history of 
this term is not clear (in the current version).

My recollection was that OBI would use a property called preferred_term 
(or something named very similar) and that the value of this would be the 
same as the value of the rdfs:label and that these would be the terms 
that OBI as a group agrees to name the node in the graph and that it 
would follow some best practice naming conventions as set by the OBO 
Foundry.

Can someone provide a reference to the date of the developers call that 
the use of the property formal_term was discussed? Thanks in advance.


>> Term information implemented as owl annotation properties in OBI
>> 
>> -preferred_term
>> TW - Is this the property that was proposed because the rdfs:label field 
>> does not have any semantic meaning, but is often used to display the term 
>> name, modified using existing methods of the Protege API, etc.?
>> 
> Yes, this is the term name currently in rdfs:label. We currently choose to 
> display the classes by this 'Display or Browser key' (tool functionality).
Ok, so that is confirmed. It would probably be useful to state that the 
value for this property is the same as the value for the rdfs:label and 
why that is being done, i.e. the question above.


>> -definition
>> 
>>> DS: Maybe definition_source is more intuitive to the majority of obo users 
>>> then ? How do we exactly capture this? Will it have a complex value 
>>> itself, containing source sescription and description_id?
>>> 
>> 
>> TW - Is the above comment in reference to the proposed property 
>> 'definition' or to the use of 'attribution' as part of the complex value 
>> for this property?
>> 
> It refers to 'attribution' and I think we should call this 
> 'definition_source' because it is more intuitive. 'attribution' is close to 
> 'attribute' which is a synonym for 'property' in some KR domains.
To follow-up, I believe that it was decided at the developers call that 
this would be changed from attribution to definition_source.


>> -curation_status
>> 
>>> DS: Should "value graph position temporary" be as well discussed in the 
>>> deprecation policy list? Does it refer to an alternative_class_parent? 
>>> When curation_status is used for object properties then it applies only 
>>> when we use property hierarchies...
>>> 
>> 
>> TW - My understanding for the possible value of the property 
>> curation_status of "graph position temporary" is that it means that the 
>> position of term in the hierarchy has not been discussed or agreed to and 
>> therefore the term may not be in the proper location in the hierarchy, but 
>> is not related to the term being deprecated. Just my impression based on 
>> the other values for this property.
>> 
>> ***Bill, can you clarify the meaning of this value?

This was answered in a separate email as copied below:
graph_position_temporary :== indicates the class may not be in its
final preferred location within the ontology graph. This label can be
particularly useful during early ontology creation, as for certain
entities, it may not be obvious where precisely a given class should
reside until a sufficiently large portion of the graph has been
settled;


Cheers,
Trish