I agree with Doug on almost all points below. (I should, since I said
many of the same things.) (01)
doug foxvog wrote: (02)
> Naming considerations should depend on the practicality and utility of
> unique identification. The batch of received test tubes should have a
> unique identifier so that the provinence of each tube can be determined,
> for example if there were a fault in a production batch. Having an
> identifier for the batch allows statements to be made as to the properties
> of the individual tubes within the batch (dimensions, material, rating,
> manufacturer, ...).
>
> Given that the individual tubes are identical (for all practical purposes)
> without identifying labels, the assignment of different names to the
> unidentifyable tubes upon receipt would be counterproductive.
> (03)
Agree. (04)
> The utility of assigning identifiers to the lots being sent to each robot
> depends on context. If useful, the identifiers could be defined when the
> decision is made to create the lots (either before or after receipt of the
> shipment), but the identifiers could not be assigned to a physical lot
> until that lot is (at least logically) separated from the other test tubes
> in the shipment.
> (05)
Also agree. Note that "create the (sub)lots", which creates only
information objects, implies creation of identifiers for them. The
relationship between creating the KB object and its physical counterpart
as a group of test tubes is a separate concern. John specified that the
handling was done by robotic equipment, which would necessarily create
some formal information objects to manage the _movement_ of the test
tubes, because they have different destinations. (06)
> Until a test tube is removed from the lot received by a robot, there seems
> to be no utility in assigning it an identifier. (07)
I agree with this, with the caveat that we are talking about common
laboratory practice. (YRMV) (08)
> However, once a test tube
> is selected for use, the assignment of an identifier could be useful. But
> depending upon the situation, it might be more reasonable to identify the
> "package" (test tube plus contents) or merely the contents instead of the
> specific test tube. An identifier for each individual test tube could be
> created, but not assigned when the lot is transfered to the receiving
> robot, or at any time thereafter.
> (09)
I thnik Doug is right here, with a slight revision. When a test tube is
used, it acquires identity according to its use. Functional behavior,
content, content-to-be are all properties that may associate with the
test tube in use. Whether the test tube is considered to be a distinct
object from its content, or its instantiated role, is a design choice.
If you take 4 vials of blood from the same individual at the same time,
do you have 4 vials associated with a single "J.Doe's blood at datetime"
content object, or 4 objects that are "vials of J.Doe's blood at
date/time" numbered 1/4, 2/4, etc.? That is a matter of practice, and
that practice differs among labs. When you take part of the content of
one of these vials and put it into a new tube for some test, you need to
maintain the trace, and you can do that by linking or copying. The
knowledge bases are "information bases" and the schemas (ontological
invariants) are designed to support the software that supports the
functions. It is all about laboratory practice and software design. (010)
> As far as the knowledge base is concerned, the only naming concern for the
> individual test tubes is that they be unique. Statements in the knowledge
> base would relate the individual tube to the batch it came from, its
> physical properties, and any label attached to it. Considerations for
> the text on a physical label might suggest that features of a written
> identifier may allow a viewer to infer some of these features. Viewers of
> the knowledge base should be able to see and access information about an
> individual test tube using the text on the label.
> (011)
The knowledge base may also record its physical location, and the viewer
may be able to retrieve information based on that. In practice, the
choice of 'definite description' of the test tube you mean, and its
relationship to 'identifier', is another issue of practice. Doug is
right that thinking of the 'identifier' as a specific canonical
attribute of the test tube may not match laboratory practice: some
users may refer to them by what is on their labels, and other may refer
to them by their position or role. (012)
> As Matthew suggests, if an unused test tube breaks, there is no need to
> identify it; all that is needed (other than picking up the shards) is that
> the number of available tubes be decremented.
>
> If a test tube in use breaks or spills, it often would be more useful to
> identify the specific contents which spilled rather than the container.
>
> If a used test tube is to be reused, it may be useful to identify it
> before cleaning, so that the type of contents might be identified.
> Similarly, if issues on disposal of used test tubes depend on the type
> of former contents. If all the test tubes in the facility use the same
> type of contents, this may not be an issue.
> (013)
Being careful here, the test tube may lose individual identity and
become one "count" of the collection of tubes that are in the same state
-- having been used in a certain way. It is obviously simpler if the
laboratory has only one such category, but the same applies when the
laboratory has 3 categories or 8. It is about how many different
cleaning or disposal processes there are, based on previous use and content. (014)
> If there might be an issue related to incomplete cleaning, there might be
> a reason to maintain the identity of a test tube post-cleaning. This
> would bring up issues of maintaining information about each usage of
> a test tube. One way to do this would be to link the identifier to
> the test tube as involved in a particular use. A subsequent use of a
> test tube would have a new identifier, but be related via a property to
> its previous use.
> (015)
Well, now we are talking about associating a 'history' with the
individual test tube. If you are going to do that, you probably assign
it an identifier and put a label on it when it comes out of the shipment
package. I don't know of labs that do this, but (as I said) this kind
of thing does happen to things like test tubes that are used in
sensitive manufacturing processes, e.g., in semiconductor manufacture,
food processing, or pharmaceuticals. (016)
> If the identity of a test tube is not maintained after cleaning, the test
> tube could re-join the lot of unidentified test tubes and a new identifier
> could be assigned to it the next time it is selected for use.
> (017)
Exactly. It loses identity until it acquires a new use and a
corresponding identity. (018)
-Ed (019)
> -- doug foxvog
> (020)
--
Edward J. Barkmeyer Email: edbark@xxxxxxxx
National Institute of Standards & Technology
Manufacturing Systems Integration Division
100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528
Gaithersburg, MD 20899-8263 FAX: +1 301-975-4694 (021)
"The opinions expressed above do not reflect consensus of NIST,
and have not been reviewed by any Government authority." (022)
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/
To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx (023)
|