MAWG F2F -- 06 Nov 2009

<Chris> Werner: use case of providing rich metadata for specific application is not relevant to us

<Chris> ... we are assuming that metadata is needed for different providers

<Chris> Veronique: we want to combine metadata of different formats

<Chris> Jean-Pierre: it is not clear what will be done with our api and ontology

<Chris> Joakim: to conclude previous discussions

<Chris> ... let's get some feedback from browser implementors on the API document

<Chris> Florian: would be good, in the meantime we can continue the work

<Chris> ... and more clearly specify the use case of the API

<Chris> ACTION: joakim to contact browser implementors to review the API document [recorded in http://www.w3.org/2009/11/06-mediaann-minutes.html#action01]

<trackbot> Created ACTION-176 - Contact browser implementors to review the API document [on Joakim Söderberg - due 2009-11-13].

<Chris> Joakim: should we include images that more clearly explain an application using our API and ontology

<Chris> ... one case with API in web browser

<Chris> ... second one with API in back-end

<Chris> Werner: I can do that

<Chris> ACTION: werner to make schematic pictures of sample applications [recorded in http://www.w3.org/2009/11/06-mediaann-minutes.html#action02]

<trackbot> Created ACTION-177 - Make schematic pictures of sample applications [on Werner Bailer - due 2009-11-13].

<Chris> Sylvia Pfeiffer: don't really have problems with the API document on first glance

<Chris> Erik: should we use one function or several functions for each property?

<Chris> ... Doug favored the first approach

<Chris> Silvia: one function seems better

<Daniel> To Werner: http://www.w3.org/2008/WebVideo/Annotations/wiki/Image:API-Drawing-TPAC09.JPG

<Chris> Jean-Pierre: how will you access the metadata?

<Chris> ... for example metadata included in picture

<Chris> werner: this is a implementation issue

<Chris> Joakim: Doug suggested metadata on metadata

<Chris> ... like creation date of metadata

<Chris> ... should we include this?

<Chris> Florian: maybe we should postpone this issue for now

<Chris> ACTION: chris to add this open issue to the wiki [recorded in http://www.w3.org/2009/11/06-mediaann-minutes.html#action03]

<trackbot> Created ACTION-178 - Add this open issue to the wiki [on Chris Poppe - due 2009-11-13].

<Chris> Joakim: how will we proceed with the subtypes?

<Chris> Jean-Pierre: do we need to go into subtypes?

<Chris> ACTION: chris to add the subtype problem as an open issue to the wiki [recorded in http://www.w3.org/2009/11/06-mediaann-minutes.html#action04]

<trackbot> Created ACTION-179 - Add the subtype problem as an open issue to the wiki [on Chris Poppe - due 2009-11-13].

<Chris> ACTION: chris to add the metadata on metadata issue to the open issues on the wiki [recorded in http://www.w3.org/2009/11/06-mediaann-minutes.html#action05]

<trackbot> Created ACTION-180 - Add the metadata on metadata issue to the open issues on the wiki [on Chris Poppe - due 2009-11-13].

<Chris> Joakim: ontology issues are done

<Chris> ... next topic API open issues

<Chris> http://www.w3.org/2008/WebVideo/Annotations/wiki/API_Open_Issues

return types

<Chris> werner: some of the issues are related to what we discussed on the ontologies

<Chris> ... it's not clear why some of the properties return no collection

<Chris> ... the languages should result in a collection being returned

<Chris> ... the same for the filtering according to the F2F 4 discussions

<Chris> ... the strawman API summarizes the filters

<Chris> http://www.w3.org/2008/WebVideo/Annotations/wiki/Strawman_API_design_and_notes

<Chris> werner: if a property returns a list of values we should use plural notation

<Chris> ... but if only one method will be used for these properties the issues need to be reviewed

<Chris> the Strawman API is currently only partially represented in the API document

<Chris> Joakim: are there other API's that can be used as an example?

<Chris> Werner: are there other API's that have the same issue?

<Chris> Joakim: OpenSocial

<Chris> maybe we should await feedback from the browser implementors before changing the API document

<Chris> to avoid redundant work

<Chris> werner: we should ask feedback on the strawman api also

<Chris> +1

<wonsuk> +1

free text vs. formal values

<Chris> werner: should we use strings or URIs?

<Chris> joakim: if we allow both we need to be able to indicate which one is used

<Chris> jean-pierre: a URI could lead to a complex structure

<Chris> this problem occurs if we have only one method or if we have different methods

<Chris> joakim: if we do changes to the API, do we make a new version e.g., api-1.1

<Chris> ... we should add a page on the wiki with decided changes

<Chris> I can extend the DOMString return values to an object which holds a value and a type (denoting if the value is a URI or string)

<Chris> ACTION: chris to add the proposed solution to include URIs and strings to the wiki [recorded in http://www.w3.org/2009/11/06-mediaann-minutes.html#action06]

<trackbot> Created ACTION-181 - Add the proposed solution to include URIs and strings to the wiki [on Chris Poppe - due 2009-11-13].

duration

<Chris> werner: is it safe to return the duration in seconds?

<Chris> ... we should support the ways of specifying time as in the Media Fragments WG

<Chris> how do they do this in Media Fragments WG?

<wbailer> http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#naming-time

<Chris> wonsuk: we can use seconds for the duration

<Chris> +1

<Chris> the media fragments timing can be converted to seconds

<Chris> so the proposed solution is to use seconds

<Chris> ACTION: chris to add the use of seconds to the proposed solutions [recorded in http://www.w3.org/2009/11/06-mediaann-minutes.html#action07]

<trackbot> Created ACTION-182 - Add the use of seconds to the proposed solutions [on Chris Poppe - due 2009-11-13].

representation of dates

<Chris> currently an own object is defined for the date

<Chris> veronique: we could use timex

<Chris> werner: the wiki has been updated on the resolved issues

<vmalais> timex2 document: http://fofoca.mitre.org/

<vmalais> W3C Time ontology: http://www.w3.org/TR/owl-time/

<Chris> joakim: dealt with most of the open issues on the agenda

<Chris> ... tomorrow we should focus on the test suits

<Chris> daniel: can we go through the candidate additional elements

<wonsuk> http://www.w3.org/2009/06/26-mediaann-minutes.html

review requirements document

<Chris> http://www.w3.org/TR/2009/WD-media-annot-reqs-20090604/

<wbailer> requirement 1 can be misunderstood that we support getting metadata in different formats

<wbailer> also the key issue is not about media objects in different formats, but metadata in different formats

<Chris> joakim: who is going to do the updates?

<Chris> ... we should collect the changes

<Chris> ... werner can add the pictures to the requirements document

<Chris> ACTION: wonsuk to update the requirements document based on the proposed updates [recorded in http://www.w3.org/2009/11/06-mediaann-minutes.html#action08]

<trackbot> Created ACTION-183 - Update the requirements document based on the proposed updates [on WonSuk Lee - due 2009-11-13].

<Chris> werner: we should be precise on structured and unstructured

<Chris> joakim: at the point that the document was written we didn't know what we do now

<Chris> werner: we can revise the requirements more in-depth

<Chris> jean-pierre: is there consensus on the answer on the question: why not use DC?

<Chris> http://www.w3.org/2008/WebVideo/Annotations/wiki/Improvements_/_Enhancement_for_a_revision_of_the_%22Ontology_for_Media_Resource_1.0%22_document

<Chris> joakim is reading the answer...

<Chris> joakim: this answer should be formulated in the ontology document

<daniel> http://www.w3.org/2008/WebVideo/Annotations/wiki/Candidate_Additional_Elements

<daniel> last item for today is ontology...

<Chris> joakim: these answers were sent to the mailing list

candidate additional elements

<Chris> http://www.w3.org/2008/WebVideo/Annotations/wiki/Candidate_Additional_Elements

<Chris> joakim: who created this page?

<Chris> werner: me

<Chris> ... we got a request by the PFWG on including some additional elements for accessibility

<Chris> ... the 'relation' property is usefull to link alternate versions

<Chris> silvia: is it possible to get the tracks?

<Chris> werner: yes we have close link with the media fragmentations WG

<Chris> silvia: media queries would be interesting

<Chris> ... David Singer is aware of this

<silvia> http://www.w3.org/TR/css3-mediaqueries/

<Chris> ACTION: david to explain the link, difference or relation of our work with the Media Queries [recorded in http://www.w3.org/2009/11/06-mediaann-minutes.html#action09]

<trackbot> Created ACTION-184 - Explain the link, difference or relation of our work with the Media Queries [on David Singer - due 2009-11-13].

<Chris> werner: it was also requested to include ways to identify resources required to play a resource

<Chris> ... this could be solved using 'relation' property

fictional character

<Chris> the Timed Text WG includes finctional character

<Chris> joakim: let's not touch this semantic hazzard

<Chris> ... yet

<Chris> the 'description' element allows for a textual represenation of the content

media types

<Chris> werner: are there more?

<Chris> silvia: how about SMIL files

<Chris> we should address the notion of containers

<Chris> jean-pierre: a new property could be used for container

<wbailer> Meeting: MAWG F2F

<wbailer> Chair: Joakim

<wbailer> scribe: wbailer

<JF> Minutes: http://www.w3.org/2009/11/01-media-minutes.html

<JF> IRC Loghttp://www.w3.org/2009/11/01-media-irc

<JF> http://www.w3.org/2009/11/01-media-irc

daniel: have not sufficient experience on creating test suite in the group, need advice

veronique: ask felix

<JF> Twitter http://twitter.com/#search?q=h5ma

accessibility of mm

john: organsised workshop together with dsinger
... not official w3c activity, but representants from different groups present
... task force in html5, work on accessibility of mm content
... alternative content needed to support accessibility (e.g. closed captions, subtitling)
... not visibility to majority of users, but available on demand

joakim: why is it called closed caption?

john: open caption always present, closed caption switched on/off
... could be burnt in or overlaid
... need to keep file sizes small, transmit additional content only when needed, and not always in bundle
... "pich & choose", implemented as SMIL file
... MAWG could support this process
... need switching mechanism
... SMIL too complex for baseline functionality needed, actually only a subset is required
... timeline is an issue, what is primary timeline, etc
... one thing that shall be supported is descsriptive audio, 2 audio streams in parallel, need to avoid collissions
... metadata could help to simplify decision making process
... e.g. support asychronous timeline

joakim: domain of metadata is becoming increasingly complex, amount of data is growing
... MAWG niche is to create a framework for mapping different formats to a simplified core set

john: would metadata about the media file and all support files (e.g. time stamp file, caption files) be in scope of MAWG?

joakim: discussed on describing SMIL with silvia yesterday
... we should support describing SMIL file as a media resource
... but not parse into SMIL file

john: david is thinking about using css media queries for querying requirements
... is there overlap between css mq and mawg?

mawg needs to analyse this

joakim: is the prime use case a broadcast or a web scenario?

john: primary use case is web scenarios, viewing video on the web
... e.g. watching personal video on airplane can in fact be implemented as web based media
... commercially most relevant use case is youtube or itunes type of use cases
... links also to internalisation
... youtube allows to upload timestamp file with captions, use google translation to do real time translation
... other example, medical video, doing professional translation, provide translated captions
... libraries have agreed on dublin core for metadata, but is it the right thing to use for media held in libraries?
... search can benefit from textual metadata associated with media, time stamps help to locate precise segments

joakim: is the use case finding versions of media?

john: how do we ensure that assets can be bound to the video, and that media are reusable

joakim: tandberg has a system for closed captions, will check how the handle these issues
... in mawg we have relation element to point to other resources

introducing subtype of language to express spoken language, caption etc would be useful

joakim: at the ws, someone was asking for link to descriptive audio

john: how are annotations bound the media assets?
... one concern is orphan files, ie. video + external is published, someone copies part of video but no additional files for accessibility
... bind annotations and links support stuff to media file

veronique: we can express that things are link, we cannot enforce binding
... we do not create an annotation format
... making bridges between annotation formats

rigo: it's good that mawg bridges annotation formats, but why do you restrict to that
... the things you are bridging come from industry

veronique: not sure, some formats have gone through standardisation process

rigo: they do not care about accessibility, allow third parties to extend mawg profile with accessibility metadata
... do we limit ourselves to the existing and just bridge
... or extend in addition

john: this would be useful for accessibility

joakim: we do not a placeholder for additional data

rigo: ontology could hold additional information

joakim: recommend format to support accessibility

john: make sure that mawg is aware of properties used

rigo: can propose p3p and odrl to add to formats considered by mawg for mapping

relates to comment of pfwg on required media, would need eg to parse smil file

john: SMIL is interesting cadidate, but maybe too complex, solution needs to be very simple
... find balance between essential functionality and add more complex information

veronique: when querying, we could get results from different annotations, we have to decide which we trust more, and what has priority

john: are you dealing with this trust issue?

veronique: will look at these things one basic api is there, which annotator you trust more, not done work on that yet
... felix talked about that to last tpac

<rigo> for rights language: http://www.w3.org/TR/odrl/

joakim: metadata working group is looking for a standardisation body to work with

<Daniel> http://www.metadataworkinggroup.org/

joakim: the mwg has also defined an order in which properties from different formats are returned

rigo: we are working on reputation stuff etc, but it is still far ahead

[john is leaving]

<rigo> http://www.w3.org/TR/P3P11/

<rigo> http://www.w3.org/Policy/pling/

pling

rigo: outcome of EU project prime, ws on policy languages
... issues: link policy information to objects
... things can be identified by URI, how to bind to object, still unsolved
... apis identify objects (similar for mawg, geolocations), points to annotations
... extension we want is in api
... geolocation does not include policy, object provider should know
... in geolocation, web page asks for geolocation, then browser asks for location service
... api defines how to ask for location information
... geolocation decided the page needs to handle policy information

joakim: what is the goal wrt policy

rigo: in geolocation, you e.g. want to give the location information, but not allow to track
... e.g. for media: attach CC license, author information
... there are privacy implications, eg access control personal videos on the web

joakim: where should the policy information be?

rigo: for geolocation use case, policy inf will be supported by dap

<Daniel> Kangchan is taling

kangchan: several level of policy description
... is there any requirement on metadata?

joakim: is there policy on the metadata?

rigo: eg rights on large databases in EU
... eg user generated metadata
... not thought about on policies on metadata levels
... no binding issue if on semantic web
... sees two possible solutions for mawg
... 1) when information is collected in api and bound to media, return policy info to application, application may or may not consider it
... 2) take into account odrl and p3p, reference odrl or p3p information, leave binding to object to odrl to p3p
... problem is how does api know to which media object is related to
... when object is identified, we can describe object, eg including odrl info
... if ma properties point to odrl file, it is defined that odrl file applies
... p3p has a file describing the bindings
... it could be an optional point in the spec: if you want to use policy info, put link to policy file in media file of metadata
... or future version one could store metadata augmented with policy information
... policy languages have their own binding mechanisms
... in this case the context of media resource would create new binding information
... binding is created dynamically

wonsuk: how many formats currently support including policy information?

<scribe> ACTION: rigo to ask pling wg to provide text on including policy information [recorded in http://www.w3.org/2009/11/06-mediaann-minutes.html#action10]

<trackbot> Sorry, couldn't find user - rigo

veronique: send input to mailing list

how much does policy overlap with license?

rigo: see email from renato (sent 2009-10-21 to MAWG chairs)
... generalises license property

joakim: policy subtypes?

rigo: license, policy, access

veronique: would copyright be more appropriate?

rigo: rights is a subclass of policy

veronique: standards for privacy information?

rigo: p3p
... research in primelife on more advanced languages
... copyright and license are redundant
... labeling is not comprehensible
... copyright is a dc style identification, while license describes the use conditions

joakim: please provide references to pling documents to be referenced in mawg documents

<florian> scribeNick: florian

<scribe> scribe: florian

Test Suite

Joakim invited Doug to help us with the test suite

Joakim: this is our first try to describe the test environment
... we want to file media files

Doug: all tests are implemented, but no conformance tests
... neither performance testing
... testing should have any feature in scope, at least one test
... also a mixture of features in one test

Joakim: what is a feature?

Doug: a test should have negative and positive tests
... e.g. in the API a single interface would be a test (or a single value/paramater like title)
... an example of a negative test would be, what happens if an empty paramater occurs
... a combined test could be also if you combine the title property with a filtering
... you should deal in the api, how metadata will be extracted from different sources
... a test should take this into scope

Werner: a very common example for that would be technical metadata (some embedded, some external stored)

Doug: look at youtube videos, you have metadata about the video in the page (e.g. rating) that could be exposed with RDFa, but the actual metadata is in another place, because not embedded in the video
... so you have to find all these sources
... this will lead to the fact to identify scenarios
... in what why you want to test the implementation
... regarding the ontology, talk to e.g. the OWL guys
... a good test would be the mapping between two formats
... a negative test could be to try to map bad XMP data

<Daniel> reference call for implementation: http://www.w3.org/2005/10/Process-20051014/tr.html#cfi

Doug: what would the predictable result

Florian: should we make error handling? predefined error codes?

Doug: yes
... testing format should work with mozilla and microsoft (reftest - reference test interface/platform)
... the idea of reftest is to build primary tests
... reftest is valuable, because it can be run automatically
... you can reproduce the precondition in the test

Reftest: https://developer.mozilla.org/en/Mozilla_automated_testing

<joakim> http://www.w3.org/2008/webapps/ElementTraversal/index.html

Doug: you could also use this for the api
... should be in principle similar to the future MAWG API tests
... but this is not a reftest
... only css uses reftest yet
... but you could start with simple test, like from the link above

Joakim: if somebody wants to implement the spec
... how should we do the reference implementation?

Doug: you have to implement the whole spec
... all things tagged with "must" has to be tested
... the test could be rebuild on each other (e.g. the test for title is at the base the same for creator)
... regarding the API design, browser vendors like the one method idea more than a set of methods
... can provide you a quasi-spec for the api

<joakim> http://dev.w3.org/2006/webapi/MediaObject/publish/

Doug: this is the MAXIM spec
... it is similar to the API spec (getMetadata)
... you have to put a security section in the api doc
... e.g. get a ressource from another domain, privacy concerns could arise

Joakim: like a disclaimer?

Doug: yes
... you are facing three groups of people: implementors, users and guys who want to understand that
... the disclaimer helps people to understand the whole, that the metadata could rise privacy issues
... so an informative disclaimer helps
... the shorter the spec will be, the more people will review

Joakim: we will collect the ideas for the restructered API in a wiki entry

Doug: will provide the information about browser vendors soon

Joakim: after that we will reflect the information of the wiki and the browser vendors into the API doc

Werner: one of the issues we have to deal with is, if the same property comes from different formats
... what we should take and what ordering in the result array

Doug: let the user decide what ordering they want
... you could expose a graph of the metadata
... the objects in the array hold data about what kind of type they are
... so you could deal with structured and unstructered data
... and you can search on it

Joakim: could we define the graph idea in WebIDL?

Doug: perhaps with an array chain and give the author the opportunity to navigate in the chain
... this could be a model, not the structure

Werner: maybe always returning the context is a good idea
... we need to have a simple way to access it in a first way
... the graph should not be part of the api

Doug: context is the most gentel way to deal with it
... context could be e.g. the parent node
... this concept of context could help dealing with the filtering

Werner: Accessing the subtypes directly is a strong argument for the one-method API

Doug: have a look at the selectors api

<wbailer> http://www.w3.org/TR/selectors-api/

<scribe> ACTION: joakim to ask Doug for the alternative implementation/syntx for the API doc [recorded in http://www.w3.org/2009/11/06-mediaann-minutes.html#action11]

<trackbot> Created ACTION-186 - Ask Doug for the alternative implementation/syntx for the API doc [on Joakim Söderberg - due 2009-11-13].

<scribe> ACTION: Chris to create a WebIDL specifiction to the generic GET Method [recorded in http://www.w3.org/2009/11/06-mediaann-minutes.html#action12]

<trackbot> Created ACTION-187 - Create a WebIDL specifiction to the generic GET Method [on Chris Poppe - due 2009-11-13].

The group is back from lunch

Summary of Dougs feedback to the API document

Werner: if people want to work on a graph structure, we could provide getRDF()
... but we must have a formal ontology in that case

<joakim> One Function To Rule them All!

+1 @ Joakim

Wonsuk: we should wait until we get the feedback from the browser vendors

Veronique: oyu could use filtering more easily with this approach

Werner: better for the browser vendors to insert only one method stub in their interfaces
... you can also have an additional layer in front of it

Florian: perhaps make the general description in the spec and in an informal part the set of methods approach as an additional layer

Joakim: the one-method implementation would make us even more generic regarding the possibility to query subproperties

<scribe> ACTION: Joakim to put the "Error Handling" topic into the agenda of the next telecon [recorded in http://www.w3.org/2009/11/06-mediaann-minutes.html#action13]

<trackbot> Created ACTION-188 - Put the "Error Handling" topic into the agenda of the next telecon [on Joakim Söderberg - due 2009-11-13].

Werner: we have to define a subset of subproperties in order to query them
... the set of methods approach can handle queries without defined subproperties

Joakim: should someone work on the subproperties?

<scribe> ACTION: tobias to work on the the subproperties (http://www.w3.org/2008/WebVideo/Annotations/wiki/Sub_Types) [recorded in http://www.w3.org/2009/11/06-mediaann-minutes.html#action14]

<trackbot> Created ACTION-189 - Work on the the subproperties (http://www.w3.org/2008/WebVideo/Annotations/wiki/Sub_Types) [on Tobias Bürger - due 2009-11-13].

Veronique: should we rename the licence property to policy?

Werner: policy is too generic
... no we can add it to the hierarchy
... a policy should be something formal
... copyright is only a descriptive thing

Wonsuk: why are people discussing the namen of properties?
... we should focus on the mapping

Joakim: mapping will be as is, only the name will be changed

Wonsuk: basically we must take into account what subproperty is needed for the mapping

Joakim: Tobias should take care of the subproperties topic

Werner: we can start collecting subproperties at the wiki page

Brainstorming regarding the Test Suite

Joakim: we should make a wiki page

Werner: we should define a set of test data and the correct results/behaviour for tests
... e.g. set of return values, or exceptions
... just like JUnit
... we have to decide what error handling we want to use

Wonsuk: we should define test cases
... do we have to take all metadata formats into scope?

Veronique: no, doug said we should only take 2 or 3 into account

Werner: you can derive enough test cases with 2-3 metadata formats
... we do not make conformance tests

Veronique: we have also to define negative test cases

Joakim: we should have a test for at least the top level at first

Werner: we should do it also for the subproperties
... should define tests that retrieve metadata from more than one source

Veronique: the document should specify, what kind of metadata sourcen (e.g., RDFa) are in scope

Werner: technically it is not more effort extracting RDFa related EXIF
... anything else should be excluded

Florian: we should not forget Dougs hint to build test cases using "broken" metadata

Werner: we should also deal with different types of multimedia data (e.g. MPEG, SMIL)
... what will be a valid response, if you query the bandwith of a SMIL file?!

Joakim: we should choose a particular extraction app

Werner: this is a risk
... but it?s not a conformance test

Wonsuk: shall we provide a report regarding the testing?

Werner: it would be nice, if the test suite could be executed on the server _and_ the client

Joakim: there is no need to extract the metadata of files

Veronique: we should ask the mailing list, what tests we should cover on the basis of dougs examples
... we should write this email now

The group sets up the email

Joakim: shall we set up deadlines now?
... and we have to add the security disclaimer

<scribe> ACTION: daniel to make a first draft for a rights disclaimer and add it to the API doc [recorded in http://www.w3.org/2009/11/06-mediaann-minutes.html#action15]

<trackbot> Sorry, couldn't find user - daniel

<scribe> ACTION: Daniel to make a first draft for a rights disclaimer and add it to the API doc [recorded in http://www.w3.org/2009/11/06-mediaann-minutes.html#action16]

<trackbot> Sorry, couldn't find user - Daniel

<Daniel> ACTION: daniel to make a first draft for a rights disclaimer and add it to the API doc [recorded in http://www.w3.org/2009/11/06-mediaann-minutes.html#action17]

<trackbot> Sorry, couldn't find user - daniel

<Daniel> ACTION: spark3 to make a first draft for a rights disclaimer and add it to the API doc [recorded in http://www.w3.org/2009/11/06-mediaann-minutes.html#action18]

<trackbot> Created ACTION-191 - Make a first draft for a rights disclaimer and add it to the API doc [on Soohong Daniel Park - due 2009-11-13].

Joakim send the Email with the call for Tests to the mailing list.

<Daniel> next f2f is in the last week of Feb 2010 in Seoul, will be finally confirmed later

- DRAFT -

MAWG F2F

06 Nov 2009

Attendees

Contents