#summary Working session at ICBO 2012

A working session on IAO is organized on Saturday July 21st, 6-8pm during the ICBO conference.

This event is targeted at members of the IAO developers group. While everybody will be welcome to attend, there won’t be any general presentation of the IAO, and attendees are expected to be very familiar with the IAO. Agenda will be limited to those items that have been approved for discussion by the community of developers. If you are planning to attend, please help us plan by adding your name to the attendee list below. Add any topic you want to see discussed to the agenda, specifying your name as proposer (e.g. "topic X, proposed by Y)

See announcement here

• ICE and parts: In a CTSA meeting regarding ontologies the question was brought up whether an instance of a plan specification that has_part an instance of an objectives specification, once the objective specification changes this PS stays the same. Analogy to ICs suggest it does, but participants expressed interest in further discussion (proposed by Mathias).

• IAO Top Nodes Working Group: I want to propose and discuss starting a small group of IAO developers who are interested and have time at their hands to work on optimizing the upper level of IAO (not BFO, of course, but the classes immediately below 'information content entity') and come up with a consistent hierarchy and consistent definitions. In the past we had worked on single examples of inconsistency (e.g. data item and measurement datum), but I feel it would be beneficial to look at the big picture and get things in line. My proposal is that the working group works on providing a proposal at ICBO 2013 to the IAO community. Meanwhile there will be progress reports on the mailing list to enable discussion. (Proposed by Mathias)

• IAO Releases: Can the working group assemble volunteers for making this more regular and getting a newer version into Bioportal (current verison is THREE years old)? Do we want to upload release version of IAO made for each OBI release to Bioportal or only major release? Do we need to vote for switching to BFO 2.0? (Notes by Jie: IAO has a release version with each OBI release until the end of last year which are not uploaded to Bioportal.)

• iao:data item: Lately, members of the OBI developer list have intensively discussed iao:data_item and issues related to the definition and representation of data items as outputs of measurements, predictions and as part of plan specifications (like device settings). To provide a consistent representation of data items used in and obtained from biomedical investigations in OBI these issues need to be resolved (proposed by Christian). Starting by the problematic notion of data items as "true" ICEs (1) several problems were exposed on the OBI list, specifically it was discussed that:

  • the textual definition of iao:data item may need to be revised: data items aren't statements, they are part of statements and as such they are neither true nor false (whereas the statements which they can be part of are) (2)
  • data items can be the result of measurements or predictions or part of plan specifications. In the case of predictions it is not so clear what they are about and also the "aboutness" appears to be different from how a measurement datum is about a (real) thing being measured. In plan specification they play yet a different role. To resolve this creating a class 'value specification' or 'value denotation' has been suggested (3,4) or, alternatively, to create different subclasses of iao:is_about to convey different types of aboutness (5,6) (Notes by Jie: Data item can be used as software setting specification, input parameter, which is part of a plan specification. However, not all setting specification are data item. Would like to cover software setting specification in the discussion if possible.)
  • suggestions have been made for corresponding textual/logical definitions or superclass expressions (5,6)
  • there is an inconsistency between the 'measurement unit label' definition and its subclass as a consequence of mireoting UO classes (7)

(based on notes taken by André Q. Andrade and on a video provided by Mustafa Jarrar)

• ICE and parts: In a Clinical and Translational Science Ontology Workshop in Baltimore in April (http://www.bioontology.org/wiki/index.php/Clinical_and_Translational_Science_Ontology_Workshop) the question was raised whether ICEs, more specifically "plan specification", stay identical if one of its part, for instance "objective specification" or "action specification" changes. It was pointed out by Sivaram that this is basically a problem of individuals, not so much of classes. However, Chris pointed out that it seems to touch on issues of class membership for individuals, too. It seems that for most cases the change of a part of a plan specification changes the plan specification as such. This can result in the individual plan specification being member in a different class than initially. Barry pointed ou that the best strategy to ensure that this holds, is to actively look for counterexamples.

• IAO Releases: The topic arises from the situation that multiple IAO version exist at that time, due to the existence of two different versions of BFO (bfo1.1 and bfo_ruttenberg). OBI imported the later BFO version whereas the major release of IAO still uses bfo1.1. From these issues a number of questions arise:

1. Should the IAO release process be in sync with the OBI release process? How often should there be a release?
2. How can we ensure that the version pointed to by the PURL or provided to BioPortal is the newest release version?
3. Should we provided release notes to each release? How could that be organized?

ad 1: Melanie proposes that whenever changes that are critical for OBI occur in IAO there needs to be an IAO release. She points out the qualities of the OBI release process and states that for the time being she'd be happy if IAO releases happened in sync with OBI releases. Regarding issues related to minor vs. major releases (updating of PURL/BioPortal) it seems that there are not (and should not be) a differentiation between major and minor releases. There are dated release versions, which are stable, and there is the development version, which is not. Melanie pointed out earlier in the discussion that dated releases enable users of IAO to stick with a previous released version.

ad 2: Melanie points out that Alan is the one with the BioPortal keys and that he is aware of the situation and working on it. James already asked to be added as an administrator to the IAO account with BioPortal and we are looking for more people to volunteer. With respect to the PURL there, too, exist a group of people administrating the IAO PURL. Melanie offers to add Jie immediately to that group to allow her to update the target link of the PURL. Jie brings up the question of whether those resources ought only to be updated to the last major release version or, rather, to all releases, including minor ones.

Melanie update August 2nd 2012: The iao-admin user now has admin rights on BioPortal. Password will be shared upon request to Alan.

ad 3: As far as release notes are concerned we recognize that all development on IAO is done by people on their own time, so editing extensive notes might be to much to ask. However, we agreed on the necessity of better documentation of changes in IAO. Mathias and Chris point out that one step towards providing release notes might be to invest more time in the change log by reporting a) the changes and b) the rationale or reasoning behind the changes. Sivaram points out that is a basic software development policy and that this is not only important for users, but for the developer's themselves. Despite the fact that we all agree that it is hard at times to write really helpful log messages, there seems to be agreement that we'd advertise better documentation and will try to engage in better documentation ourselves. As far as release notes are concerned Melanie proposes to provide a t least a paragraph of release notes for all major releases of IAO. The release notes can be derived from the log messages.

