|
From: frank g. <Fra...@nc...> - 2007-02-26 17:41:39
|
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 |