MAWG F2F 2009-11-05 -- 05 Nov 2009

<wbailer> scribe: wbailer

agenda

joakim: reschedule to have important topics after parallel ac meeting ends

wonsuk: we should discuss update of uc and requirements document

agenda draft at http://www.w3.org/2008/WebVideo/Annotations/wiki/Meeting_Agenda_F2F_5

<Daniel> self-introduction around the table

<Daniel> Jaesung Han who is a new person from Samsung Electronics at this meeting

ontology improvement

veronique: in the joint paper we had different propositions for the ontology
... questions: which option to follow?
... other proposition: represent as event
... event models by raphael troncy et al and at vua
... merged the two
... formal way of describing metadata

chris: why use events?
... why eg for technical properties?

veronique: link technical properties to event (e.g. creation)
... annotation has time dimension, supports versioning

chris: this is metadata about properties and not about resource

veronique: resource is also represented as an event, can be linked
... proposals in paper
... link properties with skos (not desinged for that)
... or more formal, owl equivalent
... do we keep the bag of properties we have now
... or organise in an ontology

joakim: we have a set of core attributes

chris: these attributes are properties

joakim: what do you call the relations between properties?

veronique: property mappings
... in wbailers and wonsuks proposal classes are used for modelling
... alternative could be to represent them as events
... do we go for one or all of these options?
... what is supported in the current apis?

joakim: feedback from outside: where is the ontology? can it be applied to real time media
... we need a primer document

veronique: we need to define the ontology in order to implement the api based
... maybe vote for the different options
... or one api per ontology proposal
... would the apis be still interoperable?

chris: api should be independent from how ontology is modelled

veronique: can it be independent (property vs class)

chris: api will access values of core properties
... mapping is taken care of internally
... for the clients the api should be the same
... for the 4 propositions it's possible to create compatible apis

florian: what's the role of the api spec?

chris: it's a uniform way of accessing a specific set of properties

florian: not much information in api spec then
... actual information is in ontology document
... the two could be merged

chris: what do you expect that the api should do?

florian: two documents should be merged

chris: api should define interface, implementation can be different
... needs to conform to ontology definition
... no matter how the mappings are implemented

florian: give guidelines for implementations

wbailer: our implementations will be available as example

florian: could be added to api doc

joakim: let's go through the four proposals

chris: the different proposals could be implementation provided with rec

veronique: agree to go with multiple options
... only worried that apis could not be compatible

chris: implementation approaches do not need to be described, thinks that felix shares that view
... not sure how to make ontology document then specific enough
... implementations should be published, not sure where

veronique: implementations should be in the document

chris: in other recs, they add a list of possible recommendations, not in the rec
... there needs to be sufficient documentation on the implementations

veronqiue: reader needs concrete examples

<florian> +1 @ Vero

joakim: charter says we have 2 recommendations
... we could keep them separate, but publish them synchronously

veronique: there is also the issue of a separate document on implementations

joakim: as ontology is a rec, we need to discuss how to test it
... to be discussed with team contact

wonsuk: not clear how to do that for the ontology, look at how other groups handle similar issues

veronique: we have 5 different implementations of ontology

wonsuk: we have to decide if we just provide the core properties, or also design of ontology
... not sure what is appropriate for recommendation
... if we only provide core properties, mapping scheme is moved to implementation part

if we describe mapping more concretely, we need to elaborate ontology document to describe an approach that fits for many people

wonsuk: deciding for a certain scheme will raise discussions about approach

chris: wonsuk, do you mean a concrete serialisation by mapping scheme?

wonsuk: a concrete one
... there could be additional formats not considered
... people may want to add other formats

joakim: felix was in favour of having no formal mapping in the rec
... the formal description could be to explain in make it clear, but not normative
... as an additional layer of conformance
... let's go through the approaches in the paper

veronique: we seem to agree that several ones are possible
... approach based on skos
... use skos for mapping between properties
... issue for many people, should be discussed on skos list

joakim: does it define data types?

veronique: assumes what is mapped are skos concepts, so it's typed in a sense
... less formal than owl equivalence

joakim: do we need inference?

florian: eg map dimension to width/height

veronique: why is spatial dimension in one property?

there are pros and cons for having it one or two properties

chris: mapping using owl and swrl
... properties are modelled as classes
... it's ontology engineering on metadata format

veronique: similar to proposal in event model

