2011-05-23-Protocol

Scribe's note: This document provides a result-oriented, highly-compressed wrap-up of two days of intense discussions.
Members mentioned at session titles acted as guiding moderators of the respective session.
The document was confirmed during the phone conference on June 10, 2011.

Participants

• DFKI: Alexander Kröner (scribe), Boris Brandherm, Jens Haupert, Marc Seißler
• SAP: Sven Horn
• Siemens: Jörg Neidig, Bruno Kiesel
• TU/D: Daniel Schreiber
• UCL: Ralph Barthel
• Guest: Markus Miche

TOP 1 Introduction

Alexander Kröner: XG and beyond

• Remaining XG runtime: The activity is on time, and will continue following its roadmap. A final report is required; however, there are or formal criteria concerning that report’s structure and content. Suggested are use cases with examples, XML syntax, and guidelines (“how to”).
• After the XG runtime: If the activity should be continued at the W3C, then results have to be transferred into an existing working group, or a new working group needs to be established. In preparation of this process, the XG has to advertise its results in order to acquire more members (and thus signalizing W3C relevance). Furthermore, the topic has to be discussed with W3C Activity chairs. Here, the members found most promising: Ubiquitous Web, Provenance, and Multimodal interaction.
• ACTION
  • The activity chairs have to be contacted.

TOP 2 The OMM: Current Status and Known Issues

Jens Haupert: Syntax Details

• Overall, the presented XML syntax is accepted by the members; this holds as well for the “omm” namespace. The semantics and location of an “omm:PrimaryId” is accepted.
• In the current OMM XML representation, a block header always precedes its respective content section. In contrast, in the binary SemProM format, all block headers of a memory are bundled in the very beginning of the binary structure. This facilitates quick access to retrieval keys, and allows for reading retrieval keys without need to parse the complete memory – a necessity for highly constrained (in terms of read performance) RFID chips. It is discussed if that approach is of value for an XML-based representation as the OMM. Actually, there is an agreement that SAX-based parsing software might benefit from such an approach, especially if large-scale memories occur. The topic is not perceived as crucial (overlap with the following ToC discussion); therefore, the current structure is kept. This decision might be re-evaluated in the future.
• Future discussion
  • With respect to potential hardware limitations, there might be a need to limit the size of an id – or to translate it.
  • So far, the OMM does not address the distribution of a single OMM across several files. However, there are scenarios where explicit support for such a distribution would be valuable, e.g, if a small excerpt is stored at the object’s label, and the complete file resides on a Web server.

Bruno Kiesel: Table of Contents (ToC)

• A table of contents (ToC) would facilitate the interaction with an OMM – in particular, in order to get an idea of where which kinds of blocks are stored. The members agree that an automated generation of such a ToC required for reducing maintenance efforts.
• The ToC should be generated automatically from block headers. This implies that certain block metadata should be present in order to facilitate automated generation. Furthermore, this emphasizes the need for a carful metadata selection.
• The ToC might be part of the memory file or be generated on-the-fly during runtime “virtual ToC”. Preferred is an optional, but standardized block, which allows the application designer to decide on that issue depending on the employed (label) technology.
• ACTION
  • A formal XML definition of the ToC is required.
• Future discussion
  • If the distribution of an OMM is planned (currently not planned), a re-evaluation of the ToC structure and handling might be required.
  • The topic might interact with a binary representation (example: attribute namespace)

Jörg Neidig: Block Meta Data

• In SemProM demonstration systems, only few meta data were used, in the first place due to technical constraints and the lack of discovery actions (unknown actions).
• Concerning the link to the Semantic Web – the OMM is a structure model as such just XML; linking the Semantic Web should be explicitly supported.
• A meta data dictionary is required (like Dublin Core) – this might be linked with the standardization of blocks. Recommended is a separation of structure discussion and this dictionary, as the latter one requires an evolutionary process.
• Overall, a meta data definition should be constrained to a controlled vocabulary in order to support quick access without complex parsing efforts (e.g., on limited PLCs). It should be combined with the option for free metadata in order to support the evolution of the vocabulary as well as free form description.
• Human-readable metadata might support lookup of particular data.
• ACTION
  • This vocabulary needs to be identified on the basis of work from SemProM.
