Object Memory Modeling
W3C Incubator Group Report 26 September 2011
- This version:
- http://www.w3.org/2005/Incubator/omm/XGR-omm-20111026/
- Latest version:
- http://www.w3.org/2005/Incubator/omm/XGR-omm/
- Editor:
- Alexander Kröner, DFKI (Chair)
- Authors:
- Jens Haupert, DFKI
- Marc Seißler, DFKI
- Bruno Kiesel, Siemens
- Barbara Schennerlein, SAP
- Sven Horn, SAP
- Daniel Schreiber, Technical University Darmstadt
- Ralph Barthel, UCL
Copyright © 2011 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
Abstract
This report summarizes the findings of the Object Memory Modeling Incubator Group. An XML-based object memory format is introduced, which allows for modeling of events or other information about individual physical artifacts, and which is designed to support data storage of those logs on so-called "smart labels" attached to the physical artifact. The group makes several recommendations concerning the future evolution of the object memory format at the W3C; these address connections to provenance modeling, the embedding of object memories in web pages, and potential benefits of an object memory API.
Status of This Document
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of Final Incubator Group Reports is available. See also the W3C technical reports index at http://www.w3.org/TR/.
This document was developed by the Object Memory Modeling Incubator Group. The report summarizes work conducted in the context of the group's charter. As expected and expressed in the incubator group's roadmap, the topic of object memory modeling could not be investigated in its entirety during the runtime of the group. Results achieved address in the very first place the object memory format. How the remaining issues could be addressed is discussed in Section 5. If you wish to make comments regarding this document, please send them to public-xg-omm@w3.org. All feedback is welcome.
Publication of this document by W3C as part of the W3C Incubator Activity indicates no endorsement of its content by W3C, nor that W3C has, is, or will be allocating any resources to the issues addressed by it. Participation in Incubator Groups and publication of Incubator Group Reports at the W3C site are benefits of W3C Membership.
Incubator Groups have as a goal to produce work that can be implemented on a Royalty Free basis, as defined in the W3C Patent Policy. Participants in this Incubator Group have made no statements about whether they will offer licenses according to the licensing requirements of the W3C Patent Policy for portions of this Incubator Group Report that are subsequently incorporated in a W3C Recommendation.
The mission of the Object Memory Modeling Incubator Group (OMM XG), part of the Incubator Activity, was as follows: To define an object memory format, which allows for modeling of events or other information about individual physical artifacts, ideally over their lifetime, and thus implements an object memory model (OMM).
The object memory format should be designed to support data storage on so-called "smart labels" attached to the physical artifact. Such labels range from barcodes, to RFID, to sensor nodes - miniaturized embedded systems capable of performing some processing, gathering sensory information and communicating with other nodes. The object memory format implemented on a "smart label" can provide an object memory, which may serve as a data collector for real world data concerning a physical artifact. Associating semantic definitions with the data stored using the object memory format, can help tie together the Semantic Web with the Internet of Things.
Today, heterogeneous standards are already in use to describe a physical artifact's individual characteristics in different application domains. The envisioned object memory format has to complement and embrace such standards dedicated to the description of physical items. In order to facilitate interoperability in scenarios comprising several application domains (e.g., business processes covering production and logistics) and open-loop scenarios (e.g., production lines with highly varying process steps), the object memory format should provide a standardized way to organize and access the selected data independent from the application domain. Furthermore, it should function as a technology-neutral layer for delivering content from physical artifacts to applications in business processes ranging from product lifecycle management to consumer support.
This report summarizes results achieved by the members of the OMM XG. It describes the conceptual role and scope of an object memory model, provides an exemplary mapping of this model to an XML-based object memory format, and illustrates the application of this format on the basis of selected use cases.
The vision of an object memory format was the outcome of discussions between members from industry and research active in several research projects. All of them employ information and communication technology in order extend the role and capabilities of a physical artifact in applications ranging from supply chain management over support for human interaction with products to applying artifacts for the engagement with personal and social memories. Despite this diversity, applications invented by the different projects share the idea of linking physical artifacts with a continuously growing store of digital information.
The OMM XG was driven by the assumption that it should be feasible to identify a common conceptual structure (called object memory model) for this information store. Then, a shared implementation of that model (called object memory format) could allow for using object memories across applications. This might not only leverage, for instance, the collection of data for object memories, but also enable novel applications beyond the individual goals of the contributing projects.
- The SemProM project
- Funded by the German Ministry of Education and Research, the project SemProM (Semantic Product Memory, see http://www.semprom.org/) employs smart labels in order to give products a digital memory and thus support intelligent applications along the product's lifecycle. By the use of integrated sensors, relations in the production process become transparent and supply chains as well as environmental influences retraceable. The producer gets supported and the consumer better informed about the product.
- The ADiWa project
- The ADiWa project (Alliance Digital Product Flow, see http://www.adiwa.net/), funded by the German Ministry of Education and Research, makes the huge potential of information from the Internet of Things accessible for business-relevant workflows that can be strategically planned and manipulated. For the data-level connection of objects from the real world, results from available solutions and from the SemProM project shall be used. ADiWa focuses on business processes, which can be controlled and manipulated based on evaluated information from the real world.
- The Aletheia project
- The Aletheia project (see see http://www.aletheia-projekt.de/) is a leading innovation project, sponsored by the German Ministry of Education and Research that aims at obtaining comprehensive access to product information through the use of semantic technologies. The project follows an approach which does not only consult structured data from company-owned information sources, such as product databases, to respond to inquiries, it also looks at unstructured data from office documents and web 2.0 sources, such as wikis, blogs, and web forums, as well as sensor and RFID data.
- The SmartProducts project
- The SmartProducts project (see http://www.smartproducts-project.eu/), funded by the European Union in the 7th Research Framework Programme (FP7), develops the scientific and technological basis for building "smart products" with embedded proactive knowledge. Smart products help customers, designers and workers to deal with the ever increasing complexity and variety of modern products. Such smart products leverage proactive knowledge to communicate and co-operate with humans, other products and the environment. The project thereby also focuses on small devices with limited storage capabilities and thus also requires efficient storage mechanisms. Moreover, the project aims to apply the results achieved by the incubator group for optimizing the data exchange between different smart products.
- Tales of Things
- Tales of Things and electronic Memory (TOTeM, see http://www.youtotem.com/) is a three-year collaborative project between five universities in the United Kingdom. A project aim is to explore the implications of Internet of Things technologies for the design of novel forms of augmented memory systems. While the potential implications of the Internet of Things for supply chain management and energy consumption have been acknowledged and discussed, its application for the engagement with personal and social memories has been rarely mentioned. More and more newly manufactured objects are often tagged at production and made traceable. However, we typically do not think of old(er) objects as part of these networked structures. Tales of Things provides a design space for exploring the value a user-generated Internet of Old Things in which people's memories are linked to objects. In TOTeM tagging technologies such as Quick Response Codes and RFID are employed to provide links between objects and a centralized database of stories about these objects. The Tales of Things service makes these tags read and writable so that events and memories can be captured and replayed to reveal the significance of the tagged object. TOTeM is funded through a £1.39 million research grant from the Digital Economy Research Councils UK.
The incubator group was in permanent contact with these projects. They supported the group in the definition of OMM use cases, and provided input from practical experiments with preliminary results generated by the incubator group. Furthermore, the projects supported the incubator group with complementary activities such as market research concerning business models that could drive the transfer of a potential standard into practice. In addition, OMM concept, requirements, and use cases were discussed at the International Workshop on Digital Object Memories [DOMe] with other research groups.
General requirements for the object memory format include:
- Independence from the application domain;
- Independence from technical constraints imposed by smart label technology;
- Openness, flexibility, modularity and scalability
An object memory format addresses the organization, the description and the transformation of object-related information. Hence, the use of the following three components is playing a prominent role:
- A structure model defines the structural characteristics of an object memory. It should provide a flexible and extensible approach, such that any potential owner of the object will be able to enrich the representation with additional information in arbitrary formats. This model should explicitly support the temporal and incremental aspects of information accumulation along the object's lifecycle and allow for describing the state of the object at different points in time. In addition, it should allow for describing active components, such as sensors, employed by the object to acquire information from its environment. Furthermore, this model should be designed in a way which facilitates its adoption on technically limited information storage devices such as RFID chips. Further, it should enable an efficient information exchange between objects.
- A set of well-defined metadata enables a superficial characterization of a physical object without need to access additional information sources. This metadata (keywords) should be used by any kind of object memory in order to facilitate information exchange in scenarios with several parties interacting with the object.
- A conversion format should provide a defined but flexible way to transfer the object memory format to a representation matching the technical constraints of various types of labels ranging from RFID tags to sensor nodes. It should allow for defining mappings between an XML-based representation of the object memory format and arbitrary binary formats with potentially strong technical
limitations.
The object memory format should further provide mechanisms to support: data access; interpretation of data; and data integrity for distributed information linked with an object.
In order to explore this topic, the following sequence of work was planned:
- Analysis of requirements for data storage and processing on the physical
item and externally in the environment. Notes: This includes processing object
memories on the physical item's smart label.
- Definition of a structural description for object memories, which allows
for defining content blocks and histories of events for an individual
object. Notes: There are no agreed
formal definitions for the structure of object memories at present.
Creating agreed formal definitions will be a task of the incubator group.
Furthermore, constraints imposed by physical aspects of smart label
technology should be taken into account in order to enable a transfer of
these structures from web-based scenarios to smart labels.
- Definition of structures that facilitate access to and description of
content stored in object memories, such as keywords and index structures.
Here, a particular objective is to define these structures in a way that
permits quick direct access to data even after a transfer (and potential
conversion) of such structures to arbitrary smart labels. Notes: An important requirement is to
record product decomposition in an "open world", i.e., these structures
should be ready for extensions.
- Definition of a description, which allows for the specification of
associated remote data sources such as object-related sensors - sources
which may feed the object memory with content. Notes: Following the related concept of
smart labels, a particular focus will be on the description and treatment
of information sources actually attached to the physical artifact.
- Definition of structures supporting the conversion from XML-based
representations to other, more compact (e.g. binary) formats appropriate
for different kinds of smart label technology. Notes: This particular step will require
a formal description of the mapping process; the approach should be open
and thus allow content providers to define their own mapping schemes for
their respective contents.
Matching initial expectations issued in its charter, the incubator group's efforts focused on items (1), (2) and (3) during its one year runtime. The group started to investigate items (4) and (5); a corresponding proposal of how to deal with these topics - also as part of future work - is included in this document. During the runtime, the group aligned its activities according to the success criteria of defining a (re)usable structure, which
- Describes a physical artifact's individual characteristics and
technical capabilities.
- Enables the representation and organization of individual event histories
(and thus the evolution of properties of a single artifact).
- Supports retrieval and access of changing owners and users along the
product lifecycle.
- Is ready for translation according to (memory) constraints imposed by
smart label technology.
For a discussion of these criteria with respect to the proposed object memory format, please see Section 3.
The OMM XG sought to introduce new structures only if needed for the particular purpose of object memory modeling. Consequently, the following activities are considered related, but out of scope for the purpose of this group. Their respective results were embraced where possible in order to ease the deployment of new elements created as part of the object memory model.
- Modeling of product or object properties
- The OMM provides a structure for organizing and accumulating information about physical artifacts, which may, but must not be products. Project models are considered to be contents of an OMM. Consequently, efforts such as Semantic Product Modeling, which aim at semantically rich product descriptions, are considered complementary to the OMM.
- Product classification models
- There exist various standards for classifying products, such as eCl@ss. Often tailored for a particular application domain, these standards have their own justification - and it might even be necessary to provide several descriptions in an object memory, e.g., in order to reflect changing information interests along a product's lifecycle. Furthermore, these structures are meant to describe an object class, and thus reflect neither the characteristics of an individual object, nor change in an object's properties. The OMM does not want to establish a new means of classifying products. Its structure explicitly allows for storing several classifications, and is tailored for continuous extensions of the referred data collection.
- Object identifiers for the Internet of Things
- Applications in the Internet of Things usually require the identification of physical artifacts by means of a standardized identifier associated with the respective object. For the identification of objects several standards exist. Some of them are widely used, for instance EPC, EAN or GTIN codes - stored as barcode or RFID data tag -, or DUNS numbers for companies and manufacturer identification. In the scope of Internet of Things new identification standards came up, not only for products, also for more unspecified "things". Most important here is the IPV6 standard, which allows 6.5 x 10^23 addresses for each square meter worldwide. Other identifications like the ID@URI or DOI - the Digital Object Identifier are also common. Some of the identification systems require a registration; some are also not free of charge. Mostly the scope of the product use or handling defines which identification system should be used. The OMM does not want to introduce a new identification standard, and explicitly seeks to support information collection across several of such scopes. Therefore, the OMM allows for storing several identifiers (see Section 3.4.2).
- Modeling complex events
- Complex event processing is a technology used for providing real-time insights of events in business networks. Applications aim, for instance, at a greater end-to-end process visibility and therefore a higher agility of business processes. Based on a huge data stream of single data (e.g. recorded and send by sensors) this data is analyzed and complex events are defined. A complex event is a specific combination of simple events that represents a condition, a trend, or a change that is meaningful to an organization. While the OMM's block-based nature is meant to support data collection (including events), modeling complex events would be out of scope of this structure.
- Recording process instances
- Use cases of the OMM include scenarios, where an object is subject of a well-defined process (e.g., manufacturing). For modeling such a process, different standards exist. For instance, is the related area of business process modeling, prominent modeling approaches are BPMN 2.0 and event-driven process chains. These are used for the conceptualization of business processes and for the description of automatically executable workflows. While an object memory may accompany an object through such a process, the OMM itself does not want to model such a process. In contrast, it may serve as a container for the documentation of such a process, e.g., by means of memory blocks matching the respective process steps.
- Access logging
- For use cases such as Process Documentation (see Section 4.1) it might be interesting to record access to an object memory independently from the OMM's block-based structure. The XG members decided against supporting access logging explicitly due to the strong dependency of an access log's reliability from the employed (software-) mechanisms for enforcing access logging.
- Secure access and content integrity
- Secure access to object memories consists of two parts. First, secured data transfer, to avoid external observers to clearly see the interaction (read, modify and write actions) done with the object memory. Second, data integrity during data transfer to ensure that nobody (as man-in-the-middle) is able to modify the data during transport. The realization with certificates (e.g. X.509) is widely used to ensure data integrity and enable secure entity authentication. But these features are not part of the OMM because the model only deals with the general memory structure and techniques to easily find and access the wanted data, and does not cover the topics how to store and how to access such memories.
This document investigates and motivates structural characteristics of a model for object memories. It is meant for readers interested in several areas.
- Automation and supply-chain management
- An object memory wants to strengthen the role of an artifact in such processes, making it a tool for collecting and communicating data - and thus for documenting and steering processes.
- Smart Items
- Object memories can be used to let (digital services linked to) artifacts act smarter, e.g., by means of records describing an item's previous applications.
- Ubiquitous Web and Internet of Things
- The structure of the OMM was developed with a web-based application in mind, and thus might contribute to the linking of physical artifacts with web-based structures - in particular, by making data records about artifacts available in a unified way that facilitates their inclusion in web pages.
- Provenance
- Object memories are explicitly meant to support humans as well as machines in exploring the provenance of an artifact - e.g., where and under which conditions a certain product has been produced. Consequently, the OMM could be interpreted as a model of artifact provenance (see Section 2.4).
The OMM was investigated in the W3C context for several reasons. These share the idea that it should optionally be possible to store object memories in the Web in order to facilitate building and communicating object-related data:
- Long-term storage
- On a conceptual level, object memories want to support collecting data concerning individual physical artifacts - up to a complete lifecycle data collection. Use cases in general suggest a tight linking of artifact and memory - up to a physical connection of artifact and memory device as illustrated in Section 4.5. However, there are situations where a long-term remote storage would be beneficial - e.g., if an artifact might get lost or consumed.
- Community-generated content and open access
- Object memories may support human communication concerning a physical artifact. Then, users not in possession of the artifact require access to its object memory, as discussed in Section 4.2.
- Shared resources
- While the object memory concept explicitly wants to support a data model for the individual artifact, several artifacts (and their object memories) may nevertheless be required to share some data resource for reasons of efficiency. For instance, a single multimedia manual can be shared by the memories of all objects of a certain product series.
- Memories for the Internet of Things
- An object memory may address tasks in an Internet of Things, which require a thing to "remember" previous events.
The Physical Markup Language (PML) provides an XML-based mechanism for modeling physical properties of an artifact including aspects related to supply-chain management such as changing ownership or responsibilities. While the OMM XG members consider the firmer aspect to be out of scope of an OMM (see Section 1.3), the OMM is sharing some ideas of the latter aspect. While the OMM can be applied in the context of business processes (see, e.g., Section 4.1), it explicitly focuses only on the memory structure in order to emphasize openness of the model and to ensure independence from the application domain.
Use cases explored by the OMM XG showed that the subject of event logging is often a concern. Examples of how event logs and contents in an object memory are linked include the following:
- An event log could include information about the handling of an object (e.g. minimum or maximum temperature) that could be flagged if a critical event is registered. An object memory could contain logs of periodic sensor readings (e.g. temperature) that characterize the environment.
- An event log could document relevant processes during the lifecycle of an object such as production date, quality checks and maintenance activities. This information is important when object memories are used in complex production processes.
- An event log could document which people and/or devices interacted with an object during its lifecycle.
Modeling event logs is a complex topic and the development of a specification is a formidable task that would require including insights and use cases that are out of the scope of the OMM XG. Consequently, the group looked at related activities and event logging standards to analyze if and how the object memory format could benefit from an existing specification.
Common Event Expression (CEE - http://cee.mitre.org/about.html) is an active standardization project with a focus on how computer events are described, logged, and exchanged. Unlike other event logging standards that are mainly concerned with web server logs such as W3C Common Log file format (http://www.w3.org/Daemon/User/Config/Logging.html) and W3C Extended Log File format (http://www.w3.org/TR/WD-logfile.html) CEE aims to improve overall audit processes and to increase interoperability between event and log formats.
CEE contains of a number of different elements and will offer different levels of conformance. The specification contains of a log syntax (CLS) that describes how an event and its data are represented. The collection of possible event fields and value types of event records are described via a CEE Dictionary and the CEE Taxonomy defines a collection of tags that can be used to categorize events. The CEE community provides log recommendations (CELR) that are aimed at providing best practices what data to log and how to log it. Finally another part of the specification (CLT) describes what technical support is necessary (e.g. internationalization, interfaces for event recording) to support the transport of logs.
The OMM XG recommends to deal with event logging within an object memory as follows:
- A single OMM Block may be used to represent a single event, as illustrated in Section 4.1. Its metadata can be exploited to model the event. Limitations of this approach are twofold: First of all, if an application creates a huge number of events, then this may "overcrowd" an object memory, and thus making it difficult to handle in scenarios with strong limitations in the employed storage and interaction hardware. Second, the payload of such event blocks is not subject of the format, which may become an issue if a log has to be established across several applications.
- Alternatively, an application may store an event log as payload of an OMM Block. The option to remotely store payload data is of particular advantage if large logs have to be represented. In order to facilitate communication concerning some object between applications, the OMM XG recommends to rely on a standardized event modeling format, in particular CEE.
After several years of discussion the standard IEEE 1451.7 (identical to ANSI 1451.7) has been published on the 26th of June 2010. Its full title is "Standard for a smart transducer interface for sensors and actuators-transducers to radio frequency identification (RFID) systems communication protocols and transducer electronic data formats".
This standard includes a binary data model for describing the key features of the sensor / actuator as well as different event logging mechanisms. Different types of events and summaries (e.g., max value, means) are given. Finally an interface (also binary) to the transducer is given.
Because of its focus on binary representations and its narrow field of application, the approach is probably not directly applicable to our approach. Nevertheless, its extensive listing of event types and logging mechanisms is interesting.
An object memory seeks to enable different parties to contribute data to the memory (e.g., in order to record the exchange of an artifact between business partners), but also to provide a clear distinction of all of these contributions. As such, provenance of an object memory is two-fold: First of all, provenance of contributed data has to be represented. Second of all and depending on the use cases, the overall memory may represent the provenance of an artifact. Here, provenance of contained data is not constrained to a particular subject. The OMM relies on metadata in order to support retrieval of contained data. The reference implementation uses metadata based on Dublin Core Metadata (see Section 2.6) in order to describe provenance of contents within the memory.
Therefore, the OMM is related to some extent to activities devoted to provenance modeling - such as the W3C Provenance Working Group, which is aiming at a widespread publication and use of provenance information of web documents, data, and resources. The OMM may contribute to this activity. In turn, a generic provenance model (or mapping) would be of particular use for OMM-based applications: it is likely that scenarios involving parties from different application domains would result in object memories with contents following differing provenance models.
The OMM can be naturally encoded in an XML representation, and this report gives several examples of XML encoded OMMs. Given the restrictions of many potential OMM containers, such as RFID tags or even barcodes, a more concise, binary, representation format for the OMM is extremely desirable. However, translating the OMM to a representation suited for such labels is a challenge on its own, as discussed in [Seißler et al., 2010].
The W3C has expressed a recommendation concerning an Efficient XML Interchange (EXI) Format. It specifies a compact binary representation for XML documents, which could be applied in order to create a binary and highly compact representation of an OMM. From the use cases of the OMM, compactness is, however, not the only requirement of a binary OMM representation. For example, the OMM should support a distributed production process (see Section 4.1), where Programmable Logic Controllers (PLC) with only limited processing capabilities are very common. These cannot possibly parse the complete OMM, but still they need to access certain information from the OMM. In order to support these devices in existing manufacturing processes, it should be possible to identify the exact byte address of certain pieces of information in the OMM.
XML and consequently EXI do not allow for this, since, e.g., length information for attribute values is not maintained. An OMM binary representation should thus be specified using other means. A natural language specification together with a reference implementation was used in SemProM. This approach does, however, not scale easily to larger use cases, thereby deteriorating the benefit of standardization. The same drawbacks hold for other representations, such as JSON, which are commonly used as more compact representations instead of XML.
Outside the manufacturing and logistics domain, languages such as ASN.1 have been used to identify binary encodings for messages. ASN.1 specifications are, however, difficult to understand and not well supported in programming languages. More recently the need for defining binary encodings gained some attractions in the open-source and web community, when Facebook and Google released the Thrift and ProtocolBuffer framework respectively. Both of them are integrated in a growing number of programming languages, making the implementation of parsers and generators easy. They have been designed to achieve performance next to what is achievable with hand-crafted binary formats, while still maintaining a high readability and extensibility.
Out of the two Thrift comes closes to what is required for the OMM. The non-compact format of Thrift enables to specify binary formats with known byte-addresses for certain pieces of information. It is thus likely that a first binary representation of OMM should be undertaken using a binary format specified in Thrift (for an example, see OMM Binary Format Draft). Note that Thrift contains many more features besides the ability to produce and read binary messages according to a specification, e.g., generation of RPC stubs and network transport for messages. These will not be needed in the case of OMM. Instead, just the ability of writing and reading messages from and to files or in-memory arrays will be used. The transport of the messages will be done by other means, such as RFID.
"The Dublin Core Metadata Initiative, or 'DCMI', is an open organization engaged in the development of interoperable metadata standards that support a broad range of purposes and business models. DCMI's activities include work on architecture and modeling, discussions and collaborative work in DCMI Communities and DCMI Task Groups, annual conferences and workshops, standards liaison, and educational efforts to promote widespread acceptance of metadata standards and practices" (see http://dublincore.org/).
Together with the W3C's generic data model for metadata, the Resource Descriptive Framework (RDF), the Dublin Core Community developed application profiles leading to the creation of a core set of metadata extended with special domain specific data, that enabled us to use some of the Dublin Core metadata for our purposes and extend them with additional information, rather than defining a complete new set. So we used the core attributes Title, Description, Format, Creator, Contributor, Subject (partially) as foundation for our metadata set. We extended these core types with additional features to support our needs and complemented them with auxiliary object memory specific information.
This section summarizes a proposal concerning an object memory format on the basis of XML, which implements an object memory model. Format and model were designed to be independent from the application scenario; they address the OMM XG's success criteria (cf. Section 1.2) as follows:
- The overall object memory format doesn't impose particular constraints on the description of a physical artifact's individual characteristics and technical capabilities - the OMM XG considered such models to be out of this activity's scope (see Section 1.3). Thus, the application(s) are free to store detailed object descriptions in the payload of memory blocks. In addition, a memory header and a table of contents provide hints concerning the presence of this data.
- The memory is partitioned into blocks. Over time, new blocks may be added in order to add information about the object. This enables the representation and organization of individual event histories and thus the evolution of properties of a single artifact.
- The block-based mechanism seeks to clearly separate contributions made by changing owners of the artifact. In order to provide further support for retrieval and access along the product lifecycle, the object memory format defines a small set of keywords shared by each instance of an object memory. Among other features, these keywords allow for specifying information about the provenance of the respective block.
- Prototypes have shown that the use of blocks is beneficial for a translation of the memory according to (memory) capacity constraints imposed by smart label technology. An application is free to choose a subset of blocks from the memory for storage on a label attached to the artifact. The object memory format includes a definition of memory links, which can be employed to connect the various parts of such a distributed memory.
In the following, the individual parts of the object memory format are discussed in more detail. The discussion is accompanied by XML code snippets, which illustrate the application of the format. More complex examples on the basis of use cases investigated in projects affiliated to the OMM XG are described in Section 4. The key words must, must not, required, should, should not, recommended, may, and optional in this specification are to be interpreted as described in [RFC2119].
Figure 1: General OMM Structure
The proposed object memory format partitions an object memory into several blocks. Each block contains a specific information fragment and provides a set of metadata to ease search tasks the data itself (see Figure 1). This list of blocks is supplemented with an optional table of contents (ToC, see Section 3.2) and a header section. This header contains the version of the OMM, a primary unique identifier ("primary ID") for this object memory and an optional link to additional external block sources.
The OMM Header introduces a new object memory. It defines the memory's encoding version and defines a primary ID.
This primary ID is optional but fixed for this memory once set. It is used to define relations between an object memory and other memories, additional (external) blocks, and other structures (see Section 3.4). If there is no need for such relations, then the primary ID is optional; otherwise it is required. Additional and temporary IDs for this memory can be defined within a special IDs Block. Furthermore, additional blocks can be stored outside this XML file and linked with this memory within the header.
The following examples shows an OMM header with version 1 (<omm:version>, required), the URL "http://www.w3.org/2005/Incubator/omm/samples/p1" as primary ID (<omm:primaryID>, required) and
the URL "http://www.w3.org/2005/Incubator/omm/samples/p1/ext" as source of other OMM blocks (<omm:additionalBlocks>, optional),
that can be fetched via http (==> type "omm_http").
<omm:header>
<omm:version>1</omm:version>
<omm:primaryID omm:type="url">http://www.w3.org/2005/Incubator/omm/samples/p1</omm:primaryID>
<omm:additionalBlocks omm:type="omm_http">http://www.w3.org/2005/Incubator/omm/samples/p1/ext</omm:additionalBlocks>
</omm:header>
Each object memory block contains information about a specific topic. All blocks are on a par, the arrangement of the blocks does not imply any order. There are no access regulation and constraints defined, so anybody that has access to the XML file is allowed to add, change or remove blocks without any restrictions. Due to this fact, an application cannot act on the assumption that a specific information block is available at a specific time. To enable users and applications to identify relevant blocks (see Figure 2) a set of block metadata indicates the block's topic, which is stored in the block payload.
Figure 2: An OMM Block consists of metadata and payload.
The following overview shows the metadata attributes in detail:
- ID
- Namespace
- Format
- Creator
- Contributor
- Title
- Description
- Type
- Subject
- Link
Payload
- Purpose: Enables inline payload storage as alternative to the linked structure.
- Type: CDATA (plain text or XML structures).
- Attributes:
- Encoding (
omm:encoding, optional): Indicates the binary encoding used for this payload (e.g. "base64")
- Optional (Required, if no "Link" is given)
- Necessity: Inline payload, without the necessity of any external storage.
- Code sample (1) showing a simple text string as payload:
<omm:payload omm:encoding="none">123-55787-52</omm:payload>
- Code sample (2) showing a base64 encoded text string as payload:
<omm:payload omm:encoding="base64">UG9seWZvbiB6d2l0c2NoZXJuZCBhw59lbiBNw6R4Y2hlbnMgVsO2Z2VsIFLDvGJlbiwgSm9naHVydCB1bmQgUXVhcms=</omm:payload>
- Code sample (3) showing a proprietary embedded XML structure as payload:
<omm:payload omm:encoding="none">
<other:data>
<other:id other:tag="ee1234">AAA11214</other:id>
</other:data>
</omm:payload>
The following box shows a complete sample for an OMM Block with several metadata, link and payload information (just for this example since link and payload usually don't appear in the same block):
<omm:block omm:id="block_123">
<omm:namespace>http://www.w3.org/2005/Incubator/omm/ns/sample</omm:namespace>
<omm:format omm:schema="http://www.w3.org/2005/Incubator/omm/schema/sample.xsd" omm:encryption="none">application/xml</omm:format>
<omm:creation>
<omm:creator omm:type="duns">195505177</omm:creator>
<omm:date omm:encoding="ISO8601">2011-01-30T18:30:00+02:00</omm:date>
</omm:creation>
<omm:contribution>
<omm:contributor omm:type="email">user@example.com</omm:contributor>
<omm:date omm:encoding="ISO8601">2011-01-31T08:12:50+02:00</omm:date>
</omm:contribution>
<omm:title xml:lang="en">sample title</omm:title>
<omm:title xml:lang="de">Beispieltitel</omm:title>
<omm:description xml:lang="en">sample description</omm:description>
<omm:description xml:lang="de">Beispielbeschreibung</omm:description>
<omm:description xml:lang="fr">description example</omm:description>
<omm:type>http://purl.org/dc/dcmitype/Dataset</omm:type>
<omm:subject>
<omm:tag omm:type="ontology" omm:value="http://o.org/def.owl#ManufacturerData" />
<omm:tag omm:type="ontology" omm:value="http://www.w3.org/2005/Incubator/omm/ontologies/v1/phase.owl#Production" />
<omm:tag omm:type="text" omm:value="ingredients" />
<omm:tag omm:type="text" omm:value="norms">
<omm:tag omm:type="text" omm:value="din">
<omm:tag omm:type="text" omm:value="e12" />
</omm:tag>
</omm:tag>
</omm:subject>
<omm:link omm:type="url" omm:hash="d32b568cd1b96d459e7291ebf4b25d007f275c9f13149beeb782fac0716613f8">http://www.w3.org/2005/Incubator/omm/samples/p1/ext.xml</omm:link>
<omm:payload omm:encoding="base64">(...)</omm:payload>
</omm:block>
Figure 3: The OMM Table of Contents comprises a subset of each block's metadata.
The OMM includes a definition for a table of contents (ToC). This optional structure is meant for scenarios, where reading the entire object memory would be inconvenient or cause technical issues. Example scenarios include the classification of an object with a memory populated by a huge number of blocks, the interaction with memories with externally stored blocks, and memory stores without random access capabilities. In such scenarios, communication efforts may be reduced by reading the ToC instead of the entire store.
A ToC entry relies on a subset of an OMM Block's metadata attributes (see Figure 3). It is required to share the referenced OMM Block's identification attributes ("ID" and either "Namespace", "Format" or both of them). By using the same ID in the block and the ToC, the ToC entry is linked to the corresponding block. Furthermore, the attributes "Creator" and "Title" are recommended for a ToC entry if they are defined in the corresponding block. All other attributes are optional, but can be set in the ToC in order to provide additional support for searching an object memory.
The following XML code sample shows a possible table of contents entry for the OMM Block mentioned in Section 3.2:
<omm:toc>
<omm:element omm:id="block_123">
<omm:namespace>http://www.w3.org/2005/Incubator/omm/ns/sample</omm:namespace>
<omm:format omm:schema="http://www.w3.org/2005/Incubator/omm/schema/sample.xsd" omm:encryption="none">application/xml</omm:format>
<omm:creation>
<omm:creator omm:type="duns">195505177</omm:creator>
<omm:date omm:encoding="ISO8601">2011-01-30T18:30:00+02:00</omm:date>
</omm:creation>
<omm:title xml:lang="en">sample title</omm:title>
<omm:title xml:lang="de">Beispieltitel</omm:title>
<omm:subject>
<omm:tag omm:type="ontology" omm:value="http://o.org/def.owl#ManufacturerData" />
<omm:tag omm:type="ontology" omm:value="http://www.w3.org/2005/Incubator/omm/ontologies/v1/phase.owl#Production" />
<omm:tag omm:type="text" omm:value="ingredients" />
<omm:tag omm:type="text" omm:value="norms">
<omm:tag omm:type="text" omm:value="din">
<omm:tag omm:type="text" omm:value="e12" />
</omm:tag>
</omm:tag>
</omm:subject>
</omm:element>
</omm:toc>
The object memory format includes a small set of templates concerning the payload of an OM Block. If a block is making reference to such a template, it is denoted a "standardized block". These blocks either have a particular function concerning the object memory (and thus implement an aspect of the OMM), or address basic applications of an object memory. Overall, standardized blocks are meant to ease the communication between different applications running on the same object memory.
The Structure Block enables users and applications to store relationships between the object and other objects. For production and manufacturing scenarios (see Section 4.5) this approach can handle connection and integration information such as "Object A is connected with Object B" or "Object A is part of Object B". In addition each relation information is extended by time and date to indicate the moment this relation became valid or to indicate the time span this relation has been valid (see example). The structure block is indicated by the namespace attribute "http://www.w3.org/2005/Incubator/omm/ns/structureBlock". To ensure interoperability, the following relations are predefined by the OMM XG, but users can extend this list with their own custom relations:
- isConnectedWith
- isPartOf
- hasPart
- isStoredIn
- other custom values
The following example shows two structural relations.
The first relation is currently valid and was stored on January 30th, 2011 (2011-01-30T18:30:00+02:00). The structure
defines a isPartOf-relation to an object identified by its ID "http://www.w3.org/2005/Incubator/omm/samples/p2" of type "URL".
The second structure information was valid from January 30th, 2011 (2011-01-30T18:30:00+02:00) to February 17th, 2011 (2011-02-17T18:30:00+02:00) and defines
a isConnectedWith-relation to an object identified by its ID "http://www.w3.org/2005/Incubator/omm/samples/p3" of type "URL".
<omm:block omm:id="block_1234">
<!-- METADATA -->
<omm:namespace>http://www.w3.org/2005/Incubator/omm/ns/structureBlock</omm:namespace>
<omm:format omm:schema="http://www.w3.org/2005/Incubator/omm/schema/structureBlock.xsd" omm:encryption="none">application/xml</omm:format>
<omm:payload omm:encoding="none">
<omm:structure>
<omm:structureInformation>
<omm:date omm:encoding="ISO8601">2011-01-30T18:30:00+02:00</omm:date>
<omm:relation omm:relationType="isPartOf" omm:type="url">http://www.w3.org/2005/Incubator/omm/samples/p2</omm:relation>
</omm:structureInformation>
<omm:structureInformation>
<omm:timeSpan>
<omm:begin omm:encoding="ISO8601">2011-01-30T18:30:00+02:00</omm:begin>
<omm:end omm:encoding="ISO8601">2011-02-17T18:30:00+02:00</omm:end>
</omm:timeSpan>
<omm:relation omm:relationType="isConnectedWith" omm:type="url">http://www.w3.org/2005/Incubator/omm/samples/p3</omm:relation>
</omm:structureInformation>
</omm:structure>
</omm:payload>
</omm:block>
The IDs Block is intended to handle several object IDs. These IDs are complementary to the primary ID (see Section 3.1) stored in the OMM Header. The IDs Block allows for handling several IDs during the object's life cycle, or to ease maintenance tasks (see Section 4.3). The IDs Block is indicated by the namespace attribute "http://www.w3.org/2005/Incubator/omm/ns/idsBlock".
The following example illustrates how two identifiers are assigned to an object, one of type "URL" ("http://www.w3.org/2005/Incubator/omm/samples/p2") and one of type "email" ("p2@producer.org").
<omm:block omm:id="block_12345">
<!-- METADATA -->
<omm:namespace>http://www.w3.org/2005/Incubator/omm/ns/idsBlock</omm:namespace>
<omm:format omm:schema="http://www.w3.org/2005/Incubator/omm/schema/idsBlock.xsd" omm:encryption="none">application/xml</omm:format>
<omm:payload omm:encoding="none">
<omm:identification>
<omm:identifier omm:type="url">http://www.w3.org/2005/Incubator/omm/samples/p2</omm:identifier>
<omm:identifier omm:type="email">p2@producer.org</omm:identifier>
</omm:identification>
</omm:payload>
</omm:block>
This template extends the OMM payload part with a generic key-value structure, which may be used in several domains. The Key-Value Block Template serves in the very first place as formatting element (see example use case in Section 4.1). Its application is indicated by the format schema attribute "http://www.w3.org/2005/Incubator/omm/schema/attributeList.xsd". The following example shows two key-value pairs with keys "numberPillA" and "numberPillA" and corresponding values (1 and 2):
<omm:block omm:id="block_12346">
<!-- METADATA -->
<omm:format omm:schema="http://www.w3.org/2005/Incubator/omm/schema/attributeList.xsd" omm:encryption="none">application/xml</omm:format>
<omm:payload omm:encoding="none">
<omm:attributeList>
<omm:attribute omm:key="numberPillA">1</omm:attribute>
<omm:attribute omm:key="numberPillB">2</omm:attribute>
</omm:attributeList>
</omm:payload>
</omm:block>
The following use cases illustrate various applications of the OMM. The examples include code snippets, which focus particular aspects of the previously discussed object memory format. The majority of these use cases originate from scenarios, where statements about an artifact are expressed or accessed by multiple parties, either along a well-defined process, or in an open fashion common for scenarios with user-generated content.
It is noteworthy that implementations of these examples - which have been explored in related activities, see Section 1.1 - rely on various kinds of interaction devices and storage architectures. Matching the diversity of situations that may require access to an OMM, these may even change in a single application. For instance, the scenario described in Section 4.5 may require hybrid access via a mobile device for a technician as well as via a desktop control application for a supervisor, both connected via a hybrid infrastructure involving OMM storage at the artifact (via a smart label) and a web server. These aspects are neglected in the context of this document due to its focus on the modeling aspect of OMM, but may require further attention.
The following XML code sample introduces the memory content (with OMM Header and OMM Table of Contents and a link to additional blocks of this memory) for the uses cases described below:
<omm:omm>
<omm:header>
<omm:version>1</omm:version>
<omm:primaryID omm:type="url">http://www.w3.org/2005/Incubator/omm/samples/p1</omm:primaryID>
<omm:additionalBlocks omm:type="omm_http">http://www.w3.org/2005/Incubator/omm/samples/p1/ext</omm:additionalBlocks>
</omm:header>
<omm:toc>
<omm:element omm:id="11">
<omm:namespace>http://myCompany.org/omm/logging</omm:namespace>
<omm:title xml:lang="en">log event</omm:title>
<omm:creation>
<omm:creator omm:type="duns">19-550-5178</omm:creator>
<omm:date omm:encoding="ISO8601">2011-01-11T19:20:00+01:00</omm:date>
</omm:creation>
<omm:subject>
<omm:tag omm:type="text" omm:value="event" />
</omm:subject>
</omm:element>
<omm:element omm:id="12">
<omm:namespace>http://myCompany.org/omm/logging</omm:namespace>
<omm:title xml:lang="en">log event</omm:title>
<omm:creation>
<omm:creator omm:type="duns">19-550-5178</omm:creator>
<omm:date omm:encoding="ISO8601">2011-01-11T19:21:00+01:00</omm:date>
</omm:creation>
<omm:subject>
<omm:tag omm:type="text" omm:value="event" />
</omm:subject>
</omm:element>
(... toc entry for blocks 13 - 61 ...)
</omm:toc>
In complex production processes there is a need to have knowledge about every single process step. Especially in industries such as aerospace, defense or chemistry, there are requirements for such information for audits and for safety reasons. In order to increase efficiency, to avoid errors and to increase product quality, process data can be recorded in an object memory linked with objects (see, e.g., [Schneider et al., 2008] and [Stephan et al., 2010]). These objects can be products as well as machines and tools employed during production. Their object memory may leverage communication between the actual objects and the respective process. For instance, if a product's object memory is carrying an entry about a failure during a routing process, then the next routing process may decide not start. Similarly, the following production-specific information might be stored in an object memory:
- Timestamps regarding specific production events
- Routing start / routing finish
- Production start / production finish
- Process history information
- Routing successful finished
- Routing finished with errors
- Quality check successful
- Unexpected events
- Process environment information
- Used tools
- Involved employees and their skills
- Energy consumption
The following example illustrates the documentation of a production process including three successfully finished steps. These production steps are the transportation of the work piece to the work center, the production of a work piece and the quality control by measurement of the produced work piece. Each production process step is documented by a single <omm:block>. After the definition of the block ID and language follow the DUNS number of the manufacturer as the identification of the creator and the time stamp of the block creation, both stored in <omm:creation>. <omm:type> is employed to mark a block as event. Similarly, <omm:subject> assigns a tag "event", which is also visible in the ToC. The actual event data ("action", "begin", "end") are specified in <omm:payload> using the Key-Value Block Template.
<omm:block omm:id="11">
<omm:namespace>http://myCompany.org/omm/logging</omm:namespace>
<omm:format omm:schema="http://www.w3.org/2005/Incubator/omm/schema/attributeList.xsd" omm:encryption="none">application/xml</omm:format>
<omm:title xml:lang="en">log event</omm:title>
<omm:creation>
<omm:creator omm:type="duns">19-550-5178</omm:creator>
<omm:date omm:encoding="ISO8601">2011-01-11T19:20:00+01:00</omm:date>
</omm:creation>
<omm:type>http://purl.org/dc/dcmitype/Event</omm:type>
<omm:subject>
<omm:tag omm:type="text" omm:value="event" />
</omm:subject>
<omm:payload>
<omm:attributeList>
<omm:attribute omm:key="action">Transport</omm:attribute>
<omm:attribute omm:key="begin">2011-01-11T19:03:00+01:00</omm:attribute>
<omm:attribute omm:key="end">2011-01-11T19:04:00+01:00</omm:attribute>
</omm:attributeList>
</omm:payload>
</omm:block>
<omm:block omm:id="12">
<omm:namespace>http://myCompany.org/omm/logging</omm:namespace>
<omm:format omm:schema="http://www.w3.org/2005/Incubator/omm/schema/attributeList.xsd" omm:encryption="none">application/xml</omm:format>
<omm:title xml:lang="en">log event</omm:title>
<omm:creation>
<omm:creator omm:type="duns">19-550-5178</omm:creator>
<omm:date omm:encoding="ISO8601">2011-01-11T19:21:00+01:00</omm:date>
</omm:creation>
<omm:type>http://purl.org/dc/dcmitype/Event</omm:type>
<omm:subject>
<omm:tag omm:type="text" omm:value="event" />
</omm:subject>
<omm:payload>
<omm:attributeList>
<omm:attribute omm:key="action">Production</omm:attribute>
<omm:attribute omm:key="begin">2011-01-11T19:04:00+01:00</omm:attribute>
<omm:attribute omm:key="end">2011-01-11T19:05:00+01:00</omm:attribute>
</omm:attributeList>
</omm:payload>
</omm:block>
<omm:block omm:id="13">
<omm:namespace>http://myCompany.org/omm/logging</omm:namespace>
<omm:format omm:schema="http://www.w3.org/2005/Incubator/omm/schema/attributeList.xsd" omm:encryption="none">application/xml</omm:format>
<omm:title xml:lang="en">log event</omm:title>
<omm:creation>
<omm:creator omm:type="duns">19-550-5178</omm:creator>
<omm:date omm:encoding="ISO8601">2011-01-11T19:22:00+01:00</omm:date>
</omm:creation>
<omm:type>http://purl.org/dc/dcmitype/Event</omm:type>
<omm:subject>
<omm:tag omm:type="text" omm:value="event" />
</omm:subject>
<omm:payload>
<omm:attributeList>
<omm:attribute omm:key="action">QualityCheck</omm:attribute>
<omm:attribute omm:key="begin">2011-01-11T19:05:00+01:00</omm:attribute>
<omm:attribute omm:key="end">2011-01-11T19:06:00+01:00</omm:attribute>
</omm:attributeList>
</omm:payload>
</omm:block>
In different scenarios (e.g. retail, social enterprises, collectors) it is often perceived as desirable to have provenance information about the origin of an object or previous interactions with an object. The knowledge about the history of an object may impact consumer behavior and add value to an object. Examples of this are added information about the producer of a product such as in a fair trade shop, information about previous owners of the object in scenarios that deal with second hand goods and generally of peoples' interactions with a product over the course of its lifecycle. This provenance information can include different media and can be open ended in its structure.
A special use case is when this provenance information is stored remotely. A rationale for such a distributed object memory is that some objects might have unique tags (e.g., RFID, QR code, and barcode) but they don't possess computational capabilities so that client applications such as mobiles interact with a centralized service to read and write service information related to a tagged object. Such distributed object memories might be accessible by different means.
Figure 4: Tales of Things employs object memories in order to support humans in the communication about objects.
The following XML example shows an object memory that was created by the Tales of Things (http://talesofthings.com) service. The service relies on a centralized web server for organizing object-related data. As illustrated in Figure 4, users build a personal pool of objects and corresponding memories, which can be made accessible to other users in a web-based platform (1). Within an object memory, the memory creator may store references to multimedia data hosted at other servers in order to describe the object (2). Other users may comment on the object (3). The two blocks of the example XML contain information when and by whom they were created. <omm:namespace> identifies the context for the data structure. The first block uses <omm:link> and <omm:format> to indicate that the payload of this block is externally available via a URL in JSON (Java Script Object Notation) format. The second block has an identical structure but links to a different URL where the payload is available in RDFa format.
<omm:block omm:id="21">
<omm:title xml:lang="en">Kelvin Electrical Balance</omm:title>
<omm:description xml:lang="en">This instrument was made by the Glasgow company James White. Founded in 1850,....</omm:description>
<omm:creation>
<omm:creator omm:type="email">someone@talesofthings.com</omm:creator>
<omm:date omm:encoding="ISO8601">2010-07-12T11:22:00+01:00</omm:date>
</omm:creation>
<omm:namespace>http://www.totemlabs.com/talesofthings/elements/1/</omm:namespace>
<omm:format>application/json</omm:format>
<omm:link omm:type="url">http://talesofthings.com/api/things/6638/</omm:link>
</omm:block>
<omm:block omm:id="22">
<omm:title xml:lang="en">Kelvin Electrical Balance</omm:title>
<omm:description xml:lang="en">This instrument was made by the Glasgow company James White. Founded in 1850,....</omm:description>
<omm:creation>
<omm:creator omm:type="email">someone@talesofthings.com</omm:creator>
<omm:date omm:encoding="ISO8601">2010-07-12T11:22:00+01:00</omm:date>
</omm:creation>
<omm:namespace>http://www.totemlabs.com/talesofthings/elements/1/</omm:namespace>
<omm:format>application/rdf+xml</omm:format>
<omm:link omm:type="url">http://talesofthings.com/totem/totem_view/6638/</omm:link>
</omm:block>
In maintenance scenarios the concise identification of objects (assets) is an essential requirement for an effective maintenance process. The asset has to be easily identifiable with different IDs, because typically an asset has at least a serial number, an equipment ID and a location identification code. In addition to these identifiers assets may contain classifications and any number of valid values for each classification. An example are the Level of Maintenance classification codes (LMC codes), which define the importance of an asset in a specific domain. A maintenance technician uses the location identification code (e.g. +A10-F03) to identify the asset in a given context (e.g. plant), while a warehouse clerk needs the order number (e.g. 6SE6420-2AD22-2BA1) to get a spare part if the object must be replaced.
The OMM wants to support the usage of multiple identifiers and classifications. OMM offers a standardized IDs Block, which facilitates the storage of identifiers and classifications within the payload of the block as XML elements.
The following XML sample shows an IDs Block with two different IDs, which are specified with a type. <omm:namespace> identifies this block as IDs Block with a defined payload structure. The first ID element contains a Bluetooth address which is described by the type "Bluetooth". The second ID element is an identifier for RFID tagging at the item level (EPC SGTIN-96).
<omm:block omm:id="31">
<omm:namespace>http://www.w3.org/2005/Incubator/omm/ns/idsBlock</omm:namespace>
<omm:format omm:schema="http://www.w3.org/2005/Incubator/omm/schema/idsBlock.xsd" omm:encryption="none">application/xml</omm:format>
<omm:title xml:lang="en">Object identifiers</omm:title>
<omm:creation>
<omm:creator omm:type="email">user@deviceproducer.com</omm:creator>
<omm:date omm:encoding="ISO8601">2011-09-18T12:30:00+02:00</omm:date>
</omm:creation>
<omm:type>http://purl.org/dc/dcmitype/Dataset</omm:type>
<omm:format>application/xml</omm:format>
<omm:payload>
<omm:identification>
<omm:identifier omm:type="bluetooth">01-02-03-04-05-06</omm:identifier>
<omm:identifier omm:type="SGTIN-96">0x30700048440cc8002e185623</omm:identifier>
</omm:identification>
</omm:payload>
</omm:block>
Future industrial and automation scenarios will involve decentralized production processes. For example, subcontractors will be chosen on the fly. To support this novel flexibility it is desirable to collect all production-related product-specific information and to store it on the product parts as part of an object memory.
The OMM is suitable to describe the single productions steps and manipulation tasks that have to be performed on the individual product. Only this product-centered knowledge management approach, in which products communicate manipulation actions they require ("Fill in 3 pills of type A and close bin with cap") or the dispatching strategies ("Prefer time critical jobs") to the production systems, enables the efficient design of robust and flexible decentralized production processes.
The simplest form of a decentralized production process can be implemented with an object memory that only holds static product specific information (e.g., product ID, product color, production timestamp, product quality). In each production step, information is read from the object memory and the according manipulation actions and handling operations are derived in the process control and then performed on the product. Therefore, the product and information in its object memory can be considered as "passive" while the control and handling algorithms are implemented in the process control (of each production module).
The following XML sample shows an OMM Block, which specifies production information for a personal medicament product (Personal Pill Blister) that is produced by "YourPersonalMeds Inc.". The data in <omm:payload> is organized according to the Key-Value Block Template. It consists of two attributes denoting pill type ("SleppoPharm", "PainReliefSuper") and number of pills that has to be filled in the blister.
<omm:block omm:id="41">
<omm:namespace>http://www.YourPersonalMeds.com/blister/order/</omm:namespace>
<omm:format omm:schema="http://www.w3.org/2005/Incubator/omm/schema/attributeList.xsd" omm:encryption="none">application/xml</omm:format>
<omm:title xml:lang="en">Personal Pill Blister</omm:title>
<omm:creation>
<omm:creator omm:type="email">production@YourPersonalMeds.com</omm:creator>
<omm:date omm:encoding="ISO8601">2011-09-22T17:18:00+02:00</omm:date>
</omm:creation>
<omm:type>http://purl.org/dc/dcmitype/Collection</omm:type>
<omm:payload>
<omm:attributeList>
<omm:attribute omm:key="SleepoPharm">3</omm:attribute>
<omm:attribute omm:key="SleepoPharmURL">http://www.yourpersonalmeds.com/infos/medicaments/sleepopharm</omm:attribute>
<omm:attribute omm:key="PainReliefSuper">1</omm:attribute>
<omm:attribute omm:key="PainReliefSuperURL">http://www.yourpersonalmeds.com/infos/medicaments/painreliefsuper</omm:attribute>
</omm:attributeList>
</omm:payload>
</omm:block>
This use case addresses decentralized systems for mass production, helping to maintain a high degree of automation in the production process. The variation between the individual products stored in the OMM is limited to what the automated production line can achieve.
The OMM may, however, also assist in the decentralized production process for highly customized products, which cannot be automated to such a high degree. Such use cases are investigated in the SmartProducts project, which deals with manufacturing maintenance and use of complex technical products. One of the example scenarios considered in SmartProducts concerns the manufacturing of civil aircraft. Many steps in the production process of a civil aircraft need to be carried out by hand, as every aircraft is built to the specific requirements of the ordering airline. Thus, the production process needs to be tailored to a high degree for each aircraft instance.
Currently, this is done by handing out printed work orders to manufacturing operators. These read the written instructions and use the sheets to report back data relevant to the quality assurance process. Relying on paper documents for providing the process steps to the operator and for storing the quality assurance data often leads to problems, when the paper documents do not match the actual situation in the aircraft, e.g., sometimes work orders for wrong type of aircraft are used.
Aircraft manufacturing can benefit from storing the production procedures directly in the object memory of the aircraft, or a certain part of the aircraft, such as the cockpit. Due to the large variations between the different aircrafts, it does not suffice to store just parameters for different steps in the production process. The processes vary so much that the complete workflow must be stored in the object memory. These workflows may describe behavior that can be performed on a product by an operator. However, they may also contain activities that are performed by the product itself. To support the integration of workflow descriptions standardized workflow models (formalized e.g. via XPDL) can be stored in the OMM.
The following XML example shows an OMM block which describes a "manufacturing workflow" for an aircraft. XPDL is used to model the workflow process via a standardized, XML-based notation. This is indicated by the format tag using the MIME type "application/x-xpdl". The according XPDL document is stored within <omm:payload> of the OMM Block. Therefore, in this use case the OMM serves as a skeleton adding meta-information to the workflow description that can be directly stored on a product.
<omm:block omm:id="42">
<omm:namespace>http://www.wfmc.org/2002/XPDL1.0</omm:namespace>
<omm:title xml:lang="en">Harness Assembly Workflow</omm:title>
<omm:creation>
<omm:creator omm:type="email">production@aircraftcompany.com</omm:creator>
<omm:date omm:encoding="ISO8601">2011-06-06T17:13:38+02:00</omm:date>
</omm:creation>
<omm:format>application/x-xpdl</omm:format>
<omm:type>http://purl.org/dc/dcmitype/Software</omm:type>
<omm:payload>
<xpdl:Package>
<xpdl:PackageHeader>
<xpdl:XPDLVersion>1.0</xpdl:XPDLVersion>
<xpdl:Vendor>Together</xpdl:Vendor>
<xpdl:Created>2011-06-06 17:12:44</xpdl:Created>
</xpdl:PackageHeader>
<xpdl:WorkflowProcesses>
<xpdl:WorkflowProcess Id="ElectricalHarnessAssembly" Name="Assembly of electrical harness">
<xpdl:ProcessHeader>
<xpdl:Created>2011-06-06 17:13:38</xpdl:Created>
</xpdl:ProcessHeader>
...
</xpdl:WorkflowProcess>
</xpdl:WorkflowProcesses>
</xpdl:Package>
</omm:payload>
</omm:block>
In production scenarios component parts are often assembled to create a higher-value object. In the case of high-class objects such as automobiles, turbines, or computer tomographs it is reasonable to assume that even the components are valuable enough to have their own object memory. Examples could be the gearbox of an automobile or the low pressure section of a turbine.
While the new assembled object will get its own object memory, the information of the assembled components must stay accessible and changeable. For a reasonable handling it should be possible to build up a data structure which reflects the objects assembly. If parts of high-value products fail, these parts are repaired or exchanged. It must therefore be possible to alter the structure that reflects the objects assembly. Parts may be added or removed, connections between parts may be altered. If a part leaves the object (is dismantled) the object's memory should reflect its complete lifecycle including its life as a part of the object. I.e. a part should remember where it has been. As a counterpart the whole object should also be able to log the information about its dismantled parts. (E.g. an automobile should "know" that the engine was replaced two times. A re-installed engine should know if it was previously installed in another car.)
Figure 5: An object memory is used to document the assembly history of a complex object.
The OMM supports the description of structured objects with a standardized Structure Block, which enables the description of structures by means of relations (such as "has_part", "part_of") to the primary ID of object memories of the various object parts. Figure 5 shows an implementation of this approach, which was realized by the project SemProM. Each part of a complex device is carrying an RFID transponder, where a binary encoded object memory structure block is stored. A technician uses a mobile device to read and to update the structure block (2). In addition, the data is synchronized with a web-based representation, which allows for exploring the digitally linked object memories of the physically assembled objects (3).
The following XML sample shows an OMM Block, which describes two links to other object memories. The <omm:namespace> identifies this block as Structure Block. The two references in the payload are IDs with an additional relation attribute ("hasPart"), which shows that the current object has one added part ("http://www.example.com/omm/samples/part1") and another part has been but is no longer part of ("http://www.example.com/omm/samples/part2"). These parts in turn will have a Structure Block with an inverse relation ("isPartOf"), which is not visible in this example (because it is an element of another object memory).
<omm:block omm:id="51">
<omm:namespace>http://www.w3.org/2005/Incubator/omm/ns/structureBlock</omm:namespace>
<omm:format omm:schema="http://www.w3.org/2005/Incubator/omm/schema/structureBlock.xsd" omm:encryption="none">application/xml</omm:format>
<omm:title xml:lang="en">Object Assembly History</omm:title>
<omm:creation>
<omm:creator omm:type="email">user@example.com</omm:creator>
<omm:date omm:encoding="ISO8601">2011-09-19T16:30:00+02:00</omm:date>
</omm:creation>
<omm:type>http://purl.org/dc/dcmitype/Dataset</omm:type>
<omm:payload>
<omm:structure>
<omm:structureInformation>
<omm:date omm:encoding="ISO8601">2011-01-30T18:30:00+02:00</omm:date>
<omm:relation omm:relationType="hasPart" omm:type="url">http://www.example.com/omm/samples/part1</omm:relation>
</omm:structureInformation>
<omm:structureInformation>
<omm:timeSpan>
<omm:begin omm:encoding="ISO8601">2011-01-30T18:30:00+02:00</omm:begin>
<omm:end omm:encoding="ISO8601">2011-02-17T18:30:00+02:00</omm:end>
</omm:timeSpan>
<omm:relation omm:relationType="hasPart" omm:type="url">http://www.example.com/omm/samples/part2</omm:relation>
</omm:structureInformation>
</omm:structure>
</omm:payload>
</omm:block>
In industrial and automation scenarios it is desirable to have the ability to add information to object memories that should be unavailable for public reading because it is intended for some special user group only. For instance, object memory users may want to add information about confidential production processes, license-based data or information meant for bilateral communication.
The OMM wants to support such encrypted information, data providers should be enabled to easily add encrypted information. So it is possible to encrypt the payload data of each OMM Block and flag this fact with the omm:encryption attribute. This enables other application to skip this block unless they are able decrypt the data which can be detected by the given creator and content metadata of this block.
The following XML sample shows a block with AES256 encrypted binary data encoded as Base64 text.
The combination of data stored in <omm:namespace> and <omm:creator> allows users to detect whether they are able to decrypt this block or not (e.g. the namespace "encSample" and the creator "user@example.com" indicates the necessary AES key).
<omm:block omm:id="61">
<omm:namespace>http://www.example.com/omm/ns/encSample</omm:namespace>
<omm:creation>
<omm:creator omm:type="email">user@example.com</omm:creator>
<omm:date omm:encoding="ISO8601">2011-09-15T12:30:00+02:00</omm:date>
</omm:creation>
<omm:format omm:encryption="aes256">application/octet-stream</omm:format>
<omm:payload omm:encoding="base64">cGxlYXN1cmUu</payload>
</omm:block>
The OMM XG concludes that a unified model for information collections concerning artifacts can be achieved, and proposes a structure for such an object memory model. Use cases of this model are illustrated on the basis of an XML-based implementation of this model, the object memory format. Concerning the future direction this work, the group formulates the following recommendations:
- Recommendation ("model - standardized blocks"): The standardization of memory blocks for particular applications (see Section 3.4) might require further discussion. On the one hand, additional standardized blocks (e.g., for particular domains or stages of a product life-cycle) might be introduced in order to facilitate communication between actors in a process. On the other hand, a more complex specification might increase the efforts needed to integrate the object memory model into existing systems. Therefore, the OMM XG recommends to investigate on the basis of OMM applications if and which blocks should be standardized.
- Recommendation ("model - provenance"): As discussed in Section 2.4, advances concerning provenance modeling might suggest an adaptation of provenance aspects within the object memory model and object memory format. The OMM XG established a contact to the W3C Provenance Working Group and recommends to investigate this topic in cooperation with this group.
- Recommendation ("format"): The object memory format used in the context of this document relies on a particular XML schema. However, other formats may implement the object memory model as well. For instance, its similar structure and treatment of metadata might qualify the Atom Syndication Format as a tool to express an object memory model. In order to illustrate the feasibility of such alternative definitions, the OMM XG prepared examples of alternative object memory formats with a particular focus on embedding an object memory in web pages, e.g., on the basis of RDFa, or HTML5 and Microdata.
- Recommendation ("binary format"): The OMM XG recommends to devote attention to open issues according to the sequence of work specified in Section 1.2. These emphasize the role of the hardware and software environment where an object memory model would be deployed. As discussed in Section 2.5, memory capacity and processing limitations of devices present in such an environment suggest a highly efficient object memory format, e.g., on the basis of a binary representation. In order to explore this topic, the OMM XG conducted first experiments concerning an OMM Binary Format.
- Recommendation ("interface"): Some use cases suggest that the object memory format may be encountered on devices as well as web-based structures, and hybrid interaction involving both aspects may occur (see, e.g., Section 4.5). Therefore, the group recommends to add an additional goal to the charter - the specification of an object memory model API, which supports and unifies the interaction with devices carrying an object memory. As a very first step, the group established contact to the W3C Device APIs Working Group in order to discuss this goal.
As a consequence of these observations, the OMM XG recommends to continue investigating the topic of object memory modeling within the W3C - within activities affine to topics mentioned in Section 1.4 or as the subject of a new activity.
We like to thank Jörg Neidig, Thorbjørn Hansen, Markus Miche, Boris Brandherm, Jörg Baus, and Massimo Romanelli for their advise and support.
- AES
- Advanced Encryption Standard
- API
- Application programmable interface
- BPMN
- Business Process Model and Notation
- DUNS
- Data Universal Numbering System
- EPC
- Electronic Product Code
- EAN
- European Article Number
- GTIN
- Global Trade Item Number
- QR code
- Quick Response code
- RFID
- Radio-frequency identification
- SGTIN
- Serialised Global Trade Item Number
- XPDL
- XML Process Definition Language
- [Schneider et al., 2008]
- M. Schneider, A. Kröner: The Smart Pizza Packing: An Application of Object Memories. In Proceedings of the 4th International Conference on Intelligent Environments (IE 2008), Seattle, USA, 2008. DOI 10.1049/cp:20081136
- [Stephan et al., 2010]
- P. Stephan, G. Meixner, H. Kößling, Florian Flörchinger, Lisa Ollinger: Product-Mediated Communication through Digital Object Memories in Heterogeneous Value Chains. In Proceedings of the 8th IEEE International Conference on Pervasive Computing and Communications, Mannheim, Germany, IEEE, 2010.
- [Seißler et al., 2010]
- M. Seißler, I. Heck, P. Stephan, J. Schlick: Bridging the Gap between Digital Object Memory Information and Its Binary Representation. In DOME-IoT: International Workshop on Digital Object Memories in the Internet of Things, Pages 25-30, Copenhagen, Denmark, 2010. Technical Report DFKI-D-10-01.
- [DOMe]
- International Workshop on Digital Object Memories 2009, 2010, 2011. URL: http://www.dfki.de/dome-workshop/
- [HTML5]
- I. Hickson; D. Hyatt (Eds.): HTML5: A vocabulary and associated APIs for HTML and XHTML. W3C Working Draft, 2011. URL: http://www.w3.org/TR/html5/
- [RDFa]
- B. Adida, M. Birbeck, S. McCarron, S. Pemberton (Eds.): RDFa in XHTML: Syntax and Processing. W3C Recommendation, 2008. URL: http://www.w3.org/TR/2008/REC-rdfa-syntax-20081014/
- [RFC2119]
- S. Bradner: Key words for use in RFCs to Indicate Requirement Levels. Internet RFC 2119, 1997. URL: http://www.ietf.org/rfc/rfc2119.txt