See also: IRC log
<joakim> meeting F2F Gent
<Daniel> welcome media annotation WG and self introduction
<Daniel> Evain from EBU working for EBU, TV-anytime and metadata related technologies
<Daniel> Wonsuk from ETRI working for sematic web who is a co-editor of use case and req. document
<Daniel> Chris and Sam Univ of Gent, working for image annotation and metadata of sematic web
<joakim> Bailer from Johanneum inst
<joakim> media semantic incubtaor group
<Daniel> Tobias from Univ. of Innsbruk working for several research items.
<Daniel> Joamin from Ericsson. research fields are amlost multimedia. mostly working for metadata today
<Daniel> Felix at W3C team contact
<joakim> Felix will move to Pottsdam to teach at university
<joakim> Frank has a passed in AI, how to use AI for various applications
<Daniel> Frank Univ of Amasterdam
<joakim> Frank has been working with MPEG-7
<joakim> Victor arrived from Bareclona
<Daniel> number of f2f meetings depend on how much works to be done within WG. During this meeting, we will at least discuss the next f2f meeting data and place
<joakim> updated agenda to discuss the API today
<joakim> scribe: tobias
<fsasaki> scribeNick: tobiasb
fsasaki: We start with a review of the Dublin Core schema
Discussion of dc:contributor: it is very general needs to be specialized
<joakim> Mediachain from MPEG-7 defines "roles"
<joakim> Do you want to point to refernce. The problem is according to Evain to find the most update role list
EBU also defined roles, TVAnytime too. The question is which role define we adhere to.
DC: Coverage is again a very general property; should be refined in more specialized field
pierre: we should at least refine it to spatial/temporal coverage
XMP in its Dublin Core Schema part only uses the basic Dublin Core basic terms
pierre: someone developed a specification how to write DC strings
fsasaki: we should try to use common and already defined properties as much as possible
fasaki: discussion about mapping schemas: highly complex even if you take the simple case of mapping the representation of person names in different standards
joakim: DC leaves room for interpretation as it is defined very general
fsaski: we can for example define an own creator-property with more specialized information.
Problem from Europeana is the demand to map back to Dublin Core which looses information
... on the on hand you have a very simple DC and on the other hand you have a very complex MPEG-7 standard. How do you bring them together?
fsasaki: we will have to arrange with the loss of information.
frank: you can point to locations how to get more information (available in MPEG-7 or any other format available)
fsaski: points out to examples from the API listing mappings for createDate
fsasaki: The group decided to put XMP in the center of the group and will discuss it very detailed.
wbailer: the api should abstract
from the format behind and should return the same all the time.
... more detailed information should be optional
fsasaki: jumping to the ontology deliverable: Developers have to implement the mappings; another question which arises: when is an implementation conformant to our specification?
joakim: perhaps we need a test suite.
fsaski: we could maybe to think of specifying profiles with differing complexity
fsasaki: DC data, description, format, language,
rights, subject, title: all yes
... XMP indentifier is qualified using a schema
wbailer: it should be open to support different identification schemes
fsasaki: future more complex mappings should be
supported meaning that other parties should be able to extend the mapping specification.
... rating-yes but we should define it more detailed.
joakim: rating can mean anything; parental rating/subjective rating/etc.
wbailer: With MPEG-7 you can define rating schemes.
<scribe> ACTION: Felix to check XMP rating [recorded in http://www.w3.org/2008/12/09-mediaann-minutes.html#action01]
<trackbot> Created ACTION-43 - Check XMP rating [on Felix Sasaki - due 2008-12-16].
pierre: worried about just having a container for rights information; because you can define very detailed schemas; or you can make it simple and point to external information
<raphael> Raphael: go through the spatial fragments specifications (image maps, MPEG-7, SVG)
victor: probably we should define a certificate field.
... for some use cases we need more complex rights schemes like ORDL or something else.
tobias: creative commons licesing schema defines basic terms which could be adopted
<wbailer> scribe werner
<wbailer> scribeNick wbailer
<VeroniqueM> I can call, yes, what is the number?
<fsasaki> scribe: wbailer
xmp:derivedFrom useful for 3 level description (idea-realisations-instance)
... useful mainly for cultural heritage UC
felix: decide from UCs if needed
chris: same as dc:source?
<fsasaki> "Unique identifier of the work from which this resource was derived."
chris: xmp:derivedFrom is same kind of information but more specific than dc:source
felix: take both into account (xmp:derivedFrom related to dc:source)
xmpMM: history: no - comments?
for user adaptation, should be included
... example: users generate media items, if system should provide support for creation, this could be derived from history of previously created item
... alternative is link to other kind of representation of this information
tobias: relevant in creation of e.g. 3D items (derivation of content, modifications, ...)
of conformance, there could be different levels of conformance (e.g. without history)
... include xmp:history for some UCs
<scribe> ACTION: frank to check if xmp:history is applicable for the current use cases [recorded in http://www.w3.org/2008/12/09-mediaann-minutes.html#action02]
<trackbot> Created ACTION-44 - Check if xmp:history is applicable for the current use cases [on Frank Nack - due 2008-12-16].
felix: xmpMM:Ingredients to be discussed with fragments WG
frank: same applied to derivedFrom
felix: in derivedFrom rather link to media item, with ingredients rather to
... xmpMM:InstanceID related to history
joakim: important to have
... refers to content
xmpMM: ManagedFrom, Manager, ManageTo: no
xmp: MM:ManageUI: yes - comments?
jean-pierre: depends on type of application, professional or end user
... for content mgmt in professional information
chris: same as dc:description?
jean-pierre: no, description should not contain an identifier
xmpMM: OriginalDocumentID: yes
related to xmp:identifier?
felix: general issue with XMP properties: how do applications use them, which mappings could make sense?
jean-pierre: careful with trying to align with Adobe, focus should be what users need
felix: hope that Adobe joins WG
xmp: MMPantry, yes, related to 3 level
xmpMM: Versions: no - comments?
relation to xmp:history?
joakim: actors from creation tool manufacturers, end user applications and users - different interests, users should define requirements
felix: users are important, all actors are needed to get solution
... approach: start with simple working implementation, extend in future versions
agreed on excluded properties
joakim: some included properties related to dc properties (e.g album)
... make connection to dc, explain difference in the mapping
... xmpDM:engineer - exclude
... xmpDM:composer related to dc:creator
... xmpDM:duration related to dc extent
xmpDM: instrument, xmpDM:key, xmpDM:numberOfBeats -> dc:description
felix: look at how xmp fields are used in applications
joakim: sony ericsson is using xmp
<scribe> ACTION: joakim to look at how sony ericsson uses xmp [recorded in http://www.w3.org/2008/12/09-mediaann-minutes.html#action03]
<trackbot> Created ACTION-45 - Look at how sony ericsson uses xmp [on Joakim Söderberg - due 2008-12-16].
frank: is ontology supporting api or to build applications on
... use ontology for development of api, also design to be used by other people for app development
<VeroniqueM> I think that it would be useful to have the ontology as an "interlingua"
felix: maybe do not specify formal ontology, but just prose descriptions
... avoid discussions rdf vs xml
... keep door open for people to provide formal specification
... conformance: which is the normative part of the spec?
... choices: take into account mappings, implement api, rdf non-normative OR rdf normative, but different levels of conformance, including some without rdf
... cf r05: providing the ontology as a set of terms
joakim: good to have reference
... also to demonstrate approach
felix: test suite required for everything that's normative
... tests and examples as soon as possible to make it easier for people to understand
... shows internationalisation tag set test suite as example
wonsuk: create table of all considered properties and mappings (if possible) to other standards
joakim: include in template
tobias: content description - more important than other media properties for end user
felix: more than covered by the xmp elements?
jean-pierre: internet tv: use search engine for
content, work on ontology for av content
... users search eg by series, broadcast time
... many xml based metadata formats
... use semantic web to reach users
felix: gotuit - hq metadata for search etc
joakim: manual annotation possible for professional content, but not for UGC
felix: 2 steps: ontology 1.0 (find content), ontology 2.0 for av content and services
<fsasaki> ONTOLOGY 1.0
<fsasaki> general mechanism to find content
<fsasaki> different levels of description should you bring back to content.
<fsasaki> Example: "I am looking for a program with title XYZ."
jean-pierre: current approach: 1 class, only properties
<fsasaki> ONTOLOGY 1.x, 2.0:
<fsasaki> ontology for audivisual content and services
<fsasaki> different levels of description should you bring back to content, work with sw technologies
<fsasaki> many specs in broadcasting world today in XML (TV Anytime, ...). How to provide interoperability?
rssagent, make logs public
<fsasaki> chris presents PeCMan Metadata, metadata for managed personal content
<fsasaki> metadata standards like mpeg-7, dig35, EXIF, ... are mapped to the metadata model
<fsasaki> mappings are OWL equivalence mappings
<fsasaki> retrieval of metadata content based on queries
<fsasaki> result can be e.g. a dc:description
<fsasaki> a dc:description is mapped to ontology, so that metaaccess is possible
<fsasaki> relation to XMP - most of properties are the same
<fsasaki> ontology structuring is different because of use case of interontology linking, e.g. linking to person ontologies
<fsasaki> ACTION: Felix to bother Eric so that he gives AI to Chris about the metadata model from IBBT [recorded in http://www.w3.org/2008/12/09-mediaann-minutes.html#action04]
<trackbot> Created ACTION-46 - Bother Eric so that he gives AI to Chris about the metadata model from IBBT [on Felix Sasaki - due 2008-12-16].
<fsasaki> RICO ontology
<fsasaki> use case is also metadata retrieval
<fsasaki> victor presents MXM and we are discussing API format and relation between API and ontology
<fsasaki> idea is to have API specified not specific to e.g. java or c++, but have a general description which can be implemented in specific framework
<fsasaki> we are considering how or if to implement setting of metadata information. Question: how can this be implemented? What are protocol-specific requirements? What is necessary to implement setting information in addition to just say "setPropteryXYZ" instead of "getPropertyXYZ"?
<fsasaki> issue of how to set data types
<fsasaki> e.g. set a string or a date data type
<fsasaki> issue how to get from information-lossy ontology to e.g. an adequate description in the target format
<fsasaki> ACTION: Werner and Frank to investiage existing approach for setting metadata on a "metamodel level" (or "ontology level") [recorded in http://www.w3.org/2008/12/09-mediaann-minutes.html#action05]
<trackbot> Created ACTION-47 - And Frank to investiage existing approach for setting metadata on a \"metamodel level\" (or \"ontology level\") [on Werner Bailer - due 2008-12-16].
<fsasaki> see http://www.w3.org/2008/12/09-mediafrag-irc#T14-42-12 and after
<raphael> go to #mediafrag
<spark3> please switch this IRC channel to mediafrag for this joint session
<fsasaki> ACTION: Felix to send pointer to media fragments WG for review of uc&req doc, when it is ready [recorded in http://www.w3.org/2008/12/09-mediaann-minutes.html#action06]
<trackbot> Created ACTION-48 - Send pointer to media fragments WG for review of uc&req doc, when it is ready [on Felix Sasaki - due 2008-12-16].