chris: modelling properties and schemes, but approach similar to event model
... model as classes, use equivalentProperty, equivalentClass
... rules need for data type conversion

<florian> werner: introduces his approach using a format independent ontology

<florian> ...this approach my have drawbacks with levels of media fragments (discovered while implementing, not part of the paper)

veronique: event model might be useful fot mapping fragments

wonsuk: approach: mapping with built-in properties
... describe properties in 2 standards to be mapped
... relation classes modelling type of relation, data types
... general approach for mapping between media ontology and each format
... target of mapping described by XPath for XML based formats
... for EXIF or ID3, the mapping class contains identifier
... when metadata property is encountered, application applies information in mapping class
... can access information in input file

veronique: should be represented as ontology defining the mapping, and rules
... representation is awkward now with too many blank notes
... interesting idea, but implementation needs improvement
... event based model seems to be generalisation of chris' approach
... metadata is event, that has author, start/end date, place, ...
... link to representation of content, can be linked to other metadata of the event
... technical properties can be attached
... people are working on spatial and technical reasoning on event models
... beneficial to relate to generic concepts

chris: reason for representing properties as concepts

veronique: link properties to subclasses of event model

joakim: created movie ontology
... ingested data from imdb, dbpedia
... many advantages for querying, inference
... could solve problems for us
... concepts get natural grouping

veronique: eg person has natural mapping, no need to care about structure of names
... no natural mapping for some properties, might need extensions

joakim: do we have a generic ontology?

veronique: different event models have been proposed
... link between different models

joakim: would we define generic one and link our properties?

<florian> motools.sourceforge.net/event/event.html

[coffee break]

<Daniel> http://www.w3.org/TR/dcontology/

improvement of use case document

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

<joakim> scribe: Joakim

Veronique: we can send an email to the group if should define a generic ontology

Chris: how should we define the mappings in the ontology document?

