specified ... relations

[obi-bot]

- The relations still refer to 'input role / output role'. That should have been removed according to the workshop to deal with data not having roles. - The has_specified participant relation is missing. That was decided to add at the workshop to deal with those participants which are used somewhere in the protocol (e.g. a reagent or instrument).

Reported by: bpeters42

Original Ticket: obi/obi-terms/163

[obi-bot]

• assigned_to: lsoldatova --> bjoernpeters

Original comment by: bpeters42

[obi-bot]

- I committed updated the definitions that do not have references to roles. - I also added the 'has_specified_participant relations'. Those seem to impact reasoning performance negatively, but I don't know what to do about that. Propose to close after discussion in next call.

Original comment by: bpeters42

[obi-bot]

Alan wrote: > updated the textual definitions of 'has_specified_input' + output + reverse to remove the use of roles (as discussed at the workshop. Also: Added again the 'has_specified participant relation (also discussed at the workshop). The latter seems to have negative impact on reasoning performance.

Yes, that's why I removed it, as I mentioned in the email when I said I took it out. Do we have anything remaining from the meeting other than the decision? Like the justification?

Working on performance distracts from getting the release out, so I would like it if we could take this out until then, or justify why it should be in (not that we made a decision, but why the decision was made and verify it's still a good one)

Original comment by: bpeters42

[obi-bot]

In brief: The has_specified participant relation was supposed to apply to reagents, instruments, employees, local variables in a software function call etc. that are specified in a plan, but are not inputs or outputs.

In the message when you took it out, you only stated that it was not used, which was no surprise as it was just added.

I am okay with removing it for now, but then we need to work on an alternative modeling decision for the above. Currently I believe the 'has_specified_input' relation is overused. It is not meant to apply to everything that 'can' be present at the onset, but only those things that absolutely have to. Also, there is an implicit 'output derived from input' relation which we wanted to add at some point.

My suggestion would be to use the design pattern 'planned process' realizes some (function/role inheres in participant)' for material entities. We are stuck again for data with this.

Original comment by: bpeters42

[obi-bot]

proposal - Here is a proposal from Alan + me how to deal with instruments / reagents / other entities that are specified to participate in a planned process in order to realize a certain role or function:

Proposal is to use two restrictions: planned process has_specified_input some instrument X planned process realizes some function Y and inheres in instrument X

This means 1) we always use has specified input, there will be no has specified participant relation. 2) the definition of the has specified input relation needs to remove reference to things being present at the start of the process 3) The realizes definition in RO needs to be extended to roles etc. (already emailed RO about this) 4) We need to review all uses of has_specified_input only XYZ, as they are likely invalid with this broad use of the relation

has been actioned but the following still need attention re point 4 above

clustered data visualization

data visualisation

data transformation

gene list visualisation

material processing.

Original comment by: helenp

[obi-bot]

Here is my proposed section for the manuscript that addresses the discussion so far:

While processes can have many participants, objective and plan specifications typically explicitly identify participants that are particularly important. OBI defines two relations, has specified input and has specified output, relating process instances to such participants. Other than that these participants are mentioned in plan specifications, we can infer that specified outputs must necessarily be present at the end of the planned process in which they participate in order to achieve its objective specification. Specified inputs are participants identified in the plan specification such as specimens, reagents, devices or workers as they exist when they start participating in the planned process, and which are not created during the process.

Original comment by: bpeters42

[obi-bot]

Summary of discussion - there are two child classes of

/has_participant/ / has_specified_output/ - I believe this is not contentious and we accept the label, definition and usage

/has_specified_input/

This is contentious, the inital definition (now removed from the OBI file) included 'must be present at the start of the process'.

The current definition states that specified inputs can't be created during the process

FG thinks this and the fact that the input is stated in the plan are insufficient differentia between has_participant and has_specified input.

BP thinks that inputs existing before participating in the process - they can be specified in the plan and the fact that they can't be created in the process are sufficient differentia.

FG doesn't accept the example of e.g. a buffer is added at day 3, so it is not a specified input as this should be modelled as a sub process with its own specified input of the buffer.

FG preferred the requirement for specified input to be present at the start but has now looked at the most recent file and is Ok with these

The counter argument (HP) is we don't need to be that granular - high level modelling is sufficient for the majority of use cases.

Resolution:

BP's suggestion documented in the tracker is accepted and implemented in the OBI file. BP and FG are OK with this.

Original comment by: helenp

[obi-bot]

closing as resolved as summarized by Helen.

Original comment by: bpeters42

[obi-bot]

• status: open --> closed

Original comment by: bpeters42

[obi-bot]

Sorry: re-opened because we still need to update textual definitions of inverse relations.

Original comment by: bpeters42

[obi-bot]

• status: closed --> open

Original comment by: bpeters42

[obi-bot]

inverses textual definitions are now updated to be in sync.

Original comment by: bpeters42

[obi-bot]

• status: open --> closed

Original comment by: bpeters42