RE: ACTION-211: text on client/server implementation of API

Dear Florian, all,

Thanks for your comments. Attached are updated version of the text and the diagram.

Best regards,
Werner

> -----Original Message-----
> From: public-media-annotation-request@w3.org [mailto:public-media-
> annotation-request@w3.org] On Behalf Of Florian Stegmaier
> Sent: Donnerstag, 18. Februar 2010 12:03
> To: public-media-annotation@w3.org
> Subject: ACTION-211: text on client/server implementation of API
> 
> Dear Werner, all,
> 
> Thanks for your efforts! I think the available text summarizes all
> central ideas of a possible API.
> 
> Some minor remarks:
> 
> - from my point of view, the titles of the two scenarios (user agent,
> web service) fit very well. could you sync the diagram with the new
> titles?
> 
> - [...] in the user agent (e.g., a browser) and exposed [...]
> - [...] for a supported set of formats. Therby the accessibility
> (e.g., connection establishment or retrieval) of the metadata sources
> (the media resources as well as the metadata documents) is ensured by
> the user agent.
> - [...] non-UI client, like an agent crawling metadata. However, the
> API could be also accessed from a user agent and used the same way as
> described in scenario 1 by the help of a JavaScript library for
> accessing the web service. [...]
> - [...] by a user agent. In contrast to an integrated component (see
> scenario 1), an implementation of the API in a web service could
> perform more complex mappings on the fly and is more felxible (e.g.,
> adding additional formats).
> 
> Best,
> Florian
> 
> Am 16.02.2010 um 20:48 schrieb Bailer, Werner:
> 
> > Dear all,
> >
> > Please find below a first draft of the text describing the client/
> > server scenarios for the API. It might fit into section 2.1 (design
> > considerations) of the API document.
> >
> > Best regards,
> > Werner
> >
> >
> >
> > We consider two scenarios where the API could be implemented: either
> > in the user agent (scenario 1) or as a web service (scenario 2). The
> > two scenarios are shown in Figure XX.
> >
> > 1. User agent
> >
> > The API is implemented in the user agent and exposed as a JavaScript
> > API (using the WebIDL JavaScript binding). The user agent includes
> > the components for metadata access (possibly extraction) and
> > mappings for a supported set of formats. The metadata sources (the
> > media resource and/or metadata document(s)) must be retrievable and
> > access to them is handled by the user agent.
> >
> > 2. Web service
> >
> > The API is implemented as a Web service.
> > [Editorial note: there is no appropriate WebIDL binding (such as
> > WSDL), thus appropriate formats for method calls (e.g. HTTP query
> > parameters) and return values (XML, Jason) need to be defined]
> > Such an implementation would be typically used by a non-UI client,
> > such as an agent harvesting metadata. However, the API could be also
> > accessed from a user agent, and a JavaScript library for accessing
> > the service could be provided, so that the client-side use could be
> > the same as in scenario 1. At the back-end of the web service, this
> > scenario also allows supporting a media repository (e.g. content
> > provider's archive database, movie store) from which the user agent
> > could directly retrieve metadata sources and which might have a
> > custom metadata format not supported by a user agent. An
> > implementation of the API in a web service could do more complex
> > mappings on the fly as a component integrated in a user agent, and
> > can be more flexible, as additional formats are easier to add.
> >
> > In both scenarios, the access to the metadata properties needs the
> > following stack of components:
> > - An implementation of the API for Media Resource (as defined in
> > this document), which providers the actual getter methods for the
> > properties.
> > - An implementation of the mappings from a specific source format to
> > the properties of the media ontology (as defined in Ontology for
> > Media Resource 1.0).
> > - A format specific API to access the metadata. This is can be an
> > API for accessing a metadata document describing a media resource
> > (e.g. an XML parser and a set of XPath statements) or an extractor
> > the read metadata embedded in the media resource (e.g. a library to
> > read EXIF information from JPEG images). In order to define the
> > context on which the API for Media Resource is working (cf. Section
> > 2.2), it is assumed that there is at least a unidirectional
> > reference from the media resource to the metadata document or vice
> > versa. If this is not the case such a reference needs to be provided
> > by the web application (scenario 1), web service (scenario 2) or
> > media repository (scenario 2).
> 
> _____________________________
> Dipl. Inf. Florian Stegmaier
> Chair of Distributed Information Systems
> University of Passau
> Innstr. 43
> 94032 Passau
> 
> Room 248 ITZ
> Tel.: +49 851 509 3063
> Fax: +49 851 509 3062
> stegmai@dimis.fim.uni-passau.de
> 
> https://www.dimis.fim.uni-passau.de/iris/
> 
> http://www.jpsearch.org
> http://www.mpegqueryformat.org
> _____________________________
>