Media Annotations Working Group Teleconference -- 09 Sep 2010

<raphael> trackbot, start telecon

<trackbot> Date: 09 September 2010

<daniel> http://www.w3.org/2010/POI/wiki/Draft_Charter

<raphael> scribe: Werner

<scribe> scribenick: wbailer

ontology doc LC-2404

<scribe> meeting: MAWG F2F (day 2)

comments by ivan herman

unclear to see how definitions translate to rdf

veronique: we will have examples in the ontology doc

raphael: core properties and values are defined, domain is media resource

veronique: we had an example with description as domain

raphael: domain of properties is not defined in the doc
... the rdf tf has defined classes for the domain of the properties
... is this the correct approach? this is the question behind ivans comment
... if it always media resource, write in the spec
... independent of specific representation language

chris: define domain, and reply that there will be the rdf version in the next version of the doc

raphael: update notation to clarify definition of properties
... for properties that have both datatype and object, owl full is needed, how is that modelled by rdf tf

veronique: the task force just chose object properties

chris: sent a comment to support both, rdf tf did not agree

veronique: was intended to an rdf implementation, but not the authoritative one

raphael: is rdf representation of definition is complex, we need to consider the definition
... type of identifier seems to come from a controlled vocabulary

chris: should we add more examples to the ontology doc

raphael: when we expect a controlled vocabulary, we should make this clear (without requiring a specific controlled vocabulary)

veronique: we should add for all these properties a sentence saying it is recommended to use a controlled vocabulary

raphael: rename type attribute of identifier, as it might be confusing

chris: in the api def it's called value and type of value - there is a difference in naming between the documents
... same for title
... changed based on comments on the api

raphael: isn't the type of the identifier obvious from the value?

chris: there is a reference to fragments uc 4.4, that states mention different identifiers

raphael: these are all uris

if identifiers are encoded as uris, the type is clear from the start of the uri

resolution: drop type attribute of ma:identifier as it is not required for identifiers that must be URIs

