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

Dear Jean-Pierre,

If I understand correctly you are thinking of a metadata extraction/mapping service, that receives metadata documents or media resources from a client and then uses the metadata? That would mean that the metadata document/media resource is not kept at the server, otherwise I think it would just uploading it and then using the API on the server side as it is already covered by scenario 2. Do you have a use case for such a scenario?

Best regards,
Werner

> -----Original Message-----
> From: Evain, Jean-Pierre [mailto:evain@ebu.ch]
> Sent: Donnerstag, 18. Februar 2010 13:09
> To: Bailer, Werner; public-media-annotation@w3.org
> Subject: RE: ACTION-211: text on client/server implementation of API
> 
> Dear Werner, all,
> 
> I guess there will be another section for the case where the API is on
> the server side and fetches files from the client using e.g.
> xmlHTTPrequests?
> 
> Best regards,
> 
> Jean-Pierre
> 
> -----Original Message-----
> From: public-media-annotation-request@w3.org [mailto:public-media-
> annotation-request@w3.org] On Behalf Of Bailer, Werner
> Sent: mardi, 16. février 2010 20:49
> To: public-media-annotation@w3.org
> Subject: ACTION-211: text on client/server implementation of API
> 
> 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).

Received on Thursday, 18 February 2010 12:25:41 UTC