OMM Block Header Draft

Proposal: OMM Block Header

(Author: DFKI)

This article proposes a block header structure with meta data for each information block. Several tags are inherited from the SemProM Metaformat (V1.0). The header contains the following information:

"blockID"

An unique id of this block; used for referencing omm data blocks; TODO: define format

"blockType" (from SemProM)

Determines the block data structure; some blocks are predefined with common data such as the following blocks (derived vom SemProM Core, IDs, Structure and Custom Blocks): OMM_CORE, OMM_IDS, OMM_STRUCTURE. OMM_CUSTOM indicates all undefined blocks.

"contentType" (from SemProM)

Indicates the encoding of the block data; given by MIME-type (e.g. "application/xml"); an additional schema definition can be declared with the optional "schema" attribute

"created" and "modified" (from SemProM)

Creator and last modifier of this block as pair of timestamp (here: ISO8601) and actor ID. The ID type was defined in SemProM (DUNS, GLN, E-Mail or OpenID)

"blockContentDescription"

Contains descriptive information about this block; key-value-pairs / tag list; 3 different annotation styles:

ontology-based concepts [concept-list] (1a)

e.g. "http://domain.org/other_ontology/def.owl#ManufacturerData"; concept "ManufacturerData" from ontology def.owl

predefined ontology-based concepts [concept-list] (1b)

given by OMM standard. Predefined ontologies:

• phase.owl
• verticalMarket.owl
• userRole.owl
• importance.owl
• language.owl

based on SemProM meta tags.

free text attributes [tag-list] (2)

e.g. "content", "ingredients", "manufacturer"

hierarchical text attributes [tag hierarchy / tag-list] (3)

e.g. tag "warranty.shelf_life" can be interpreted as concept "shelf_life <subclass of> warranty" or just as tag list "warranty" and "shelf_life"

Samples

Block containing manufacturer data, such as content and shelf life information

<block id="_BLOCK_123_"> <!-- necessary for referencing specific blocks (e.g. from event log) -->
  <blockMeta>
    <blockType>OMM_CUSTOM</blockType> <!-- see SemProM block meta -->
    <contentType schema="http://s.de/schema.xsd">application/xml</contentType> <!-- see SemProM block meta -->
    <created> <!-- see SemProM block meta -->
      <timestamp>2011-01-30T18:30:00+02:00</timestamp>
      <creator type="duns">19-550-5177</creator>
    </created>
    <modified> <!-- see SemProM block meta -->
      <timestamp>2011-01-30T18:35:00+02:00</timestamp>
      <modifier type="email">user@w3c.org</modifier>
    </modified>
    <blockContentDescription>

      <!-- (1a) semantic attributes (e.g. based on ontologies) -->
      <tag type="ontology" value="http://domain.org/other_ontology/def.owl#ManufacturerData" />
			
      <!-- (1b) predefined semantic attributes based on SemProM block meta (each ontology only once) -->
      <tag type="ontology" value="http://omm.org/ontologies/v1/phase.owl#Production" />
      <tag type="ontology" value="http://omm.org/ontologies/v1/verticalMarket.owl#Food" />
      <tag type="ontology" value="http://omm.org/ontologies/v1/userRole.owl#GeneralUser" />
      <tag type="ontology" value="http://omm.org/ontologies/v1/importance.owl#Medium" />
      <tag type="ontology" value="http://omm.org/ontologies/v1/language.owl#German" />
			
      <!-- (2) undefined cleartext attributes -->
      <tag type="text" value="content" />
      <tag type="text" value="ingredients" />
      <tag type="text" value="manufacturer" />			

      <!-- (3) hierarchical arranged attributes (identical to cleartext but with additional semantic) -->
      <tag type="text" value="warranty">
        <tag type="text" value="shelf_life" /> <!-- // warranty.shelf_life ('shelf_life' is a subclass of 'warranty') -->
      </tag>
      <tag type="text" value="norms">
        <tag type="text" value="din">
          <tag type="text" value="e12" > <!-- // norms.din.e12 ('e12' is a subclass of 'din' is a subclass of 'norms') -->
        </tag>
      </tag>
			
    </blockContentDescription>
  </blockMeta>
  <blockData>(...)</blockData>
