Warning:
This wiki has been archived and is now read-only.

Protocol

From Object Memory Modeling Incubator Group Wiki
Jump to: navigation, search

Participants

  • Alexander Kröner [AK], Boris Brandherm [BB], Jens Haupert [JH]
  • Daniel Schreiber [DS]
  • Marc Seißler [MS]
  • Ralph Barthel [RB]
  • Jörg Neidig [JN]
  • Barbara Schennerlein [BS], Sven Horn [SH]

Scribe

BB


TOP 1 Use Cases

Discussion: New additions to the Wiki

[AK]: Before we collect further use cases, we should ask ourselves whether the representation of the use cases is appropriate for our purposes. Do we need further use cases? Are other activities more important? Do members agree in their relevance? Which elements do they contribute, how would they affect the format?

We have use cases in the following domains:

  • Logistics
  • Production
  • Retail / consumer
  • Maintenance
  • Integration of other product information standards


Presentation of the use cases

Logistics
  • [AK]: In the domain logistic a product memory is presented. But an object memory could look differently. For example like the SPDO (Smart Product Description Object) which features a facets-model and is domain oriented. But it is not so suitable for SemProM.


Integrity
  • In the custom block an event list is represented. Question: Are event lists and events still part of the OM?
  • [JN]: There is a new norm for smart sensors. They should all be supported.
  • [DS]: Eventually, the reference to a list should be included in the OM.
  • [MS]: Agrees. References to other approaches should be possible.
  • [AK]: There is a tendency that the concrete modelling of events should be omitted but in exchange there should be a structure which supports/indicates that there is respective data.


Complex Transport
  • Several blocks for the different logistic companies. Question: Do we want to have it like this? In the SPDO logistic is just one big block.
  • Explicit relations between the blocks are not directly to recognize. These relations can be derived by the recorded time.
  • Do we need cross connections between the blocks?
  • Smart Products: different blocks are written. So far it's not considered whether these blocks have to be connected.
  • Tales of Things
    • How do all these pieces fit together?
    • Different event lists
    • How do we handle the cross linking of all the miscellaneous data? Question: Should data / blocks be interconnected?
    • Several blocks facilitate the search. Each user owns his block in which he saves his data.


Maintenance [JN]
  • Product information
  • Keep the data local at the product.
  • Electronic identification plate
  • Information which is provided by the producer
  • Maintenance lists
    • Protection by signatures
    • Tracing of maintenance history
    • Should be kept at the product because external service companies could use different data structures

[AK]:

  • In case of maintenance: OM has references on other OMs -> disassembled part provides information where it has been assembled for how long
  • Request to JN: Can you provide more detailed information for the maintenance use case? JN: Yes, this is okay.
  • Smart Products go in the same direction.
  • Central question: What would we have to define in XML?

[JN]: Existing product description standards have to be overtaken 1:1. If we don’t do so then we have to compete with them.

[BS]: There are rationales for it and against it.

[RB]: Smart Products don’t try to set up compatibilities. We should take the preliminary work.

[AK]: Consensus in the approach. Meta data is an important tool.

We should write the author behind the title of each use case.


Robust Production Processes [BS]
  • OM not only at the products which are produced but also at the machines and tools which produce.
  • For succeeding production processes: who were involved?
  • [AK]: Keep the order at the product. Question: Do we want to save in the OM requirements for the product? For example: Pizza wants to know in general the surrounding temperature.
  • [MS]: by means of the product data processes can be controlled. This is not meant to be dominated by the product but instead more on the design of the production processes.
  • [AK]: MS, can you provide such a use case to emphasize the problem?
  • [AK]: DS, is this still an element of the OM or is this orthogonal to this?
  • [DS]: We don’t do it in Smart Products but it looks reasonable.
  • Access protocols: logging what happens with the OM.
    • When was data accessed, changed or erased? Which data was erased?
    • This logging has to be realized by an API.
  • [RB]: Event lists occur quite often. Is there already a standard available?
  • [AK]: RB, can you start a little research on this topic?
  • [AK]: If we want to have a logging then we would recommend the Format XY.


Localization of objects [BS]
  • [AK]: I can see a relationship with integrity. Smart Products, how do you cope with the Is-Status respectively localization? Our model is on which level, low-level vs. high-level? Which API is needed?
  • [AK]: How do we deal with the requirements which arise from the hardware?
  • [Smart Products]: Data is recorded at the product because there are no memory problems. Use cases would be interesting which shows that the data has to be recorded at the product.


Product Recommendation [BS]
  • [AK]: BS, can you formulate for us the usage history in a use case?


Provenance Information [RB]
  • How do we cope with the case if the object has been destroyed but we still want to access the OM?
  • Cross-sectional issues
    • Data privacy protection
    • Data linkage


  • For the next TelCo: collect further use cases
  • DFKI: Extract the features out of the use cases.


F2F Meeting

4./5. April: Hanover Fair lies in parallel. 23. May: Favorite Meeting at DFKI Saarbrücken, Kaiserslautern is principally possible. AK checks whether Berlin would be possible.