MAWG -- 26 Jun 2009

<jsderber> agenda: F2F Stockholm Day 2

<jsderber> scribe: Florian

<scribe> scribe: florian

starting the API discussion with a more detailed look at wonsuks slides

Searching for missing items in the yet implemented API

Victor: are we defining a JAVA API or more generic?

Chris: different constructs in different languages

<dsinger> hm, getPropVal( propname, sub-name-filter, fragment )? returns list-of-vals

Wonsuk: we need to define a more generic API

Victor: Some kind of IDL?
... are levels of conformance thought in the API? or one level of complexity?

Joakim: perhaps OpenSocial could help...they defined something like that
... so not the project but the way they defined it

Chris: perhaps have a look at W3Cs Web IDL?

OpenSocial: http://code.google.com/intl/de-DE/apis/opensocial/

W3C Web IDL: http://www.w3.org/TR/WebIDL/

Joakim: wants to examine the yet defined functions and then check what´s missing
... after that think of the language

Wonsuk shows the yet available methods of the API (implemented in Java)

discussing a few architectural things of wonsuks implementation

Wonsuk: first loading the ontology, than accessing the data
... using MAManager

Werner: you need libraries in order to handle different metadata standards
... i our ontology only the things of our properties
... other people should build the mapping on top of it
... would be more modular

Chris: reference implementation with two metadataformats in scope

Joakim: wants to know if the API uses Jena
... where is the information about the metadata standards stored?

Wonsuk: the implementation does´nt handle data types...all are strings
... information is stored in the ontology

Dave: we would be more productive to discuss what we want in the API

trying to summarize methods we need in the API with their return types and parameter

Chris: only one metadata format on a ressource? or a mixture of different formats?
... like MPEG-7 descripton of a still image, in which is EXIF included

Werner: the key point is, if there should be only retrieved the metadata of one particular format, or anything
... the major issue is to know, from what format the propert is provided (like title) in order to use getter and setter

Chris: the loss of information must be on a low level in the API mehtods

Werner: what happens when a setter is executed? to what format will be written?

Joakim: we need some mechanism i order to loop over the supported formats

Chris: how the backend stores the metadata information is not important...the idea is to use the single fields available in metadata formats in order to reduce the semantic loss
... a few elements fit good, a few not, choose only the good fitting and don´t care on the storage

Wonsuk: we are just identifieng the metadata
... some applications might support more than one format

Werner: the behavior of the API must be specified

Joakim: what should the API return if application fails?

<victor> I dont think we have prepared well the meeting, as problems/ideas are appearing as we along quite erratically

<victor> For the next time we should have come here with some proposals to be discussed...

Florian: we should focus on identifying major issues and work on them

<victor> +1

<tobias> +1

*small_coffee_break*

<victor> ...

Werner: how relevant are the setters? only nice to have?
... getters are more important

Dave: get(property-name, source-format-filter, sub-type-filter, langugae-code-filter, fragment-indicator)
... returns list-of-values
... some properties may have subtypes
... only the first property is essential...the others are optional

Joakim: we allready have names for the different formats in the ontology doc v1.0

Dave: get-property-names-that-have-values() //kind of service discovery
... get-source-formats() //a list of formats with at least one property with at least one value

Werner: what happens if we filter on something irrelevant (e.g. language)?
... we have to define the overall context (source, metadata, ...)

Chris: the storage of the metadata should be part of the implementation (cotainer format, distributed, ...)

Werner: but you have to deal with it at the API level

werner and tobias will probably do a reference implementation

Joakim: which of the return types are controlled by our vocabulary?

Werner: we should define it (or a range)
... perhaps enumerates

Joakim: we should check the use case document if we are compliant to the requirements

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