</block>

Block containing sensor value (temperature reading)

<block id="_BLOCK_456_">
  <blockMeta>
    <blockType>OMM_CUSTOM</blockType>
    <contentType>application/xml</contentType>
    <created>
      <timestamp>2011-01-30T18:30:00+02:00</timestamp>
      <creator type="duns">19-550-5177</creator>
    </created>
    <modified>
      <timestamp>2011-01-30T18:35:00+02:00</timestamp>
      <modifier type="email">user@w3c.org</modifier>
    </modified>
    <blockContentDescription>
      <tag type="ontology" value="http://domain.org/other_ontology/def.owl#TemperatureValue" />
      <tag type="ontology" value="http://omm.org/ontologies/v1/phase.owl#Logistics" />
      <tag type="ontology" value="http://omm.org/ontologies/v1/verticalMarket.owl#Food" />
      <tag type="ontology" value="http://omm.org/ontologies/v1/userRole.owl#GeneralUser" />
      <tag type="ontology" value="http://omm.org/ontologies/v1/importance.owl#Medium" />
      <tag type="text" value="sensor">
        <tag type="text" value="temperature" />
      </tag>
    </blockContentDescription>
  </blockMeta>
  <blockData>(...)</blockData>
</block>

Block containing product documentation as pdf

<block id="_BLOCK_000_">
  <blockMeta>
    <blockType>OMM_CUSTOM</blockType>
    <contentType>application/pdf</contentType>
    <created>
      <timestamp>2011-01-30T18:30:00+02:00</timestamp>
      <creator type="duns">19-550-5177</creator>
    </created>
    <modified>
      <timestamp>2011-01-30T18:35:00+02:00</timestamp>
      <modifier type="email">user@w3c.org</modifier>
    </modified>
    <blockContentDescription>
      <tag type="ontology" value="http://domain.org/other_ontology/def.owl#ProductDocumentation" />
      <tag type="ontology" value="http://omm.org/ontologies/v1/phase.owl#Usage" />
      <tag type="ontology" value="http://omm.org/ontologies/v1/verticalMarket.owl#Entertainment" />
      <tag type="ontology" value="http://omm.org/ontologies/v1/userRole.owl#GeneralUser" />
      <tag type="ontology" value="http://omm.org/ontologies/v1/importance.owl#Lowest" />
      <tag type="ontology" value="http://omm.org/ontologies/v1/language.owl#German" />
      <tag type="text" value="documentation" />
      <tag type="text" value="manual" />
      <tag type="text" value="help" />			
    </blockContentDescription>
  </blockMeta>
  <blockData>(...)</blockData>
</block>

Block containing predefined core block (from SemProM); block content is well known -> only importance and language specified / no additional tags necessary

<block id="_BLOCK_789_">
  <blockMeta>
    <blockType>OMM_CORE</blockType>
    <contentType>application/xml</contentType>
    <created>
      <timestamp>2011-01-30T18:30:00+02:00</timestamp>
      <creator type="duns">19-550-5177</creator>
    </created>
    <modified>
      <timestamp>2011-01-30T18:35:00+02:00</timestamp>
      <modifier type="email">user@w3c.org</modifier>
    </modified>
    <blockContentDescription>
      <tag type="ontology" value="http://omm.org/ontologies/v1/importance.owl#Highest" />
      <tag type="ontology" value="http://omm.org/ontologies/v1/language.owl#English" />
    </blockContentDescription>
  </blockMeta>
  <blockData>(...)</blockData>
</block>

Revision History

• Update 04/15/11:
  • Removed tag "blockID" and moved to attribute "id" to "block"-tag
  • Add addtional "schema" attribute to "contentType"-tag

Discussion

With respect to the XML format following changes might improve the structural organization and machine-readability of the XML file:

