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

+1 to the text and the new diagramm, both are great.

Best,

Felix

2010/2/18 Bailer, Werner <werner.bailer@joanneum.at>

> 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
> > _____________________________
> >
>
>