• Future discussion
  • A subject that might be investigated in more depth on the basis of use cases – retrieving previously stored information vs. retrieving unknown information.

Marc Seißler: Binary vs. XML

• A crucial question is where the XML representation will be used with respect to layers in an automation architecture (e.g., unusual at the PLC layer) in order the judge processing requirements to the respective (application) environment.
• Related W3C activities include EXI and Binary XML. These might address the memory capacity issue of many kinds of Smart Labels. However, these reorganize and encode the original semantics of the XML source.
  • Therefore, complex decoders are required to run at the application device. Unfortunately, embedded devices might not be able to perform the non-trivial decoding operations.
  • Furthermore, these formats provide only limited support for direct access operations.
• The decision on binary or XML-based storage will depend on the kind of Smart Label technology.
  • Reference-based approaches require an extension of current reference standards (e.g., EPC Global).
• DECISION
  • The members agree that there should be only a single kind of binary encoding.
  • Minimum byte sizes for binary / XML representations need to be specified.
  • Recommendations concerning this decision process might be of interest as well.
• Future discussion
  • Binary encodings will favor subsets of data stored via the original XML representation of an OMM. How does the subset selection work?
  • This can most likely not be addressed during the XG runtime. Smart Products is currently researching related approaches.
  • An API will be required. This is not subject of the OMM (as a modeling attempt) as such; however, prototypes might be offered at the end of the XG runtime.

Jörg Neidig: Standardized Blocks

• In SemProM demonstration systems, each content block had a particular semantics assigned.
• For product catalogs, often particular standards are employed. For instance, eCl@ss is widely adopted for product categorization; matching representations (XML) exist.
• It is required that such standards can be mapped to an OMM. Furthermore, matching retrieval helpers such as meta data should be provided.
• Required are meta data indicating the presence of some block containing data encoded according to some particular standard. Meta data of such a block should follow a standardized structure (e.g., title, schema).
• A simplified description should support rapid application development and interaction with unknown object types.
  • Free text fields might support this idea; however, this option might be abused, as users might refrain from using standards.
  • An OMM core (block) might support a very small set of basic information plus a free text description (cf. Dublin Core). Reliable technical information should be stored in specialized blocks.
  • A size limitation for such core block information should be indicated in order to avoid abuse.
  • Keywords should be selected with respect to existing standards; values are human-oriented.
• ACTION
  • An overview of all standardized blocks with their particular metadata (MUST, MAY) is required.

Ralph Barthel: Storing Events

• With respect to the OMM’s product lifecycle orientation, a basic question is how an event stream could be stored across the boundaries of changing ownerships and processes.
• A state-of-the art discussion focuses CEE, which illustrates various aspects of event logging, up to recommendations of which events should be logged.
• Several approaches could be employed. The decision may depend on the number of events generated – or on relevance:
  • A log entry should be an individual block; this enables its listing in the ToC and defines a fixed structure for timestamps.
  • There might be a standardized block for events.
  • Users might create blocks with arbitrary event lists; these might be visible in the ToC.
  • A block might reference externally stored event lists – which is recommended for high-resolution data.
• Information (a block) has to be recognizable as an event or event list via metadata.
  • Special events, such as an integrity violation, could be marked explicitly (metadata), stored with documentation in an individual block (and thus appear in the ToC), where a reference to a block with more details (events) is provided.
  • Event lists may be stored arbitrarily in blocks; blocks should be marked as event container. These blocks may have assigned additional metadata, such as capacity limitations and interest flags (“should be continued”). See also the CEE recommendations on domain-specific event logging.
• ACTION
  • A standardized “event” block should be defined.
  • A standardized “event list” block should be defined
  • A limited set of messaging types (integrity violation) should be provided as well as metadata of a standardized event list block.
• Future discussion
  • Event hierarchies
  • A discussion of how CEE compares to the OMM block model (block as event) might be of interest.

Sven Horn: Data Links on the OMM