• (Seißler) Elements "blockID", "blockType" (and maybe contentType) should be changed into an attribute of the <blockMeta/> Element since they have the charakter of an parameter. The other sub-elements of <blockMeta> represent the 'content' of the block.
  • (Haupert) Element "blockID" moved to attribute "id" of "block" element (Version: 04/15/11)

• (Seißler) Element "blockType" -> Change into an attribute <blockMeta type="OMM_CORE".../> since this information has the charakter of an attribute. The possible values (e.g. "OMM_CORE") should be defined as an Enumeration.
  • (Haupert) Enumeration for "blockType" is reasonable; but type does not change the strucutre of the "blockMeta"-element so should left unchanged

Standardized Blocks

So-called standardized blocks have a particular function related to the OMM. Here, standardization means that particular metadata have to be defined in order to provide basic support for the respective (object memory) function across any OMM-based service. The content of such blocks is usually not standardized; however, in selected cases the OMM XG will express recommendations (e.g., for encoding event lists).

Structure Block

Event

A standardised block for events that can occur within the block the event is referring to or within an eventList element. An event should be logged with the following elements:

• A timestamp in ISO 8601 format
• The action that is logged. Actions are application specific.
• A description that describes the event that is logged.
• An indicator if an event is critical and why it is critical (criticality). Requires the definition of different levels. E.g. 0 (uncritical), 1 (warning), 2 (integrity violation) etc. There should be a meanism to "flag" critical events in the TOC that are considered critical. The TOC could for this purpose include references to the id's of the event block that contain this information.
• An element that identifies the source of an event (eventSource)
• A location of an external log (externalLog) if applicable (optional). This is for events that are logged at higher frequencies.
• Location - the longitude and latitude where the event took place (optional).
• A reference to the user, account or machine that triggered the event (eventUser).

Example

 <event id="e78527">
   <action>Read</action>
   <eventSource>128.113.45.212</eventSource>
   <description>The label of the object was scanned by a reader.</description>
   <timestamp>2011-06-15 17:04:29.82Z</timestamp>
   <criticality>0</criticality>
   <eventUser>David</eventUser>
   <location>
       <latitude>58.84392</latitude>
       <longitude>5.872811</longitude>
   </location>
 </event>

Event List

As alternative to attaching single events as children to block elements in an OM, a collection of events can also be represented as separate block in the OM. Each event event in the list has an additional element that references the block id the events are associated with. This is necessary as an OM can consist of multiple blocks.

Example

 <events>
     <event id="e75557">
         <action>Logon</action>
         ....
         ...
         <eventTarget>_BLOCK_123_</eventTarget>
     </event>
     ...
 </events>

The events could also contain references to one or more external log(s) containing lists of events (eventLists). The external event log could either contain logs of the same action (e.g. many readings from a temperature sensor) or it can contain different actions such as logins, sensor readings etc. in the data so that the format of the <event> block is required. The references to external event logs use the same syntax as data link blocks (see below).

 <events>
     <eventList>
         <dataLink>
             <linkText>User events</linkText>
             <linkType>URL</linkType>
             <linkContent>http://example.org/events/eventLog/</linkContent>
         </dataLink>
         <dataLink>
             <linkText>Readings of the temperature sensor</linkText>
             <linkType>URL</linkType>
             <linkContent>http://example.net/events/temperature/</linkContent>
         </dataLink>
     </eventList>
 </events>

Link

WARNING: This block is obsolet -> now included in XML specification!

Block containing product documentation as pdf (linked, linktype is URL)

occurence of <linkType> indicates that the block data is a link