• IAO Top Nodes Working Group: Mathias proposed a joined effort to clean up the upper nodes of IAO, bot with respect to hierarchy and with respect to textual and formal definitions. It seems that there are multiple (conflicting?) partitions represented in IAO without clear documentation. Part of the problem seems to be that people tend to use ICE in an unintended way. Barry points out that ICEs are meant to be persistent and therefore are restricted to information content recorded in an artifact. Shifting from ICE to either "information" or "information content" is, according to Barry, not helpful, since those are mass terms. Mass terms are notorious for creating confusion in ontological representation. The problem of the top nodes of IAO can, according to Barry, not be tackled without the ontology of mental representation. The proposal to get together a group of people to clean up IAO at that point does not find supporters.

• iao:data item: The problem, which has been discussed for quite a while, is that currently IAO states that a data item is intended to be a truthful statement. This creates two main problems: a) the claim of truth b) the claim that a data item is a statement. As far as a) is concerned there seems some people in the group agree that the fact that the definition states that a data item "is intended to be a true statement" takes care of this. However, some issue remain, especially for measurement datum, since sometimes they employ assumption and estimates. Therefore, the claim of truthfulness still seems to be dubious. One possible solution would be create a new class for measurements process variables. The proposers of the section started out from the assumption that "10mg" should be a measurement datum, however, before the meeting they already proposed a new class called "Value specification". Each measurement datum would then have a value specification as part. Regardless of the very enlightening discussion there was no agreement achieved during the working session. However, the meeting spawned multiple discussion during the following days which are reported below (Post-Working-Session Communications)

(in alphabetical order) If you want to attend dinner please mention so next to your name. Note that this is not a funded event; you will be asked to pay for your own food/drinks. Stefan very kindly booked the restaurant for us: Welscher Stub'n, Schmiedgasse 5-7, Graz 8010, Austria See the restaurant website and some reviews

• Mauricio Almeida
• André Q. Andrade.
• Christian Bölling (dinner)
• Mathias Brochhausen (dinner)
• Melanie Courtot (dinner)
• Randall Dipert
• Gwen Frishkoff
• Oliver He (dinner)
• Lawrence Hunter (regrets -- plane arrives too late)
• Alan Ruttenberg (dinner)
• Barry Smith
• Chris Stoeckert (dinner)
• Jie Zheng (dinner)
• Catalina Martínez Costa

(Provided by Christian Boelling)

The workshop and post-workshop communications were helpful in making clearer the different perspectives on the issue and separating terminological, ontological and application-oriented (i.e. representation in RDF/OWL, ease of use for representation & query) parts of the discussion.

AR = Alan Ruttenberg CS = Chris Stoeckert CB = Christian Bölling

Running example: Mouse#1 has a mass of 10 gram. This mass was determined in a particular measurement process (measurement#1) using a particular scale (scale#1).

AR and CS clarified that the term "data item" was intended to denote the concept of an information content entity that, as a hallmark, provides true information about something and that this motivated the current textual definition for data item. CS emphasized that the difference between a data item and a value specification is aboutness: data items are entities that are about something (e.g. a quality of an object) while value specifications are not.

From this perspective, the 'data item' in the running example is more than just the '10 g'. As summarized by AR (see figure) the data item in the running example could be characterized as the entity that is related to the particular weight quality via the is_quality_measurement_of property and to the particular measurement process via the is_specified_output_of property and has parts '10' and 'g'.

AR and CB agree that the entities which can be true or false are statements. The relevant statement that can be formed in this example is, according to AR: is_quality_measurement_of <mouse#1>. AR agrees with CB that in this view, data items are part of statements and that the current textual definition for data item should be revised. AR suggests to change the beginning of the textual definition to "A data item is an information content entity that can be used to form truthful statements…"

CB's concept of 'data item' corresponds by and large to the '10 gram' and is therefore close, if not identical to the suggested concept of 'value specification' (which makes up the terminological part of the discussion) Because of this, he has argued that data items aren't statements and are neither true nor false and that the current textual definiton should be revised accordingly, dropping also any reference to truthfulness, claims of which can, as he argues, in any way only be judged by evaluating information of how the measurement or prediction result was generated.

Equating CB's notion of 'data item' with the notion of the proposed 'value specification' makes some of the discussion points obsolete . However, CB argues that in his experience entities such as '10 g' are routinely referred to by wet-lab biologists and modellers as 'data' and that therefore 'data item' or 'datum' is a better term than 'value specification' for these entities.

Other points from the data item agenda have only briefly been touched, in particular whether it is necessary or desirable to refernce plan specifications and/or the (hypothetical) measurements specified in them to be able to point to the things that predictions are about. AR concedes that model-based estimations about past events or objects present problems as exposed by CB's examples. AR and CB agree that this needs to be discussed further.