[Obi-protocol-application-branch] Protocol vs ProtocolApplication

[frank g. <Fra...@nc...>]

Hi

I have been looking in the current OBI file and I have certain issues with
the current classes of Protocol and ProtocolApplication. I appreciate this
has been discussed at the recent meeting and maybe a justification of the
placement and existence of these two terms will help me understand the
placement better.

The terms of Protocol and ProtocolAplication appear to be a direct import
from FUGE, please correct me if this is not the case. As described in the
FUGE documentation  "It would be highly inefficient to redefine a complete
protocol for every single deviation that occurs. FuGE handles this by
separating the definition of a protocol from the object that annotates the
occurrence of a protocol".
This appears to reflect the definition of Protocol and ProtocolApplication
within OBI. The protocol class is defined as a Plan and ProtocolApplication
is a Process defined as "A protocol application is a process carried out to
bring about the effect defined in the protocol applied".
If I have interpreted these two terms correctly then I have several
concerns  as a result;
1. Every ProtocolApplication must have a corresponding Protocol, this will
be a hard thing to manage and may cause problems with the current proposed
branch management system.
2. The definition states that ProtocolApplication "is a process carried out
to bring about the effect defined in the protocol applied" again this
enforces point 1. Here concept of "effect" is introduced which implies that
the term Protocol defined as a Plan must have a stated "effect". This also
does not comply with the placement of Protocol as a Plan as a Plan does not
have an effect and is only a list of instructions and the same is true for a
Process, it is a representation of a sequence of events, not a reason why
those events happen, although it is perceivable that protocols can have
_roles_  or  _functions_ .
3. To quote the FUGE definition of ProtocolApplication, it contains the
specific parameters or specific inputs of a defined protocol. In an
ontology, specific deviations or in other words specific parameters or
instances of a protocol should be defined by individuals of the class and
not by a separate class, let alone a separate branch. It is possible to add
restrictions to sub classes of a protocol which would specialise certain
parameters of a protocol, but as demonstrated in 4, you may not want to take
this approach to literally.
4. The current OBI structure enforces that the application of protocols are
required. Using this structure, for example;
the definition of a shaking_protocol as a subclass of Plan>Protocol requires
an input produces an output and has a duration.
Under ProtocolApplication you are required to define the application or
instance of the shaking_protocol. If Fred shakes a glass of water for 2 mins
this would look something like this (crude example).
shaking_protocol_application, has_input=water, produces_output=shaken water,
has_duration=1min,
If Tom wants to shake water for 3 mins this will require a new
ProtocolApplication class as;
shaking_protocol_application, has_input=water, produces_output=shaken water
had_duration=3min,

The current structure in OBI at present means you must list an infinite
number of shaking_protocols as classes instead of individuals with the
applied duration of 1min, 2 min, 3min...and on to infinity.

An example of how a protocol (as a process) would then be defined would be
(ignoring participants such as devices)
protocol
-has_input
-has_action
-has_parameter
-has_output

For the example above the parameter would have a relation to the class of
_duration_ and the individual of the shaking_protocol would be
shaking_protocol
-has_input=water
-has_action=shaking
-has_parameter some values from duration* = 1min.....
-has_output = shaken water

*Duration has a restriction on some values from time measurement unit and
quantitative value.

IMHO OBI should be trying to create an overall structure of a protocol which
is a Process and to allow users to define their specific parameters (or
applications) of the protocols as individuals.  Based on this and the
examples above it is my suggestion that the label ProtocolApplication should
be renamed with the label Protocol. The class Protocol as a child of Plan
should be removed.

Cheers
Frank