<block id="_BLOCK_001_">
  <blockMeta>
    <blockType>OMM_CUSTOM</blockType>
    <contentType>application/pdf</contentType>
    <created>
      <timestamp>2011-01-30T18:30:00+02:00</timestamp>
      <creator type="duns">19-550-5177</creator>
    </created>
    <modified>
      <timestamp>2011-01-30T18:35:00+02:00</timestamp>
      <modifier type="email">user@w3c.org</modifier>
    </modified>
    <blockContentDescription>
      <tag type="text" value="manual" />
      <tag type="text" value="help" />			
    </blockContentDescription>
    <linkType>URL</linkType>
  </blockMeta>
  <blockData>http://www.sap.com/blockmanual.pdf</blockData>
</block>

linktype is KTorrent P2P System Link

<block id="_BLOCK_002_">
  <blockMeta>
    ...
    <linkType>KTorrent</linkType>
  </blockMeta>
  <blockData>urn:btih:QHQXPYWMACKDWKP47RRVIV7VOURXFE5Q</blockData>
</block>

Link Set

Block containing several product documentations (linked, several linktypes)

<block id="_BLOCK_003_">
  <blockMeta>
    <blockType>OMM_CUSTOM</blockType>
    <created>
      <timestamp>2011-01-30T18:30:00+02:00</timestamp>
      <creator type="duns">19-550-5177</creator>
    </created>
    <modified>
      <timestamp>2011-01-30T18:35:00+02:00</timestamp>
      <modifier type="email">user@w3c.org</modifier>
    </modified>
    <blockContentDescription>
      <tag type="text" value="manual" />
    </blockContentDescription>
    <linkType>LinkSet</linkType>
  </blockMeta>
  <blockData>
     <dataLink>
        <linkText>Manual File</linkText>
        <linkType>URL</linkType>
        <linkContent>http://www.sap.com/blockmanual.pdf</linkContent>
     </dataLink>
     <dataLink>
        <linkText>Help File</linkText>
        <linkType>URL</linkType>
        <linkContent>http://www.sap.com/blockhelp.pdf</linkContent>
     </dataLink>
     <dataLink>
        <linkText>Image</linkText>
        <linkType>KTorrent</linkType>
        <linkContent>urn:btih:QHQXPYWMACKDWKP47RRVIV7VOURXFE5P</linkContent>
     </dataLink>
  </blockData>
</block>

Procedures

In addition to passive and history knowledge, an object memory may contain active knowledge. Active knowledge is intended to be executed by human operators dealing with the object, or interpreted as code in an information system, as opposed to being only read and treated as data by information systems. Thereby, the interpretation can happen inside the object itself, in which case it must comprise an embedded computer, or by an external system.

Standardized blockMeta elements for this block:

• Lifecycle: the step in the lifecycle where this procedure should be used. Can be any of the following: DEVELOPMENT, PRODUCTION, SHIPPING, USE, MAINTENANCE, REPAIR, DISPOSAL. These values can be discussed, they basically reflect the SmartProducts model of Life-cycle. *Note* this means that the current life-cycle state is a object global variable, maybe along the ID of the whole DOM?.
• Interactive: whether this procedure can be automated or needs manual intervention. This may be hard to decide in advance, a procedure may become manual, if the right sensors are not available.
• Interpreter: The type of interpreter that should be able to interprete the block content (could also be called language). Useful for further specifying code for languages that do not have a MIME type specified.

Removed, because it is too complicated to include such information in the meta data:

• Sensing: Sensor / context data that is needed for the process (required=”TRUE”) or optional but can be used by the process (required=”FALSE”). Inside this element should be a list of observation elements, specifying the type of information that is used.

