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

I can think of cases for both scenarios:

- A client requests the metadata document and processes it locally corresponds to scenario 1.
- A service/system could request it and put it into a repository or temporary storage, process it, and possibly make the results available on the web again, that would be scenario 2.

Best regards,
Werner

> -----Original Message-----
> From: Evain, Jean-Pierre [mailto:evain@ebu.ch]
> Sent: Donnerstag, 18. Februar 2010 13:31
> To: Bailer, Werner; public-media-annotation@w3.org
> Subject: RE: ACTION-211: text on client/server implementation of API
> 
> Dear Werner,
> 
> The background is just that for instance EBU Eurovision can publish
> some NewsML-g2 snippets on one of our pages for the purpose of the
> test, which would be accessible through simple http requests. But it
> seems that this is covered by scenario 2?
> 
> Best regards,
> 
> Jean-Pierre
> 
> -----Original Message-----
> From: Bailer, Werner [mailto:werner.bailer@joanneum.at]
> Sent: jeudi, 18. février 2010 13:25
> To: Evain, Jean-Pierre; public-media-annotation@w3.org
> Subject: 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).
> 
> -----------------------------------------
> **************************************************
> This email and any files transmitted with it
> are confidential and intended solely for the
> use of the individual or entity to whom they
> are addressed.
> If you have received this email in error,
> please notify the system manager.
> This footnote also confirms that this email
> message has been swept by the mailgateway
> **************************************************

Received on Thursday, 18 February 2010 12:34:52 UTC