<Daniel> ACTION: Veronique to send an email to the group to define an implementation approach of ontology with four suggested approaches [recorded in http://www.w3.org/2009/11/05-mediaann-minutes.html#action01]

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

Werner: also have to maintain the mappings

<Daniel> ACTION: joakim to ask Veronique to send an email to the group to define an implementation approach of ontology with four suggested approaches [recorded in http://www.w3.org/2009/11/05-mediaann-minutes.html#action02]

<trackbot> Created ACTION-168 - Ask Veronique to send an email to the group to define an implementation approach of ontology with four suggested approaches [on Joakim Söderberg - due 2009-11-12].

Veronique will try to update the mapping table with additional properties

Chris: If we include generic concepts in the document we do more than we set out for

we should have the mapping to generic concepts as a slice of the recommendation

<Daniel> Joakim: why we should go generic concept ?

<Daniel> a separated implementation document seems good to us by several participants

<Daniel> Primer docs would be good place for having the illustration of generic concept and something like those texts if allowed

<Daniel> ext in Ontology docs Abstract needs to be elaborated

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

<Daniel> briefly going through the link above

<wbailer> ACTION: vmalaise to update text on in scope formats in ontology doc (formats not in mapping table) [recorded in http://www.w3.org/2009/11/05-mediaann-minutes.html#action03]

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

<wbailer> ACTION: veronique to update text on in scope formats in ontology doc (formats not in mapping table) [recorded in http://www.w3.org/2009/11/05-mediaann-minutes.html#action04]

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

<wbailer> ACTION: wonsuk to update 4.1.1 of ontology doc (put text on voring etc there) [recorded in http://www.w3.org/2009/11/05-mediaann-minutes.html#action05]

<trackbot> Created ACTION-170 - Update 4.1.1 of ontology doc (put text on voring etc there) [on WonSuk Lee - due 2009-11-12].

<wbailer> ACTION: dave to improve description of properties (together with veronique) [recorded in http://www.w3.org/2009/11/05-mediaann-minutes.html#action06]

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

<wbailer> ACTION: dsinger to improve description of properties (together with veronique) [recorded in http://www.w3.org/2009/11/05-mediaann-minutes.html#action07]

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

<wbailer> ACTION: veroniqueM to rewrite intro to be clear on what we mean by ontology [recorded in http://www.w3.org/2009/11/05-mediaann-minutes.html#action08]

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

<Daniel> http://www.w3.org/2008/WebVideo/Annotations/drafts/ontology10/WD/mapping_table.html

<Chris> topic nr 10 can be removed

<Daniel> new types are added in http://www.w3.org/2008/WebVideo/Annotations/drafts/ontology10/WD/mapping_table.html

<Daniel> thierry added new types into the link according to stockholm meeting, but mapping table is not updated yet. Editors should review mapping table again

<wbailer> ACTION: daniel to chase mapping table editors to restructure (following summary table) and update their tables [recorded in http://www.w3.org/2009/11/05-mediaann-minutes.html#action09]

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

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

<Chris> this is related to topic nr 12 of the Ontology improvements

<Daniel> Daniel will contact each corresponding editor (due is 1st Dec) http://www.w3.org/2008/WebVideo/Annotations/wiki/Format_mapping_review

<Daniel> Data type in summary of mapping table as well as ontology docs will be elaborated later on

loss of semantics: action item to Veronique to address that

Missing: Syntactic and semantic mapping, needs to be elaborated. Action Item to Felix

<wbailer> ACTION: felix to define data type mappings as soon as the data types for the formats are defined [recorded in http://www.w3.org/2009/11/05-mediaann-minutes.html#action10]

<trackbot> Created ACTION-175 - Define data type mappings as soon as the data types for the formats are defined [on Felix Sasaki - due 2009-11-12].

Datatypes of properties is dropped and be part of #13

<Chris> item nr 19 is related to role types

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

Defining types for properties, http://www.w3.org/2008/WebVideo/Annotations/wiki/Sub_Types

<Daniel> elements that contain type/value pairs, such as contributor, title (album, song, etc), location (recording, depicted, etc), date (create, publishing, etc) and more

<Daniel> dentifier: UMID, EASN, rating: review rating, MPAA, personal rating, collection: album, personal, my favorites,

<Daniel> e.g., Identifier: UMID, EASN, ating: review rating, MPAA, personal rating, collection: album, personal, my favorites,

<Daniel> targetAudience: Age group, geographical

<vmalais> joakim: wrap up of the previous discussions

<vmalais> werner: we could make a separate page to describe the sub-properties for the core properties of the media ontology

<vmalais> ... we could think of a wiki approach to define the relevant subproperties

<vmalais> joakim: we started with the roles and relations, checked from EBU schemas

<vmalais> joakim: should be hierarchical, we culd have subproperties per media type

<vmalais> joakim: the list was elaborated from EBU and all media guide

<vmalais> jean-pierre evain: EBU has made mappings between lots of schemas, we can benefit from these mappings

<vmalais> joakim: we need a method to select the relevant subproperties, the group we benefit from your experience to choose the most relevant ones

<vmalais> doug: I wrote a metadata schema, I am interested in yur selection of properties

<vmalais> joakim: we need sub-properties for our core properties, I made a short list for roles, relations, Jean-Pierre Evain is from EBU, he worked on the same topic, we would like to benefit from his experience

<vmalais> Jean-Pierre Evain: in the schemas I made the mappings for, it is not really necessary to have sub-properties

<vmalais> Jean-Pierre Evain: a possibility is to add the type information to the property name

<vmalais> ... property is title for example and "album" is the type

<vmalais> ... instead of making long lists of subproperties, because this will not be exhaustive

<vmalais> Werner: agreed that we will not be exhaustive, but we would like to define a set of relevant subproperties

<vmalais> Doug: let's try to clarify a terminological problem

<vmalais> Jean-Pierre Evain: "type" is a common practice to define a list of subproperties

<vmalais> ... if the ontology would be in RDF I would go for subproperties, but as it is not, the notion of type is more relevant

<vmalais> ... now it is more a list of properties and mappings, like Dublin Core, you run into the same problems: the more subproperties you make, the harder it will be for other people to map to

<vmalais> chris: my probem is that if we don't do the subproperties, we can't define mappings between them

<vmalais> Jean-Pierre Evain: I can accept the selection of the core properties, at the high level where they are, but it is much less acceptable at a greater level of specificity in the properties

<vmalais> i.e. ok on the "title" level, but not on the "album title" level

<vmalais> doug: I made maxim, a simple specification, for a webapp author the extract information from a metadata file for video

<vmalais> ... the case I was interested in was to extract metadata

<vmalais> Jean-Pierre: if you want to extract as many information as possible, then the level of "title" is more relevant, isnt't it

<vmalais> ... you can make filetrs later if you get different types of titles

<florian> Veronique: we are not closing doors with defining subproperties

<florian> Jean-Pierre: ...but you are loosing semantics

<florian> Veronique: want to give the possibility to specialyse th search by subproperties

<florian> Jean-Pierre: information will be lost, only with the mapping the information will be saved

<florian> ...it depends what you are mapping

<florian> Werner: filtering would require a unique identifier

<florian> ... that?s way we try to define a small set

<florian> Doug: a user should be able to use this set everywhere

<florian> ...a certain functional core set with a mechanism for extension is what it should be

<florian> Daniel: please discuss further topics offline Doug and Jean-Pierre

Milstones of the MAWG

<florian> Daniel: we are a little bit delayed

<florian> ...use case and requirements doc needs no further work

<florian> ...ontology and api document should be LC in March 2010

<florian> ...also next F2F will be in March 2010

<florian> ...call for implementation should be May 2010 in order to move to PR and Rec

<florian> Doug: this timeline is still in time

<florian> ...the documents must be precisely

<florian> ...the tests should only reflect the recommendation, so tests should be build as far as possible

<florian> ...avoid should and may

<florian> Daniel: open issues are the test suites

<florian> Doug: you need to have 2 implementations

<florian> Doug: one test could be "this five formats can be mapped to the ontology"

<florian> Daniel: do we need to publish the Primer?

<florian> Phillippe: it would be nice to have...not a req

<florian> ...it would be only a note

<florian> Doug: if the rec should be used, a primer is very important

<florian> ...you can get the primer perhaps by the help of the community

<florian> Joakim: how to concretize our work?

<florian> Doug: you should avoid optional things

<florian> Joakim: is there an example for this?

<florian> Doug: Perhaps in SVG

test

<shepazu> http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#dom-events-conformance

<florian> Phillippe: you can also look at the security documents

<florian> http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/

<florian> Veronique: if we have several serialisations of the ontology, we could put it in the ontology document

<florian> Doug&Phillippe: go to CR before the group charter ends

<florian> ...then the time will be extended

<florian> ...but you will get last call comments

<florian> Joakim: major argument will be "why not use Dublin Core"

<florian> ...but we have a answer to that

<florian> Doug: you have to get more precise in the API, give examples

<florian> Chris: it?s up to the implementation, how it accesses the metadata

<florian> Doug: there are common ways to get e.g. the MIME type

<florian> ... implementation may also query more sources

<florian> ...it should not be seen as a restriction

<florian> Chris: not in scope, where the metadata is stored

<florian> Doug: the format and location of the metadata should not be restricted

<florian> ...should be defined in a own section

<florian> ...should look at formats like RDFa and JSON

<florian> ...one reason not to put it in RDF is just one more semantic web technologie

<florian> ...Primers are good, because they are concentrated examples

<florian> Veronique: we have different ideas how to implement this ontology

<Daniel> updated milestone @ TPAC2009: http://www.w3.org/2008/WebVideo/Annotations/wiki/images/a/aa/MAWG%E2%80%99s_deliverables_status.ppt

<florian> ...we want to add examples but don?t know where to put

<florian> Joakim: (show mapping table) would this "example" column be appropriate?

<florian> Jean-Pierre: makes not much sense to put this table into RDF

<florian> Werner: would help if you want to embed it

<florian> Doug: what are you defining in the API? get property xy (by perhaps filtering)?

<florian> Chris: API should allow mapping between metadata formats

<florian> ...mappings stored in the ontology

<florian> Doug: use one interface ala getMetadata(string propertyName)

<florian> Chris: we also thought about that

<florian> Werner: this version would be easier for developer

<florian> Doug: let us assume the ontology is a failure, but the API is a success

<florian> ...make the API general, so it is decoupled

<florian> (some discussion about pros and cons about the two implementation approaches)

<florian> Doug: talk to browser vendors, what implementation they would prefer

<florian> ...browser vendors like things like javascript prototyping

<florian> ...can provide the contact to such people

<florian> ...return types should be an array

<florian> ...each object in it should be dynamicly typed

<florian> ...you should be able to filter on e.g. date

<florian> Doug will formulate some important aspects via email

<florian> Jean-Pierre: please inform us about the context how people would use/implement the API

<florian> scribe florian

<florian> scribe: florian

- DRAFT -

MAWG F2F 2009-11-05

05 Nov 2009

Attendees

Contents