2011-06-22-Protocol

2011-06-22 Protocol

Participants and Scribe

Alexander Kröner (scribe) Barbara Schennerlein Daniel Schreiber Ralph Barthel

TOP 1 Organizational issues

• RUNNING ACTION (DFKI) XG and beyond: The activity chairs have to be contacted.
  • Request is on the way
• Additional members desired
  • Requests still open
  • Meeting with RAN as an "advertising" opportunity
• Discussion: W3C "Community" and "Business Groups"
  • The XG might be transformed into a community or business group (to be verified)

TOP 2 Review of open action points

• AK: Siemens agreed in performing these tasks; first feedback during next phone conference
  • ACTION (Siemens) ToC: A formal XML definition of the ToC is required.
  • ACTION (Siemens) Block Meta Data: This vocabulary needs to be identified on the basis of work from SemProM.
  • ACTION (Siemens) Standardized blocks: An overview of all standardized blocks with their particular metadata (MUST, MAY) is required.
  • ACTION (Siemens) Data Links on the OMM: The relationship between a structure block and a link block requires a deeper analysis.

• DONE ACTION (TU/D) Lifecycle-oriented blocks: Proposal for maintenance block for further discussion Proposal
  • The members agree on the importance of such an element.
  • ACTION (SAP, Siemens): Validation of the lifecycle values - current proposal is from SmartProducts, there is a slightly different proposal from SemProM, other value sets might be established in formal business process descriptions.

• DONE ACTION (TU/D) Modeling Active Behavior: A standardized block and/or metadata for indicating executable content Proposal
  • The members discuss the question of how to store descriptive information about the producer and/or production process (as complement to procedures). Example is data indicating that the procedure is compliant to fair trade. Such data may be stored seperately in another block, e.g., containing a certificate. Currently, it is unclear if particular metadata are required for that purpose.
  • ACTION (TU/D, UCL) The existing use case descriptions (e.g., Provenance) needed to be validated on top of the running metadata efforts.
  • The "sensing" element as such is justified. However, the nature and complexity of referred content might be out of scope for the OMM. Therefore, such content might have to be stored in another block.
  • Another element might be needed in order to indicate which hard- or software component will be able to process the block content. For procedures alone, this might be achievable via the content mimetype. However, this approach might not be suited for configuring devices (see, for instance Decentralized Production Control).
  • ACTION (TU/D) An update of the example is needed.

• DONE ACTION (UCL) Storing events: Standardized blocks of type “event” end “event list” should be defined. A limited set of messaging types (integrity violation) should be provided as well as metadata of a standardized event list block Proposal
  • The Common Events Logging vocabulary is still in discussion. Use cases currently in focus are oriented towards logging software behavior, and are characterized by complex parameter sets. It might be interesting to contact this group in order to discuss an OMM profile for Common Event Logging.
  • ACTION (DFKI) Contact this group once OMM event model is robust.
  • Applications of a "value" field are discussed. (Editor's note: this might not be required if a single event is a regular block, as suggested during the F-2-F meeting).
  • The members dicide that external event sets should make use of the data link proposal.
  • ACTION (UCL) Adapt the external link set example according to the data link proposal.

• DONE ACTION (SAP) Data Links on the OMM: Standardized blocks of type “link” and “set of links” have to be defined Proposal
  • Basically, a link block is a regular block - but the presence of "linkType" indicates that...
    • ...data described in the metadata are actually stored externally, and...
    • ...the block data segment is carrying the link details.

• DONE ACTION (SAP) Access Rights Management: Metadata for access rights and encryption method have to be defined Proposal

• DFKI: Action still pending
  • ACTION (DFKI) Using the Memory: Metadata should be identified, which would support interaction with the memory. A metadata flag “dynamic” should indicate that some block’ content might change.

• ACTION (All): Verify MAY / MUST status of metadata in standardized blocks.

SUMMARY

Next Telco:

• July 8, 2011, 10:00