Pubwan virtual object

Pubwan virtual objects (PVO's) are abstract representations of actual objects identified and described by pubwan volunteers. The represented objects would in most cases be items identified by volunteers as available for sale to the public. Base classes of such objects would be identified in a pubwan database in such a way that objects would be considered of the same class to the extent that they are &quot;indistinguishable,&quot; in an &quot;economic&quot; sense. For many mass-produced consumer goods, the UPC (Universal Product Code) would be sufficiently one-to-one with these &quot;classes.&quot; For some other manufactured goods, &quot;make&quot; and &quot;model&quot; might comprise a workable &quot;key.&quot; Some &quot;one-of-a-kind&quot; items would of course be in a class by themselves. We shall refer to these &quot;base classes&quot; as PVO's of the &quot;simple&quot; type (SPVO's.)

These base classes would have parent classes described in terms of the familiar &quot;is a&quot; relation. These parent classes would represent more generic characterizations of represented objects. For example,


 * &quot;pitted black olive&quot; is a &quot;pitted olive&quot;
 * &quot;pitted black olive&quot; is a &quot;black olive&quot;
 * &quot;black olive&quot; is a &quot;olive&quot;
 * &quot;olive&quot; is a &quot;vegetable&quot;

Note the systematic way of handling noun phrases with multiple modifiers. It should be possible to abstract on this in the modeling of data structures for the pubwan category tree. It should also be possible to automate partially the parsing of class designations in pubwan taxonomy. The most specific (least generic) designations will often contain trade names. Pubwan volunteers must be careful always to label these as such, perhaps with a &reg; symbol in the descriptor string. The generic classes, like their subclasses, will for the purpose of this discussion also be called &quot;simple.&quot;

A pubwan database should also provide a way to represent &quot;compound&quot; virtual objects (CPVO's.) Minimally, the specification of a compound class of PVO's would be a list of simple PVO classes. Also, in many cases quantities of each item would need to be specified, as in a bill of materials. In the case of foodstuffs, such a bill of materials might be termed a &quot;recipe.&quot; In another context, perhaps a &quot;project.&quot; Such compound PVO's could be seen as representing &quot;processes.&quot; Certain specific simple PVO's relevant to a process can be identified as &quot;inputs&quot; or &quot;outputs.&quot; The other SPVO's might be akin to &quot;capital assets.&quot;

The identification of inputs and outputs among SPVO's serves an important informational purpose, related to &quot;data visualization.&quot; CPVO's can be represented as mathematical objects called &quot;graphs,&quot; which pictorially are &quot;stick figures&quot; or &quot;connect-the-dots&quot; diagrams. The simplest type of &quot;process CPVO&quot; can be represented as a &quot;star graph,&quot; which is essentially a connect-the-dots picture of an asterisk. The central &quot;vertex&quot; of this star represents the CPVO itself, with its satellite vertices representing the component SPVO's. When subjected to &quot;graph embedding&quot; techniques, there should be a tendency for product classes to act as &quot;adhesion&quot; points to processes that logically should have spatial proximity...one example would be cases in which one's outputs are another's inputs.

CPVO's can represent many things other than virtual processes.


 * virtual collections
 * virtual werehouses
 * virtual cities
 * virtual pantries
 * virtual libraries
 * virtual &quot;component systems,&quot; and collections thereof
 * virtual supermarkets

The graph embedding (or &quot;proximity modeling&quot;) for these types of CPVO's can involve other ways of representing information.