• Information stored in an OMM may be linked with other information sources – within the same OMM (block references), with other OMMs, and with other external structures.
• For external structures, references might be, for instance, URLs, EPC Object Name Service (ONS), ID@URI [Wikipedia], File Ids in a structured or unstructured peer-to-peer network (WWAI). The latter (structured) approach has strong relationships to the one employed within the SmartProducts project.
• Concerning references between OMMs
  • Hierarchies of OMMs might be beneficial to support navigation – e.g., to imply (physical) part relationships in contrast to virtual data links. Interaction issue: Example “plane” - how can a user access the whole construct’s OMM, how can a user access a particular part in front of his or her? Alternatively, filtering a set of memories could be employed.
  • This is supported explicitly by a standardized structure block (SemProM approach).
  • A whole OMM could become stored as a block (thus establishing a hierarchy). In SemProM, this approach was employed in a scenario where a device part with RFID-based OMM is integrated into a device in a way making future direct access impossible.
• Identifiers should enable linking between whole OMMs and blocks.
  • For coding such references, a combination of primary id and block id should be employed. However, this requires a resolution of the primary id.
  • A type indicates how the content can actually be reached (routing).
  • This might be simplified by a particular API.
• For storing such references in an OMM, several approaches exist.
  • A standardized structure/link block is used to store links. The actual link is stored in the content block. Metadata describe content as usual; in addition, a particular metadata serves as “flag” indicating that the block should not be parsed as usual, but as link.
  • A disadvantage of this approach is that significant memory space might be consumed by metadata. Therefore, in addition an alternative approach is provided: a (single) link block carrying sets of links.
• ACTION
  • A standardized “link” block has to be defined.
  • A standardized “set of links” block has to be defined.
  • The relationship between a structure block and a link block requires a deeper analysis.

TOP 3 OMM Architectures

Markus Miche: A Classification Scheme for OMM Implementations

• The guest speaker presents a schema for classifying implementations of an object memory.
• This schema (once finalized) aims at supporting the application potential and infrastructure-independence of the OMM.
• In its current form, it compiles technical approaches employed in SemProM, SmartProducts, and Tales of Things.
• The OMM members are invited to comment and contribute to this effort.
• Ultimate goal is an inclusion in the XG's final report and a conference or journal publication.

Daniel Schreiber: Modeling Active Behavior

• Within the project SmartProducts, the product itself carries the application – an extension of the SemProM Access Layer model. Therefore, active behavior is modeled within a SmartProduct’s memory.
• ACTION
  • Active behavior of product vs. activity in the environment, e.g., production parameters – difference is code vs. parameter? This might be addressed by a standardized block with specific metadata. Here, further discussion is required.
• Future discussion
  • Active components of a SmartItem in an OMM

Top 4 Topics not or little addressed so far

Sven Horn: Access Rights Management

• Access rights should be handled on the block level. The overall memory and all blocks’ metadata sections should always be readable in order to support open access and ToC creation. Protected blocks may be encrypted.
• Via metadata, it should be indicated if a block is encrypted. Candidate is “mime-type”.
• Applications may decide to protect whole memories via encryption. This is not explicitly supported by the OMM.
• ACTION
  • Metadata for access rights and encryption method have to be defined.
• Future discussion
  • The decision concerning public availability of metadata might require a revision once the full set of metadata is known.

Sven Horn: Access Logs

• Access logs could be of particular use for product lifecycle applications – e.g., in order to improve the quality of content of future revisions of some product. Furthermore, access frequency or relevance information might be required for (external) optimization strategies.
• However, it is unclear how such a log could be created and maintained – in particular if passive hardware components are employed and the user is not willing to extend the log.
• DECISION
  • Explicit support for access logging is excluded from the OMM.

Boris Brandherm: Using the Memory

• Information documented in an OM can be exploited to improve the OM – e.g., by sorting content of binary representations, or by increasing the quality of future products. Since enforcement of an access log is questionable, an alternative strategy is that applications may mark some block as useful.
• Furthermore, ways could be of interest, which help users to derive that some particular information is needed – and motivate him or her to contribute that information. This relates to the modeling of information needs within an OMM (see Active Behavior).
• ACTION
  • Metadata should be identified, which would support such actions. Examples include “rating”, “issues”, etcpp. However, no standardized blocks are foreseen.

Off-Agenda

• ACTION
  • A metadata flag “dynamic” should indicate that some block’ content might change – e.g., if a block summarizes the current status of an object.
• Future discussion
  • How can an XML-based OMM be made persistent? An XML database might be an appropriate approach, but this requires further research.

Top 5 Next Steps

• The ACTION items will be assigned to partners in the next phone conference.
• Date & time of this phone conference: To be determined by email.