Example

 
<block id="_BLOCK_123_">
  <blockMeta>
    <blockType>OMM_PROCEDURE</blockType> 
    <created>
      <timestamp>2011-01-30T18:30:00+02:00</timestamp>
      <creator type="email">ds1019@tk.informatik.tu-darmstadt.de</creator>
    </created>
   <blockContentDescription>
      <tag type="ontology" value="http://omm.org/ontologies/v1/phase.owl#Production" />
      <tag type="ontology" value="http://omm.org/ontologies/v1/verticalMarket.owl#Manufacturing" />
      <tag type="ontology" value="http://omm.org/ontologies/v1/userRole.owl#Expert" />
      <tag type="ontology" value="http://omm.org/ontologies/v1/importance.owl#Medium" />
      <tag type="text" value="The decalcification procedure for the coffee machine" />
    </blockContentDescription>
    <contentType>text/javascript</contentType> 
    <interpreter>ECMAScript</interpreter> 
    <lifecycle step="MAINTENANCE" />
          <!-- this is relevant during maintenance phase -->
    <interactive value="1" />
          <!-- the process requires manual intervention -->
  </blockMeta>
  <blockData>
   <!-- description of the procedure in ECMA Script (maybe good for W3C, but not implemented), or XPDL (here we can contribute), or any language, from binary to LISP.-->
   output.document.write("<html>hello user, this is a message from a procedure! P1 currently senses:" + getElementReferencedBySensor("P1").getValue() + "</html>");
   </blockData>
</block>

 
<block id="_BLOCK_123_">
  <blockMeta>
    <blockType>OMM_PROCEDURE</blockType> 
    <created>
      <timestamp>2011-01-30T18:30:00+02:00</timestamp>
      <creator type="email">ds1019@tk.informatik.tu-darmstadt.de</creator>
    </created>
   <blockContentDescription>
      <tag type="ontology" value="http://omm.org/ontologies/v1/phase.owl#Production" />
      <tag type="ontology" value="http://omm.org/ontologies/v1/verticalMarket.owl#Manufacturing" />
      <tag type="ontology" value="http://omm.org/ontologies/v1/userRole.owl#Expert" />
      <tag type="ontology" value="http://omm.org/ontologies/v1/importance.owl#Medium" />
      <tag type="text" value="The production parameter for the smart drug case" />
    </blockContentDescription>
    <contentType>text/plain</contentType> 
    <interpreter>Step 7</interpreter> 
    <lifecycle step="PRODUCTION" />
          <!-- this is relevant during production phase -->
    <interactive value="0" />
          <!-- the process requires no manual intervention -->
  </blockMeta>
  <blockData>
      L 1.234000e+002
      T MD 20   
      L 10
      T M 34   
   </blockData>
</block>

Atteributes/Property/Dictionary

Some of the most common use case for DOMs can be solved by storing key-value pairs. These can be read from and written to the DOM. Examples include parameters for a manufacturing process.

Since the data of this block is fully specified by the OMM, no additional meta information, such as content-type or schema is needed. It is however possible to specify the purpose of the block in domain terms, using the contentDescription tag. The URI of the contentDescrition tag can further be used as an ID to check, if a OMM at hand contains information that is used by a module or process step.

 
<block id="_BLOCK_123_">
  <blockMeta>
    <blockType>OMM_PROPERTY_LIST</blockType> 
    <created>
      <timestamp>2011-01-30T18:30:00+02:00</timestamp>
      <creator type="email">ds1019@tk.informatik.tu-darmstadt.de</creator>
    </created>
   <blockContentDescription>
      <tag type="ontology" value="http://omm.org/ontologies/v1/enterprise_processes.owl#ManufacturingProcess2Step4" />
   </blockContentDescription>
  </blockMeta>
  <blockData>
      <attribute key="numberPillA">1</attribute>
      <attribute key="numberPillB">1</attribute>
      <attribute key="numberPillC">1</attribute>
  </blockData>
</block>

Encryption

WARNING: This block is obsolet -> now included in XML specification!

Block with encrypted content for types see e.g. Apache Types

<block id="_BLOCK_004_">
  <blockMeta>
    ...
    <encryptionType>DES_CBC_MD5</encryptionType>
  </blockMeta>
  <blockData>UZKBVC3IZESGMKJVD5GFIZFZI6OZGFQHQXPYWMACKDWKP47RRVIV7VOURXFE5Q</blockData>
</block>

Object Lifecycle: Best Practice

In discussion: The OMM XG could express recommendations for metadata sets of information crucial for describing stages
typical for the lifecycle of a product / object.

Maintenance

(see also: Use Cases)