diff options
| author | Christian Siefkes <hc@hcpad.(none)> | 2009-10-04 20:07:48 +0200 |
|---|---|---|
| committer | Christian Siefkes <hc@hcpad.(none)> | 2009-10-04 20:07:48 +0200 |
| commit | de42915bbbe637487258739271b6eb3c108a0999 (patch) | |
| tree | 87451a9a1364f613088c5679846c97647fdf5d6f | |
| parent | 8190f3aacc2e0894ae3f3a593514bc8122b778c1 (diff) | |
| download | tangiblebit-de42915bbbe637487258739271b6eb3c108a0999.tar.gz tangiblebit-de42915bbbe637487258739271b6eb3c108a0999.zip | |
Initial description of object system
| -rw-r--r-- | doc/objects.rst | 333 | ||||
| -rw-r--r-- | doc/tb.rst | 4 |
2 files changed, 337 insertions, 0 deletions
diff --git a/doc/objects.rst b/doc/objects.rst new file mode 100644 index 0000000..d2c2ce9 --- /dev/null +++ b/doc/objects.rst @@ -0,0 +1,333 @@ +Tangible Bit Object System +-------------------------- + +The Tangible Bit Object System (TBOS) describes physical objects. It +contains including detailed and automatically processable on how they can +be build, how they can be used, and what they can be used for. The TBOS +takes care of the entire life cycle of an object, including information on +maintenance, part replacement, and repair, and disassembly. + +Each object has *properties* that describe the object. Each object is +associated with *processes* that describe how the object can be build, +used, maintained, repaired, modified, or dismantled. + +Object Descriptions +~~~~~~~~~~~~~~~~~~~ + +The most important property of each object are its *types* (categories). +Type allows placing all objects in a type hierarchy. Each type is a +*subtype* of another type, the most general object type is *Object*; each +object is an instance of one or several types (we allow multiple +inheritance here). The hierarchy of object types, as known to Tangible Bit, +is stored in ``doc/object_categories.txt`` (TODO should be formalized and +moved outside the ``doc`` directory). The object type also specified which +other properties the object has. + +The properties of the *Object* type, which are shared by all objects, are +as follows: + +* *types:* non-empty list of types the object belongs to +* *name:* an informal name of the object +* *URI:* a URI uniquely identifying the object +* *summary:* a short (one line) description of what the object is and what + is can be used for +* *description:* a longer description +* *thumbnail:* a list of small visual depictions of the object (pointers to + image file) +* *authors:* list of the people which created/packaged the object +* *maintainers:* list of people to contact regarding questions about the + object +* *last-modified:* timestamp showing when the object metadata or the files + or processes connected with the object where last modified. +* *license:* the license under which the object is made available (must be + compatible with CC-SA-BY in order to allow inclusion in the TB object + database) +* *replaces:* list of object URIs this object is meant to replace/make + obsolete +* *files:* list of files associated with the object. Each file is described + by a tuple: + + * *role:* the role of the file in regard to the object, e.g. "depiction" + (audio/visual of the object, e.g. a photo, drawing, or movie), "faq", + "whitepaper". (Make this a closed list?) Note: files such as "manual" + shouldn't be stored here; rather, they should be associated with a *use + process* (cf. below). + * *name:* the name of the file + * *mimetype:* the MIME type (guessed from the file name if missing) + * *description:* a (preferably short) description of the file and its + purpose + + TODO must be possible to specify license information for files separately + (e.g. software will often be GPL'ed -- CC-BY-SA license *should not* be + used for software). On the other hand, allowing separate licenses for + each file would be a mess--maybe add an object property + *software-license* and use that license for all files containing source + code? + +* *processes:* list of processes associated with the object. + + * *role:* the role of the process in regard to the object, one of + + * build: how to build/produce the object + * setup: how to setup the object prior to using it (comes between build + and usage, and can optionally later be repeated when necessary.) + Sample: program channel list on a TV set. + * use: how to use the object, in general or for some specific purpose. + * dismantle: how to dismantle/disassemble the object + * maintain: how to maintain the object--describes operations that need + to be performed regularly or occasionally to keep the object in good + order. Sample: change oil in a car. + * repair: how to repair the object or some parts of it. + * replace: how to replace same part of the object. + + * *process:* the URI (?) of the process itself, cf. *Process + Descriptions* below + * *description:* a (preferably short) description of the process in + relation to the object + +Other properties that will apply to most objects are: + +- weight (kg): the weight of object +- width (m), depth (m), height (m): the outer size of the object, when + fitting it into a box + +TODO Probably these properties go into the Object type too, or should we +define a subtype MaterialObject for them? + +Samples of additional properties that could be defined for a VisualDisplay: + +- resolution-x (int) +- resolution-y (int) +- display width (m) +- display height (m) + +All properties that require a unit come with a "natural unit" taken, when +possible, from the `International System of Units +<http://en.wikipedia.org/wiki/International_System_of_Units>`_ (meter, +kilogram, second, ampere, degree Celsius, candela, joule, watt, volt, +hertz, ohm, lumen etc.). Thus units need never be stored in the DB. The +obvious exception is money, where a unit (e.g. USD or EUR) must be +supplied. + +TODO How do we define new object types and properties (including type or +unit) for them? Maybe use the YAML !template approach used by skdb, or +something similar? + +Process Descriptions +~~~~~~~~~~~~~~~~~~~~ + +Processes describe the life cycle of an object: how it and be built; how it +can be used and what it can be used for; how it can be maintained, +repaired, and modified; and how it can be dismantled and discarded or +recycled when it has reached the end of its life cycle. Without processes, +any object would be pretty useless. + +Each process description has the following elements: + +Metadata +++++++++ + +* *name:* an informal name and short summary of the process +* *URI:* a URI uniquely identifying the process. Tip: derive from the URI + of the corresponding object, TODO sample. +* *description:* a description of the process +* *authors:* list of the people which created/packaged the process + (typically same as for the corresponding object) +* *maintainers:* list of people to contact regarding questions about the + process (typically same as for the corresponding object) +* *last-modified:* timestamp showing when the process was last modified +* *license:* the license under which the process is made available + (typically same as for the corresponding object) +* *files:* list of files associated with the process (same format as above) + +Input ++++++ + +Lists materials and components that are required for the process; including +the amount or the number of instances required. Materials and objects +listed here are used up or transformed during the process. + +Input requirements are listed using `Booleano +<http://code.gustavonarea.net/booleano/>`_ or the TB query language (TODO +determine language to use), e.g.:: + + object ? (type ~ SheetMetal & material = Aluminum & width = 1.5 & + depth = 0.3 height = 0.003 & copies = 12) + & + material ? (type ~ ABS & mass = 0.5) + +(12 aluminum sheets, size 150x30 cm, height 3 mm; and 0.5 kg of ABS +plastic.) + +The input requirements are often called "bill of materials (BOM)", but they +can contain materials *and* objects. + +Tools ++++++ + +Lists tools and resources that are used in the process, but that aren't +used up. Tools are listed in the same way as inputs, e.g.:: + + object ? (type ~ WaterHeater & achievableHeat >= 100 & + heatableVolume >= 2) + +(A water heater than can heat 2 liters of water (or more) to 100 degree +Celsius (or more).) + +Constraints ++++++++++++ + +Lists conditions that must be true for the process to be performed as +expected. Described in the same way as inputs, e.g.:: + + constraint ? (10 <= EnvironmentTemperature <= 35) + +(The environmental temperature must be between 10 and 35 °C.) + +Implementation note: input, tools, and constraints can be stored as "saved +queries" in the database. + +Output +++++++ + +The output describes the objects that will be created as a result of the +process, if any. Output is specified in a simple declarative language, e.g. +YAML:: + + WaterBoiler: + achievableHeat: [60, 80, 90, 100] + heatableVolume: 0-3 + power: 700 + weight: 2.8 + width: 0.28 + depth: 0.2 + height: 0.29 + +(A water boiler that can heat up to 3 liters of water to 60, 80, 90, or 100 +°C, needs 700 W, weights 2.8 kg etc.) + +For processes that don't *create* any objects, but only repair, maintain, +or use them, no output will be defined. Processes that dismantle objects +should list the resulting remains or waste as output. + +Operations +++++++++++ + +This is the core of the process: the list of operations to be performed as +part of the process. Operations are partially ordered: some must be +performed sequentially, others can be performed simultaneously or in +arbitrary order. + +For each operation, there is an *agent* that should realize the +operation--either one of the *tools* required for the process (or, in some +cases, one of the *inputs* defined?), or a human. + +Operations will ofter refer to one *files* attached to the process: CNC +router should execute the toolpath defined in file X, human should bolt the +components together as shown in PDF file Y, etc. + +By default, operations are *sequential*, they must be executed in the +defined order; alternatively, groups of operations can be marked as +*parallel* which allows them to be executed in parallel or in arbitrary +order. Groups of operations can also be *alternative* (do this or do that); +they can also be *conditional* (if...then...else). Groups of operations can +be *repeated* (while... block) for a certain number of times or until a +certain condition is true. + +Here's an example of how the different kinds of grouping constructs could +look like, using a simple YAML syntax and placeholders instead of actual +operations:: + + - parallel: # execute these operations in any order + - Bla + - Bla + - Bla + + - sequential: # You can use this inside a parallel block. Otherwise you + # won't need it, as all other blocks are sequential by + # default. + - Bla + - Bla + - Bla + + - alternative: # select one of those processes + - Bla + - Bla + - Bla + + - if: *condition* + then: + - Bla + - Bla + - Bla + else: + - Blub + + - while: *condition* + do: + - Bla + - Bla + - Bla + + - for: i # repeat this 10 times (increasing the value of i) + from: 1 # optional, since that's the default + to: 10 + #step: 1 # default + do: + - Bla + - Bla + - Bla + + - for: file # do this for each of the 3 files + in: [fileA, fileB, fileC] + do: + - Bla + +TODO Describe how operations targeted at a human or at an object could be +defined; how to define *conditions* either for automatic evaluation or as +queries to a human. + +Parameters +++++++++++ + +It should be possible for process to accept *parameters* that influence the +process--for example, if you built a chair, you can configure the exact +length of the legs, specify whether it should have a cushion, select the +color etc. + +For each parameter, the supported range or enumeration of values should be +predefined; the user then chooses among the available options. + +The choice of parameter values can influence the other elements of the +process--exact input requirements and output specification will depend on +them; some of the operations will change to reflect to them; possibly, the +tools required will change too. + +When storing options in the DB, the whole range or enum should be stored in +order to be searchable (e.g. a chair that can be made in any color with +legs between 35 cm and 80 cm should match a search for a red chair with 50 +cm legs.) That's more difficult for input/tool requirements, however (we +can calculate and store how much material a 35 cm or a 80 cm chair would +need, but we can't precalculate and store such information for *all* +possible values). A possible, though imperfect solution would be to store +such information for the *minimum* and *maximum* values of numeric +parameters, and for a *default* value for enum parameters; and to calculate +the exact values on demand. + +Object Database +~~~~~~~~~~~~~~~ + +TODO Describe how objects and processes are stored in the DB. + +Tangible Bit Object Description +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The *Tangible Bit Object* file format (extension: *.tbob*) allows +extracting objects with their relevant processes from the database and +sharing them computers and users. + +TODO Design file format. Everything is packaged in a ZIP file, similar to +formats such as ODT and EPUB. + +TODO Ensure that it's OK to package GPL'ed software with non-GPL'ed content +in a single ZIP file (should be). @@ -147,6 +147,10 @@ Current database layout: Here we need input regarding the design, structure, and contents of the materials science database. +Object System +~~~~~~~~~~~~~ + +See ``objects.rst``. Industrial Capacity Mapping ~~~~~~~~~~~~~~~~~~~~~~~~~~~ |