See also: IRC log
<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
+1
<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
This is scribe.perl Revision: 1.135 of Date: 2009/03/02 03:52:20 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/()/(implemented in Java)/ Succeeded: s/../.../ Succeeded: s/implementatio/implementation/ Succeeded: s/12/r12/ Found Scribe: Florian Inferring ScribeNick: florian Found Scribe: florian Inferring ScribeNick: florian Found Scribe: chris Inferring ScribeNick: chris Scribes: Florian, chris ScribeNicks: florian, chris WARNING: No "Topic:" lines found. Default Present: tmichel, jsderber, dsinger, florian, victor, tobias, chris, wbailer Present: tmichel jsderber dsinger florian victor tobias chris wbailer Got date from IRC log name: 26 Jun 2009 Guessing minutes URL: http://www.w3.org/2009/06/26-mediaann-minutes.html People with action items: chris jsderber tmichel tobias victor wbailer wonsuk WARNING: No "Topic: ..." lines found! Resulting HTML may have an empty (invalid) <ol>...</ol>. Explanation: "Topic: ..." lines are used to indicate the start of new discussion topics or agenda items, such as: <dbooth> Topic: Review of Amy's report[End of scribe.perl diagnostic output]