<scribe> ACTION: chris to make updates to api document related to dropping type attribute of identifier [recorded in http://www.w3.org/2010/09/09-mediaann-minutes.html#action01]

<trackbot> Created ACTION-290 - Make updates to api document related to dropping type attribute of identifier [on Chris Poppe - due 2010-09-16].

raphael: require use of bcp47 for ma:language

veronique: should be best practice

raphael: that argument holds for many things, for language this could be enforced

veronique andchris

veronique to work with chris and raphael to update the properties of the ontology doc

for ma:language bcp47 is recommended practice

comment from ivan concerning ma:location

chris: add example, refer to rdf in appendix

raphael: add examples, and that coordinate system string is from controlled vocabulary
... examples: take real world place with coordinates, and mythological place with string

veronique: use of controlled vocabulary is recommended for coordinate system

<scribe> ACTION: thierry to put agreed version of ontology to url pointed to by namespace [recorded in http://www.w3.org/2010/09/09-mediaann-minutes.html#action02]

<trackbot> Created ACTION-291 - Put agreed version of ontology to url pointed to by namespace [on Thierry Michel - due 2010-09-16].

comment on missing appendix:

raphael: appendix will be added, will go for another lc

<scribe> ACTION: thierry to draft response to ivan [recorded in http://www.w3.org/2010/09/09-mediaann-minutes.html#action03]

<trackbot> Created ACTION-292 - Draft response to ivan [on Thierry Michel - due 2010-09-16].

raphael: about title, what is type? replace it by role?

chris: not sure about renaming to role

raphael: type is likely to come from a controlled vocabulary
... date property is generic, but it is still called createdate

we do not want to support any kind of date, but creation/publication related date (up to release/first broadcast)

raphael: again recommend use of controlled vocabulary
... be more precise in the prose about creator / contributor: creator as primary agent related to creation, contributor as secondary

back to title: rename type attribute to role?

vero: we cannot use role if we use it already in a different way
... clarify the ones that are used, or ask on the mailing list about other options

<scribe> ACTION: veronique to check together with other table editors option for clarifying type/role attributes [recorded in http://www.w3.org/2010/09/09-mediaann-minutes.html#action04]

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

LC comments on API document

LC-2419

editorial: shouldn't there be plural "media resource_s_" in the title?

thierry: no formal issue to change the title

we will change to plural in both docs, maybe also in uc

<scribe> ACTION: chris to chanage title to plural in api doc [recorded in http://www.w3.org/2010/09/09-mediaann-minutes.html#action05]

<trackbot> Created ACTION-295 - Chanage title to plural in api doc [on Chris Poppe - due 2010-09-16].

<scribe> ACTION: wonsuk to change title to plural in ontology doc [recorded in http://www.w3.org/2010/09/09-mediaann-minutes.html#action06]

<trackbot> Created ACTION-296 - Change title to plural in ontology doc [on WonSuk Lee - due 2010-09-16].

editorial: thereby ... approved
... formats in scope are stored ... approved
... in the browser ... approved, (there -> their)
... api has # of interfaces ... approved

implementation should support interfaces: change to must?

change to: must implement these interfaces

comment on example ... HTML5 by making the HTMLMediaElement inherit from the MediaResource interface, not an example, but a MUST?

chris: difficult, example assumes changes to HTML5 spec
... can't be required without agreement with HTML5 group

thierry: problem is also that HTML5 is to a final rec

raphael: we should get review from HTML5 group

wonsuk: agrees to get review, concerned of time frame to get review

raphael: it's a question of negotation

thierry: requested review from HTML WG

<tmichel> Last Call review http://lists.w3.org/Archives/Public/public-media-annotation/2010Jun/0050.html

thierry asked also for scheduling of review

<tmichel> http://lists.w3.org/Archives/Public/public-media-annotation/2010Jun/0023.html

scribe: got no response

raphael: propose to send mail again to all chairs

chris: propose to drop the example

raphael: is there another way of doing the same in HTML5?

chris: what is needed to get an object that implements the interface, HTMLMediaElement is just one way of doing this, there are other ways

raphael: would you consider being a media reosurce something else?

chris: could be added as a separate object in HTML5

raphael: a binding between HTML5 and MAWG is needed

resolution: ask HTML5 for their response on this issue

<scribe> ACTION: thierry to send mail to HTML WG chairs [recorded in http://www.w3.org/2010/09/09-mediaann-minutes.html#action07]

<trackbot> Created ACTION-297 - Send mail to HTML WG chairs [on Thierry Michel - due 2010-09-16].

raphael: this is a topic for hcg telecon

parameters optional in webIDL: mark as optional instead of using OPTIONAL keyword in prose

chris: optional keywords are present in the webidl code

comment on general getProperty

chris: metadata is not necessarily loaded, this is up to the implementation

<raphael_> nick raphael

<wonsuk> Geolocation API: http://www.w3.org/TR/geolocation-API/

woksuk: geolocation uses asynchrounous api

<wonsuk> http://www.w3.org/TR/geolocation-API/

chris: should not be a big problem to change to this pattern, callbacks would get MAObjects

we could support both asynchronous and synchronous mode of using the API

chris: to check in webidl spec if overloading is possible (to have same name for synchronous and asynchronous variants of the functions)

resolution: we will add asynchronous variants of the functions to the api

substantial: getdiagnosis is not thread safe

http://www.w3.org/2006/02/lc-comments-tracker/42786/WD-mediaont-api-1.0-20100608/

[lunch break]

<daniel> Group Photo: http://www.w3.org/2008/WebVideo/Annotations/wiki/File:MAWG-Nice-201009.JPG

<vero> scribenick vero

<vero> Follow-up of the discussion on the LC comments 2419 for API document

<vero> current issue discussed: getDiagnosis doesn't seem thread safe...

<vero> Werner: the problem only occurs only if the API works synchronously

<vero> Chris: I can check out in the WebIDL if it is possible to pass an ma:Object reference as an argument in a method

<vero> ... so that it can be modified in the method

<vero> ... then we can return the status code instead of an ma:Object

<vero> ... that would prevent the need of the getDiagnosis method

<vero> Chris: if status is OK, it means that the process ran correctly but no value was found

<vero> ... probably needs to be clarified in the API document

<vero> Joakim: pasting an example code in the WG notes related to the LC comment 2419 on the API document

<vero> Next point in LC comment 2419

<vero> "I suggest exposing the properties directly on the object..."

<vero> Werner: is inherited from the single getProperty method that we agreed on

<vero> ... we do not want to duplicate the method for all the properties

<vero> ... the suggestion from Robin works with the assumption that you want to retrieve all the values for the properties

<vero> Chris: the discussed method gives back the properties that have a value

<vero> ... I do not mind its removal

<vero> Werner: what would be the alternative to querying for the values of all the properties?

<vero> ... Dough and Silvia also wanted one function with a list of values returned

<vero> Chris: the function is implemented for the ease of the implementers

<vero> Werner: the name is misleading, maybe the re would be less confusion by replacing it

<vero> Chris: the main reason for the getProperty function is that when you request even for one property, there might be several responses due to language etc

<vero> ...

<vero> and this is not easily representable as a property directly linked to an object

<vero> ... this is why we have one method returning a list of objects

<vero> Werner: we have been asked to simplify the use of the API and provide a single getProperty method

<vero> Chris: we keep the getPropertyNamesWithValues but will change the naming to a more appropriate one

<vero> Next point of the LC comment 2419 on the API document

<vero> Chris: the media object is the annotation attached to media resource

<vero> ... so media annotation is indeed better

<vero> Next point "simpler to replace getSOurceFormatWithValues with..."

<vero> Werner: same as the answer to the above, the point about the getPropertyNamesWithValues method

<vero> Chris: the function is meant to get the information of the provenance of an annotation

<vero> Werner: it is interesting mostly in the case of multiple annotations, to decide on how to handle it

<vero> Chris: so we decide to keep the method, and we add an example with EXIF that demonstrates its usefulness

<vero> Chris: actually... it's more t check out whether an annotation of a certain format is available (ex: if there is an exif annotation for a given resource)

<vero> Chris: can also get the information and process it otherwise...

<vero> ... provides simply an easier way of filtering

<vero> ... but we do not have a good use case for justifying it

<vero> The group agrees for dropping the method

<vero> At least the people presents at F2F agree to the dropping of the abovementioned method

<vero> Next point of the LC comment 2419 on the API document, about status codes

<vero> Werner/Chris: we can make the unsupported format a status quote

<vero> Werner: the description of the selectMAresource should be improved, made more precise

<vero> Werner: yes, the function is there to load an other resource and external metadata

<vero> ... and yes there will be an asynchronous version of this function

<vero> ... the return type will be changed to return a status code

<vero> Chris: we will look into creating a constructor for the media resource interface

<vero> ... which would avoid the selectMAmedia method

<vero> Next point of the LC comment 2419 on the API document "language interface is meant to be inherited..."

<vero> Chris: agree

<vero> Next point of the LC comment 2419 on the API document "unclear 'plain text' is for unstructuredValue..."

<vero> Chris: it is for the values that have no clear type; binary values are converted to a string, XML elements are parsed and their textual value returned

<vero> Next point of the LC comment 2419 on the API document "what is the type of sourceFormat"

<vero> Rapahel: it's DOMstring...

<vero> Werner: the comment is about the syntax

<vero> ...

<vero> ... in mediaFragment it's a URI, but WebIDL's spec is quite fuzzy

<vero> Raphael: so the API document has to be changed and the required information has to be added

<vero> Next point of the LC comment 2419 on the API document "why is there a value field on identifier if it's holding a URI..."

<vero> CHris: we'll remove the URI from ma:interfaceobject, because sometimes you don't have a URI (for the heigth or width for example)

<vero> ... was inherited from older version/implementation of the API

<vero> Next point of the LC comment 2419 on the API document

<vero> "usage ss a service are not precise enough and not normative enough..."

<vero> Chris: ask Felix for the rationale behind it

<vero> Werner: we have the same in our implementation, but there is no WebIDL binding for that, so WebIDL is not enough for defining it

<vero> ... maybe we can present the section as an example

<vero> Werner: useful as an example for a webservice implementation, but it should not be normative

<vero> Chris: someone contacts WebIDL to stay that we are looking into standardising web services and we are wondering in what direction things are going with WebIDL

<vero> ACTION: Joakim to contact WebIDL for requesting information about the planned direction for the webservices [recorded in http://www.w3.org/2010/09/09-mediaann-minutes.html#action08]

<trackbot> Created ACTION-298 - Contact WebIDL for requesting information about the planned direction for the webservices [on Joakim Söderberg - due 2010-09-16].

<vero> Next point of the LC comment 2419 on the API document "counter-intuitive.."

<vero> Werner/Chris: it is the same type of comment as before, on the "unique method for get lists of properties", same answer

<vero> Next point of the LC comment 2419 on the API document

<vero> "suggested terms should not be in the API document"

<vero> Werner: we should fix the naming of the properties and attributes

<vero> Chris/Raphael will go through the API+Ontology document to check out for consistency

<vero> Chris: I will indeed remove the suggested terms from the API document, and will put them in the Ontology document

<vero> Next point of the LC comment 2419 on the API document "DAte in the interface name"

<vero> Chris: will change the interface to create a Date

<vero> ACTION: Chris to change the API interface about Date [recorded in http://www.w3.org/2010/09/09-mediaann-minutes.html#action09]

<trackbot> Created ACTION-299 - Change the API interface about Date [on Chris Poppe - due 2010-09-16].

<vero> Werner: typo in the example

<vero> Next point of the LC comment 2419 on the API document "Location interface coordination with Geolocation WG"

<ChrisP> http://dev.w3.org/geo/api/spec-source.html#position

<vero> Werner: can the interface be aligned?

<vero> Raphael: problem is for the locations that are not on Earth

<vero> Werner: we culd have either their coordinate system or a URI, but they require accuracy specification, which we don't have

<vero> Chris: we have floats, they have double

<vero> Raphael: dont change anything, but state that you cover more than locations on Earth

<vero> Chris: we cover more

<vero> Raphael: can we change the value to double, then we can copy the value

<vero> Raphael: the Geolocation WG is not fixed yet, still in LC, we should contact them to ask for the optionality of the accuracy element. This way we could use their interface

<vero> ACTION: Joakim to contact the Geolocation WG and see if they'd be OK to make the accuracy optional [recorded in http://www.w3.org/2010/09/09-mediaann-minutes.html#action10]

<trackbot> Created ACTION-300 - Contact the Geolocation WG and see if they'd be OK to make the accuracy optional [on Joakim Söderberg - due 2010-09-16].

<vero> Chris: they have a fixed geolocation system, that would solve the problem for us too

<vero> Next point of the LC comment 2419 on the API document "In Relation"

<vero> Chris: changed that

<vero> Next point of the LC comment 2419 on the API document "easier to read if interface atributes..."

<vero> Chris: I'll add a link to the corresponding properties in the Ontology document

<vero> Next point of the LC comment 2419 on the API document "FrameSize preferred value and example"

<vero> Chris: it's a dot value, European/US notation clash, it's not a float

<vero> ... will do the editing work

<vero> Next point of the LC comment 2419 on the API document "compression"

<vero> Chris: related to the way it is defined in the ontology document

<vero> Joakim: compression type is used

<vero> Chris: this is a question for the ontology document, will be dealt with when updating the ontology document

<vero> ACTION: Chris to check out the compression property of the Ontology document [recorded in http://www.w3.org/2010/09/09-mediaann-minutes.html#action11]

<trackbot> Created ACTION-301 - Check out the compression property of the Ontology document [on Chris Poppe - due 2010-09-16].

<vero> Werner: recommended to use controlled vocabulary, like extended MIME type

<vero> Next point of the LC comment 2419 on the API document "samplingRate"

<vero> Werner/Chris: change to capital R, and other property names to be consistent with the naming convention

<vero> ACTION: Chris to check out the consistency in the property names in the Ontology document's table [recorded in http://www.w3.org/2010/09/09-mediaann-minutes.html#action12]

<trackbot> Created ACTION-302 - Check out the consistency in the property names in the Ontology document's table [on Chris Poppe - due 2010-09-16].

<vero> Next point of the LC comment 2419 on the API document "relationship of section 5 to HTTP is unclear"

<vero> Next point of the LC comment 2419 on the API document "privacy issues, section 7"

<vero> Werner: if someone publishes metadata on the Web, it can be accessed

<vero> Werner: we do not implement the tool that extracts this info from the image, we use other tools that do that

<vero> Next point of the LC comment 2419 on the API document "integration with Media Capture"

<vero> ACTION: Joakim to inform the Media Capture WG about our LC document [recorded in http://www.w3.org/2010/09/09-mediaann-minutes.html#action13]

<trackbot> Created ACTION-303 - Inform the Media Capture WG about our LC document [on Joakim Söderberg - due 2010-09-16].

<scribe> scribenick: wbailer

LC-2395

sampling rate as only audio param?

<daniel> I understand Robin's comment. I would propose to drop the "usage as a service" sections. We don't have time to discuss the details of the "usage as a service" sections. It was a kind of ad hoc proposal, copying the "normal" API calls

<daniel> [2010-09-09 오후 10:55:27] Felix Sasaki: So I would not contact WebIDL for requesting information about the planned direction for the webservices, but reply to Robin that I agree with his comment, and drop the "usage as a service" sections. That's of course my personal opinion. Just my two sents

chris: same answer as for ontology doc

concerning quality parameter: cf answer in ontology doc

explain about "no exceptions"

omission of speex and vp8: same as for ontology doc

<scribe> ACTION: thierry to draft answer for lc-2395 [recorded in http://www.w3.org/2010/09/09-mediaann-minutes.html#action14]

<trackbot> Created ACTION-304 - Draft answer for lc-2395 [on Thierry Michel - due 2010-09-16].

LC-2406

thierry: invite doug to join telecon and discuss these issues

<scribe> ACTION: joakim to invite doug to telecon to discuss his lc comments [recorded in http://www.w3.org/2010/09/09-mediaann-minutes.html#action15]

<trackbot> Created ACTION-305 - Invite doug to telecon to discuss his lc comments [on Joakim Söderberg - due 2010-09-16].

chris: explicitly state that we support several metadata sources

<scribe> ACTION: chris to add paragraph to section 2 about support for several metadata sources [recorded in http://www.w3.org/2010/09/09-mediaann-minutes.html#action16]

<trackbot> Created ACTION-306 - Add paragraph to section 2 about support for several metadata sources [on Chris Poppe - due 2010-09-16].

wonsuk: doug reviewed version from march, and not the lc version

joakim to inform doug about current version

LC-2410

<scribe> ACTION: chris to fix description of parameters in getoriginaldata [recorded in http://www.w3.org/2010/09/09-mediaann-minutes.html#action17]

<trackbot> Created ACTION-307 - Fix description of parameters in getoriginaldata [on Chris Poppe - due 2010-09-16].

LC-2394

<scribe> ACTION: chris to take care of editorial issues in this comment [recorded in http://www.w3.org/2010/09/09-mediaann-minutes.html#action18]

<trackbot> Created ACTION-308 - Take care of editorial issues in this comment [on Chris Poppe - due 2010-09-16].

the api -> this api: approved

mocp: add explanation and reference

Does "Media Ontology" here refer to the same thing as MOCP earlier?

chris: yes, it's the same thing

clarify in abstract

lies on -> is

drop underlying: approved

to support -> of supporting: approved

drop the sentence "This document is being published with the aspiration to gather wide feedback on the yet available API design."

improve markup of section as normative/informative (eg.section 2 api doc)

<scribe> ACTION: thierry to improve markup of nomative/informative, probably with specific class to visualise [recorded in http://www.w3.org/2010/09/09-mediaann-minutes.html#action19]

<trackbot> Created ACTION-309 - Improve markup of nomative/informative, probably with specific class to visualise [on Thierry Michel - due 2010-09-16].

add figure title for figure in sec. 1, in the first sentence add reference to Fig. x

drop the "the" after "includes" and add an "and" before "possibly": approved

change "of" to "to" approved

<Dong-Young> http://dev.w3.org/2009/dap/contacts/#security-and-privacy-considerations

raphael: ask commenter to provide a proposal for handling security

change "by" to "with": approved

At the back-end of the web service -> in the implementation of the web service

full stop after "database, movie store) "

With the help of such a service thee user agent could retrieve ...

replace "as" with "than": approved

rewrite alt text of figure

<scribe> ACTION: werner to add hyphens in Java-Script in the figure [recorded in http://www.w3.org/2010/09/09-mediaann-minutes.html#action20]

<trackbot> Created ACTION-310 - Add hyphens in Java-Script in the figure [on Werner Bailer - due 2010-09-16].

In both scenarios, the access to the metadata properties needs the following stack of components: drop "the" before access

An implementation of the mappings from a specific source format to the properties of the media ontology -> change media ontology to proper noun

change "on" to "with" and "working" to "applied": approved

it is assumed that there is at least -> one needs at least

change "exists" to "consists": already taken care of

scribe: specific operation: getProperty. approved

change "to iterate" to "iteration": approved

Lastly, methods are available -> Methods are available

in 3.1 offers -> ... provides a number of operations to access the metadata ...

change "on" to "of": approved

It seems like you're invading the HTML WG's namespace.... : issue of ongoing discussion

getProperty is singular, it shouldn't be returning an array. : we keep it, the method does not return multiple properties but multiple values of one property

change name getProperty to getMediaProperty to avoid conflics with DOM

getPropertyNamesWithValues -> renamed to Having vlaues

getSourceFormatsWithValues has been dropped

getDiagnosis has been dropped

getOriginalData will be renamed to getOriginalMetadata

operation is the conventional name in WebIDL

Change "to retrieve" to "retrieval of" (globally) - we dropped getDiagnosis

And splitting a return value ... : it's no longer split, with function returning a status code; exception are not used due to objections brought forward in comments to earlier drafts

Requesting "title" returns : add quotation mark

replace "to refine" with "refining" and add a period to this "sentence": approved

Only if the metadata is available in the specified language, the values are returned. ---> Values for the metadata will only be returned if it is available in the specified language

You have a space inside the quotes around " UMID" which seems odd. approved

the earlier request seemed to be for 'title', not 'Title' ...: approved

Why is this a string instead of a url type? there is no URI type in WebIDL

Shouldn't organization be creative commons and the "link" property be to the license? example is outdated, will use new examples provided by PLING

behaviour -> behavior

system specific information: approved

Enlarged is odd. Later versions of this document may include additional status codes or other changes. approved

should be "OK" approved

this is really unhelpful. - obsolete when removing getDiagnosis

layout issues: random indentation, random trailing whitespace

layout issues: approved

ask timeless for his real name, and add to acknowledgements

Members of the Working Group are: is there twice

fix special characters in European names

- DRAFT -

Media Annotations Working Group Teleconference

09 Sep 2010

Attendees

Contents

ontology doc LC-2404

LC comments on API document

LC-2419

LC-2395

LC-2406

LC-2410

LC-2394

Summary of Action Items

Scribe.perl diagnostic output