Re: OMM-XG and Device APIs-WG

Hi Robin,

Am 14.09.2011 11:39, schrieb Robin Berjon:
> Hi Alexander,
>
> sorry for taking a little while to respond, but OMM is a new topic to me (and I suspect to most in the DAP WG) and some reading and pondering is necessary to get to grips with it.
understood, thanks for taking the time to crawl this bunch of documents!
> On Sep 12, 2011, at 13:35 , Alexander Kröner wrote:
>> * Would it make sense to (re-)design the OM API according to guidelines of the Device API WG, and -potentially- to integrate the OM API?
> I looked around in the wiki and the specification but I could find no mention of an API. Given that, it is difficult to answer that question :)
Sorry, I should have mentioned that. The API is part of the software 
environment where the OMM will be deployed. Developing the API was not 
in the focus of the OMM XG (...which was the model the API is working on).

To wrap up our internal history:

1) Several projects developed the Digital Product Memory (DPM). One of 
these projects was SemProM; there, the DPM's structure and encoding were 
developed - therefore, these are sometimes denoted as "SemProM Format". 
The DPM comprises a data model and an API for interacting with this 
data. The API was implemented using C# (documentation, for a mobile 
scenario) and Java (for a server-based backend called "object memory 
server").

2) The OMM XG used this structure as starting point; main purpose was to 
discuss it with other groups with a similar technical approach, but 
different applications.

3) The OMM was revised; it's now the successor of the DPM.

What we would like to do now is to adapt our software infrastructure to 
the new model. We don't expect significant difficulties during that 
process, since DPM and OMM are structurally similar, and the API as such 
is not very complicated. Once that step is accomplished, we would like 
to publish the API as well.

Since we observed a potential relationship to Device APIs' activities, 
we thought it might be interesting to take during that revision feedback 
from that group into account.

> As of today we have no written-down guidelines, but given an API we'd be happy to review it and provide feedback.
That's a great offer, the OMM XG would be very interested in such 
feedback! If you like, then you may have a look at the DPM API.

http://www.dfki.de/~kroener/omm/dpm_api_1_0.zip

The documentation is for C# and quite primitive (quick and dirty export 
from a Windows help file), but hopefully you get at least some idea. The 
most relevant part is a bit hidden:

On the left, click on the right "SemanticProductMemory Namespace"
On the right, follow "IBlockMemory"

In advance, you might want to look at these more high-level documents in 
order to get an idea of the model:

http://www.dfki.de/~kroener/omm/20110126_SemProM_OMM_en.pdf
http://www.w3.org/2005/Incubator/omm/wiki/SemProM_Container_Format_Version_1.0

Furthermore, my colleague Jens Haupert would be happy to answer any 
questions concerning details of the API and model.

jens.haupert@dfki.de

>> An object memory is meant to...
>> ....support collecting data about a physical artifact (at the artifact and/or in the Web)
>> ....and to improve this way documentation and communication in artifact-driven processes.
>>
>> As such, the XG members consider an object memory to be a feature of a "smart" artifact. Communication with the OMM is supported by an API (OM API, reference implementation in progress). Thus, a particular question to members of the Device APIs Working Group would be if the XG's assumption valid at all, and how to approach this topic.
> What would be most helpful to us in order to review OMM would be examples of arbitrary web pages accessing the OM API in Javascript and doing something useful with it (it doesn't have to be fully-functional, but it helps if it should give a concrete idea). For instance, assuming I've understood the use cases:
(...answered just out of my head, probably not perfectly addressed)
>      • It's Saturday morning and I'm in a dreadful mood because my coffee machine is giving me terrible coffee. I know I need to descale it but I don't know how and the manual is in one of the boxes labeled "Misc." that have been sitting unopened on the top shelf of my cupboard since I moved here five years ago. So I grab my phone and... ?
...touch the coffee machine with the mobile device, and retrieve (e.g., 
via NFC or QR) a URL pointing to a web site where digital information 
concerning this artifact is collected. Querying the metadata 
"maintenance", "manual" returns a hyperlink pointing to the digital copy 
on the manual.

Variations would include a lookup in a personal artifact memory hosted 
on the mobile device (notes matching this artifact), or actually 
retrieving a short description from a (complex) chip attached to the 
machine.
>      • I'm an engineer looking for microfissures on an aeroplane and I see a pattern emerge that might indicate improper screwing. I want to review the torque applied to the seventeen screws in this area over the past three years of maintenance. So I grab my tablet and... ?
... access via WiFi the aeroplane's memory. A hierarchy of hyperlinked 
Object Memories allows you to dive into the airplanes physical structure 
until you reach the screws' memories. The timeline-oriented memory 
allows you to go back in time up to the construction phase. There, a 
smart screwdriver stored the torque of the screws.

The latter example is surprisingly close to a use case of the project 
Smart Products (the UC is not explicitly listed at the OMM site) and 
reflects some real world applications (unfortunately, still without 
Object Memory ;-)). Could be realized in a different way if the screws 
would carry an identifier, I just wanted to point out the topics 
"timeline" and "linking object memories".

We are currently consolidating our use case descriptions for the XG 
report. What might be interesting for you as well is the TalesOfThings 
application. This community-oriented scenario is quite different from 
the more industry-oriented goals of the DPM group.

http://talesofthings.com/


> Some high-level explanations would help as well. What is an artefact-driven process (I only found http://en.wikipedia.org/wiki/Artifact-centric_business_process_model that seemed to be related)?
It is to some extent, however, I meant processes focused on physical 
artifacts (the Wiki spec is more general).
> The wiki speaks of "DPM" a lot, notably in the use cases, but I have no idea what that is which makes the use cases quite cryptic to read.
Sorry for that :-) We try to do better in the final report. Most likely 
you browsed the draft use cases section, which was set up in the early 
beginning of the XG. Thus, the wording reflects to some extent the 
(quite different) background of the respective authors. DPM=Digital 
Product Memory.
> I am sorry if this reply is less helpful than you would likely have wished, but I'm trying to establish the means for communication :) I'm mostly a web hacker with just enough Javascript to be dangerous and no useful computer science, business processing modelling, etc. background. That description applies in varying degrees to other participants. So the more concrete and Javascriptish, the more likely we are to understand and provide useful feedback!
>
Ok - and thanks a lot for the interesting reply! I hope my email 
answered at least some of your questions.

Best regards,
   Alexander Kröner



-- 

Dr. Alexander Kröner --------- Intelligent User Interfaces Lab
DFKI GmbH  Campus D3 2  Stuhlsatzenhausweg 3 66123 Saarbrücken

Phone  +49.681.85775.5395
Fax    +49 681.85775.5021

http://www.dfki.de/~kroener/
--------------------------------------------------------------
Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
Firmensitz: Trippstadter Strasse 122, D-67663 Kaiserslautern

Geschaeftsfuehrung:
Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster (Vorsitzender)
Dr. Walter Olthoff

Vorsitzender des Aufsichtsrats:
Prof. Dr. h.c. Hans A. Aukes

Amtsgericht Kaiserslautern, HRB 2313
--------------------------------------------------------------

Received on Wednesday, 14 September 2011 14:03:28 UTC