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
_____________________________

Received on Thursday, 18 February 2010 11:03:11 UTC