Re: OMM-XG and Device APIs-WG

Hi Robin,

I've just wondered if you found the time to have a closer look on Jens' 
examples, or if you require additional information about the OMM. We 
just talked about putting information about this OMM aspect in the OMM 
XGR, so your feedback would be of special interest for us.

Best regards,
   Alexander Kröner

Am 19.09.2011 13:27, schrieb Jens Haupert:
> Hi Robin,
>
> in behalf of Alexander, I send you a javascript sample code that 
> demonstrates how a web application may access the OMM (coffee machine 
> or airplane) for the scenarios you mentioned. Please keep in mind, 
> that these snippets do not represent working code and should be 
> considered just as an example.
>
> If you have some further technical questions, feel free to contact me.
>
> Best regards,
> Jens Haupert
>
>
>
> Am 14.09.2011 16:02, schrieb Alexander Kröner:
>> 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 Tuesday, 27 September 2011 07:41:53 UTC