mawg -- 16 Apr 2009

<fsasaki> scribe: tbd

<shepazu> trackbot, start telcon

<trackbot> Meeting: Media Annotations Working Group Teleconference

<trackbot> Date: 16 April 2009

<vrodrgue2> I am vroddon2 in skype

<daniel> felix, can you hear our voices ?

<fsasaki> very hard to hear

<shepazu> XMP also has broad support on deployed devices

<shepazu> like cameras, videocams, etc.

<daniel> canonical processes discussion proposed by Venonique

<daniel> dave is talking about some issues and questions on UC&Req document.

<wbailer> scribe: wbailer

dave: cross site scripting is an security issue for metadata access
... mention that this is an issue, work on solution with other WGs
... issue: are annotations timed or not?
... applys to different type of metadata: content description, rights, etc.
... metadata global to media item might be sufficient to start, but time-dependent metadata needs to be considered

<daniel> yeah, felix, the whether is very nice

<daniel> ..:-)

joakim: what is the media object? is a fragment a media object
... needs to be defined

felix: this is an issue, do we need to solve it? could timed text approach be used for that

dave: time reference should be supported in api

joakim: doesn't media fragments solve that? uri describes fragment
... bring up question in joined section

<fsasaki> felix: media fragments group mechanism might be helpful here

dave: use case "Access via web client to metadata in heterogeneous formats"
... to which collection do the queries refer to?

<vmalais> http://dev.w3.org/cvsweb/~checkout~/2008/video/mediaann/mediaont-req/mediaont-req.html?rev=1.57&content-type=text/html;%20charset=utf-8

dave: specify what goes along the arrows in the diagram in section3