<dsinger> ACTION: victor to edit section 3 example to say that both XMP and IPTC have props that map to MAWG createDate [recorded in http://www.w3.org/2009/06/26-mediaann-minutes.html#action01]

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

now reviewing the requirements for the API

Werner: ambiguous meaning in section 6.1

Dave: problem again with structured and unstructured metadata (e.g. size <-> personal name)

Joakim: can we ask if its structured?

requirement r02: not in scope at the momen

great discussion about th handling of structured and unstructured metadata arise

scribe: regarding requirement r03

<victor> i agree

we will introduce two methods: get structured data & get unstructered data

if possible, the adequate data will be retreived...otherwise a mapping takes place (for now black box mapping)

<victor> Example:

<victor> Creator: David

<victor> Creator: <foaf:Person> <foaf:name>David Singer </foaf:name> <foaf:gender>Male</foaf:gender>...

<victor> In the second case, the mapping would return "david singer" and not Male, what is not relevant.

<chris> continuing discussions on the requirements in the use case document

<chris> ... requirement r04

<chris> David: where is the user-defined metadata?

<chris> Werner: refers to example 5.5

<scribe> scribe: chris

Victor: it's related to social networks

David: for user-defined metadata we need to identify the user

use ma:description tag?

Werner: the description tag might be not sufficient to describe "structured" user-defined metadata
... requirement r05

r05 can be met with current proposal

scribe: requirement r06

Werner: Felix raised the question if a serialization of the ontology should be defined

<victor> requirements 06 and 07 perhaps could be a bit better rephrased

<victor> sorry, I mean 05 and 06.

requirement r06 is not related to the api so further discussion on this is postponed

regarding requirement r08 we could use the ma:collection and ma:relation properties

Tobias: how do you tell if we are dealing with a resource or a collection?

remains an open question

<scribe> ACTION: tobias update rationale of r09 [recorded in http://www.w3.org/2009/06/26-mediaann-minutes.html#action02]

<trackbot> Created ACTION-141 - Update rationale of r09 [on Tobias Bürger - due 2009-07-03].

UNKNOWN_SPEAKER: requirement r09

Tobias: this is related to trust issues about the metadata
... we need metadata about the metadata

chris: other issues like who added metadata, when, trust, ...

r09 remains an open question about the provenance of metadata

requirement r10 can be met by incorporating fragment-identifiers in the api

requirement r11 can be met (and is concerning the ontology)

requirement r12 can be met using structured datatypes

requirement r13, using structured datatype we can distinguish between uri's and strings

chris: maybe we should allways return structured data (which can contain unstructured data)

\me

Florian: we should add our notes of the meeting to the wiki
... feedback is needed about the identified issues and proposals

Joakim: we should discuss summer holidays (at phoneconference)

Tobias: assign tasks to people on the identified problems

<florian> +1

<wonsuk> +1

<victor> +1

<scribe> ACTION: chris provide examples for our set of properties [recorded in http://www.w3.org/2009/06/26-mediaann-minutes.html#action03]

<trackbot> Created ACTION-142 - Provide examples for our set of properties [on Chris Poppe - due 2009-07-03].

Thierry: the mapping table has been provided as a wiki

http://www.w3.org/2008/WebVideo/Annotations/wiki/Summary_mapping.html

Thierry: would it be easier to just make changes in html (ofline) and upload?
... problem with wiki: changes need to be done in html code

Joakim: most important is that everybody can individually easily work on his documents/table

Thierry: publish the tables as html-pages and give permission to editors to upload their version

<scribe> ACTION: tmichel to sent mail about the upload of tables as html-pages [recorded in http://www.w3.org/2009/06/26-mediaann-minutes.html#action04]

<trackbot> Created ACTION-143 - Sent mail about the upload of tables as html-pages [on Thierry Michel - due 2009-07-03].

<victor> \me A group foto has been taken....

<scribe> ACTION: wbailer to fill out the datatype column for mpeg-7 to set an example for other mapping table editors [recorded in http://www.w3.org/2009/06/26-mediaann-minutes.html#action05]

<trackbot> Created ACTION-144 - Fill out the datatype column for mpeg-7 to set an example for other mapping table editors [on Werner Bailer - due 2009-07-03].

<scribe> ACTION: chris to elaborate on the API return types (structured and unstructured) by providing examples [recorded in http://www.w3.org/2009/06/26-mediaann-minutes.html#action06]

<trackbot> Created ACTION-145 - Elaborate on the API return types (structured and unstructured) by providing examples [on Chris Poppe - due 2009-07-03].

<scribe> ACTION: jsderber to define sub-types for the different properties [recorded in http://www.w3.org/2009/06/26-mediaann-minutes.html#action07]

<trackbot> Created ACTION-146 - Define sub-types for the different properties [on Joakim Söderberg - due 2009-07-03].

<wonsuk> example of XPath for ma:contributor --> /rss/channel/item/media:group/media:credit[@role='contributor']

Victor: are there means to work collaboratively on ontology design/implementation?

Joakim: should we keep all the formats?

David: we should pick a few that we will work on in prototypes

<scribe> ACTION: tmichel Check status of Web IDL for web api's [recorded in http://www.w3.org/2009/06/26-mediaann-minutes.html#action08]

<trackbot> Created ACTION-147 - Check status of Web IDL for web api's [on Thierry Michel - due 2009-07-03].

Wonsuk: a first working draft of the API document could be made (proposed editors: Wonsuk, Chris, Florian, Victor)

content of the draft: outline, introduction, draft API, draft datatype, examples of api (e.g. Java-implementation of API)

David: notes of this morning have been added to the wiki

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

<scribe> ACTION: wonsuk to start work and collaboration on the API draft document [recorded in http://www.w3.org/2009/06/26-mediaann-minutes.html#action09]

<trackbot> Created ACTION-148 - Start work and collaboration on the API draft document [on WonSuk Lee - due 2009-07-03].

<fstegmai> AOB ?

<victor> [informally, we discuss about SWRL implementations, and SPARQL utopic implementation etc...]

David: set deadline beginning of october for the API document

5th F2F is planned 2nd of November in Santa Clara

Joakim: main topic of next f2f should be the reference implementation of ontology & api
... + defining tests for the implementation
... + discussion with related groups such as semantic web and web api

- DRAFT -

MAWG

26 Jun 2009

Attendees

Contents

Summary of Action Items

Scribe.perl diagnostic output