<scribe> ACTION: felix to clarify arrow + descriptions for the diagram in section 3 of UC & req dcouments [recorded in http://www.w3.org/2009/04/16-mediaann-minutes.html#action01]

<trackbot> Created ACTION-101 - Clarify arrow + descriptions for the diagram in section 3 of UC & req dcouments [on Felix Sasaki - due 2009-04-23].

florian: uc 5.4 refers accessing the api from a search engine

joakim: check if attributes mentioned in attributes are covered by properties in mapping table

<scribe> ACTION: veroniqueM to update canonical processes use cases [recorded in http://www.w3.org/2009/04/16-mediaann-minutes.html#action02]

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

<scribe> ACTION: vmalais to update canonical processes use cases [recorded in http://www.w3.org/2009/04/16-mediaann-minutes.html#action03]

<trackbot> Created ACTION-102 - Update canonical processes use cases [on Véronique Malaisé - due 2009-04-23].

<daniel> coffee break

<daniel> and get back to the MXM discussion...

mxm introduction

wonsuk presents short overview of mpeg extensible middleware

http://mxm.wg11.sc29.org/

<daniel> resume the meeting with MXM introduction by Wonsuk

wonsuk believes there is synergy between implementation of generic metadata engine in mxm and mawg

joakim: define basic set of entities and their mappings to different formats
... in future, further formats could be added
... define basic set of entities

veronique: from which formats to take definition of these entities

joakim: entities are internal to ontology
... few, generic entities should be sufficient

jean-pierre: people will map to other formats - what to map to?

florian: a defined reference is necessary
... group and classify properties

jean-pierre: how are entities from different formats related
... define metamodel?

ruben: define minimum set of core terms

jean-pierre: went through this discussion => ebu core
... europeana: reduce to 15 elements, then enriched

veronique: start with core set, xmp also has core set going back to DC + enrichments

ruben: ID3 is good example for basic metadata set

joakim: publish set of general entities, make people think in terms of these entities

dave: we'd all like a metadata system with clear semantics, widely used
... don't know how to get it

veronique: enforcing a format is not possible, mapping is the only option

florian: mapping always means loss of information

victor: mapping using semantic technologies can provide richer mapping than other apporaches
... if set of entities is published in w3c recommendation people might be encouraged to use it

florian: problem is different semantics in enrichment of standards
... build simple core ontology, can be extended to build complex annotation

jean-pierre: kind of combination of dc and mpeg-7 reflects interest of people in wg, but not of interest

<fsasaki> +1 to a simple set of properties

jean-pierre: unthinkable combination
... we have even not agreed on which format to use for describing mappings
... most search engines make search based on brute force

veronique: there are swoogle type of search engines

jean-pierre: even if there's an api for mapping different formats- will it be used

joakim: assemble domain knowledge, not filter it

jean-pierre: work would be simple if all formats would be described already in rdf

joakim: thought that 1:1 mapping of properties makes work easier

veronique: adding entities and their relations would mean defining another ontology

joakim: grouping properties like in xmp

florian: define ontology, provide browsing properties without the need to understand owl

veronique: develop ontology for grouping, avoid define another metadata format

dave: no reason to prefer certain format, define properties and mappings to existing formats
... not really defining a new ontology
... not saying that tags we are mapping to are equivalent

veronique: do people agree to define basic set of terms?

jean-pierre: set of basic terms or superset?

dave: subset of what you reasonable want and expect to get

<fsasaki> +1 to dave

joakim: isn't that just dublinc core?

veronqiue: is this really all we want?

florian: in an image, one wants to annotate content

ruben: doing better and more precise might be understand as just another ontology

felix: what we're doing is developing dc for media
... not bad to refer to dc
... mappings to other formats not availble yet
... lots of mappings available for dc elements in mapping table, getting thinner for other elements
... concern that group is doing too much and progressing too slow
... doing something simple for v1 and more complex for v2 might be a useful approach

daniel: make first basic version, gather feedback and improve based on feedback

daniel reminds of wg charter

jean-pierre: in a simple approach, we define a list of terms (might be some as dc or xmp)
... let's see if we agree on list of terms
... define list of entities and mapping, including mapping dc and xmp to that list

joakim: everyone agrees?

no disagreement

jean-pierre: subclasses could be useful

florian: would increase semantic expressiveness

review of mapping table

joakim: level of conformance of implementations to be defined

jean-pierre: implementation cannot mean change implementations

joakim: have several levels of conformance?

<daniel> implementation volunteering (in this room): Joakim, Wonsuk, Werner

jean-pierre: api for mapping = conformance

joakim: what about proprietary formats of service providers

jean-pierre: format should not be used as data model

joakim: there are specific formats in business domains
... use this in generic deployment environment

jean-pierre: boundaries between delivery channels are disappearing
... don't want to reinvent how to describe broadcast content

dave: if there is a recommendation of comment set, why would broadcasters not use it?

jean-pierre: broadcasters would keep their formats and use mappings

dave: if there's a recommendation for set of properties, they would try to conform (in their formats)

florian: common set of entities is needed for querying across several formats

jean-pierre: content provider would not implement for mapping

veronique: at least not large providers

jean-pierre: we should not reject any particular type of metadata
... for the time being we have a restricted set of formats for which we have defined mappings
... everyone should be able to map their format
... restrictions may come from the way the api is written

veronique: skos might not be sufficient for describing the mappings

ruben: if the internal format is hidden to the user, why standardise the mappings?
... api only is visible

jean-pierre: like dc, this would mean publishing list of terms

florian: why should mapping rules be standardised?

ruben: mapping can be useful, but can be informative

jean-pierre: mapping is mechanism to discover the set of entities
... but mappings need not be normative
... simple list of properties is not incompatible with more complex ontology

felix: simple approach is good
... description of relation to other formats is very valuable
... continue review of mappings

veronique: would api be implementation of mappings?

jean-pierre: is there need for an api?
... if format in which to publish information is defined

felix: api is useful for making mapping testable

joakim: does that require solving data type issue of return values?

felix, dave: not necessary for making testable assertions

<wonsuk> http://www.w3.org/2008/WebVideo/Annotations/

veronique: list of terms, when to define?

joakim: now
... column with names of entities will be added to mapping table
... then review and agree on format reviews

veronique: are mappings one way or bidirectional?

dave: one way only

victor: refine mappings, specify transitivity, conditions under which properties are equivalent, etc
... precising the relationship further
... cardinalities
... priorities in case of several mappings

joakim: refining further would be necessary for supporting setting scenario

dave: setting raises problem of value ranges of different formats

joakim: future version of mapping table with refined semantics

dave: choose terms that can be read from many formats

jean-pierre: there might be terms that are useful but not (yet) widely supported

- DRAFT -

mawg

16 Apr 2009

Attendees

Contents

mxm introduction

review of mapping table

Summary of Action Items

Scribe.perl diagnostic output