W3C home > Mailing lists > Public > public-media-annotation@w3.org > December 2010

RE : [AGENDA] Media Annotations WG Teleconf - 2010-12-21

From: Evain, Jean-Pierre <evain@ebu.ch>
Date: Thu, 23 Dec 2010 18:58:31 +0100
To: "mcsuarez@fi.upm.es" <mcsuarez@fi.upm.es>
CC: 'Joakim Söderberg' <joakim.soderberg@ericsson.com>, "public-media-annotation@w3.org" <public-media-annotation@w3.org>
Message-ID: <7D1656F54141C042A1B2556AE5237D60010D3AB31616@GVAMAIL.gva.ebu.ch>
Dear Mari.Carmen,

Thanks for the detailed comments.

My responses and proposed changes in line.

Merry Christmas and Happy New Year 2011.

Best regards,


De : Mari Carmen Suárez de Figueroa Baonza [mcsuarez@fi.upm.es]
Date d'envoi : jeudi, 23. décembre 2010 15:38
À : Evain, Jean-Pierre
Cc : 'Joakim Söderberg'; public-media-annotation@w3.org
Objet : Re: [AGENDA] Media Annotations WG Teleconf - 2010-12-21

Dear Jean-Pierre,

thank you very much for the revised version of the ontology.

I attended the teleconf on 21st december, however I had some problems
with my micro; I was able to follow all your conversations, but I could
not provide my comments via phone (I used the irc channel).

After this teleconf, I took a look to the current version of the
ontology, and I have a set of comments:

- With respect to the language and signing of a particular resource: as
it is now in the code there is a property (hasLanguage) whose domain is
MediaResource, this means that a particular resource (e.g. a video) can
have only one language. But what about a video composing of different
tracks with diverse languages and signing, would it have sense to
consider this possibility?
In addition, I would like to comment that maybe we could provide a range
for this relations (e.g., NaturalLanguage) and instanciate it with the
ISO language codes.

JPE: A particular resource can have an infinity of languages. If we use only the class language then there is no discrimination between the role of the different languages accompanying the resource. The purpose to a language according to the approach chosen by the group is to use sub-properties of hasLanguage, e.g. hasMainLanguage, hasSigningLanguage, etc. 
The same is true for a language associated to an audio track. This could be also sub-properties under the same hasLanguage property as they would be inherited anyway.
I now realise that we don't need a sub-class of track for captioning as we provide no other information than the language and purpose (but nothing e.g. about the format). I would therefore suggest that we only have an example like a subproperty of hasLanguage saying hasAudioDescriptionCaptioningLanguage. We could add the above example to show other possible properties associated to a resource (inc. audioTrack)
About the range. The approach taken by the group is to use a blank node as a mechanism to provide a value either as a URI (e.g. pointing to a SKOS concept in a classification scheme) or a string in a label.

PROPOSAL: Remove the sub-class captioning and add examples of subproperties to hasLanguage (no change on the blank node approach)

- It is not clear for me in the ontology how the distinction between
object properties and data type properties has been done. For example,
'hasCompression' is an object property but there is no class
representing 'Compression'; in this case, which is the range of the
relation; or do we have the compression expressed as an String. Similar
situations are 'hasKeyword' that could be represented as a datatype

JPE: same as above to support a blank node to point to an object or use a label for a string value.

PROPOSAL: no change on the blank node approach

- Regarding Track: there is a data type property called 'type' whose
domain is Track and range is String. However, there is also in the
ontology a hierarchy of Track including AudioTrack, Captioning,
VideoTrack. Thus, I think the 'type' property is not needed, because if
you have an instance X whose type is 'AudioTrack', then this instance is
instance of the class 'AudioTrack' and not of the class 'Track'.

JPE: Yes, additional track types should be represented as subclasses of track. Historical leftover I guess.

PROPOSAL: remove trackType

- There is also represented in the ontology the fact that a media
resource has a target audience. This target audience is modeled as a
class, however, I would say this could be a set of strings in a data
type property; unless you want to know information about each possible
group of audience (students, researchers, grandfathers, etc.). If this
is the case, we should instanciate the class 'TargetAudience' with the
possible instance we would like to consider in the ontology.

JPE: this has been a subject of a long discussion. I used to have a position similar to yours (also for rating) but was convinced to implement as is. Anyway, thanks for raising this again. Our discussion during TPAC focused very much on parental guidance. In this specific case,  I can imagine a content provider addressing different markets with their own parental control systems  (one or more per country actually like to movies, TV and games) would have a database of such schemes and therefore the current implementation would be justifed. However, th trues meaning of targetAudience doesn't require this and an object property (blank node for a URI or string) is enough (the issuer is the content provider by default).

PROPOSAL; I would therefore propose that the ontology targetAudience property is implemented by changing the name of the targetAudience class by parentalGuidance, and create an object property 'hasTargetAudience' with domain MediaResource.

I think these are all my comments. I hope this helps.
If you agree I could also contribute both to update/modify the rdf and
to update/modify the ontology document.

JPE: if you don't mind we cannot have too many editors of the RDF. I'll therefore take care of updating the file when we have agreed the changes.

Thank you very much and Best Regards.
Merry Christmas and Happy New Year 2011.

Mari Carmen.

Evain, Jean-Pierre escribió:
> Dear all,
> The revised version of the RDF hopefully implementing the changes
> agreed today.
> Regards,
> Jean-Pierre
> *From:* public-media-annotation-request@w3.org
> [mailto:public-media-annotation-request@w3.org] *On Behalf Of *Joakim
> Söderberg
> *Sent:* lundi, 20. décembre 2010 16:54
> *To:* public-media-annotation@w3.org
> *Subject:* [AGENDA] Media Annotations WG Teleconf - 2010-12-21
> Hello,
> On request from Florian et al. I have added an item to the agenda
> tomorrow.
> Remember, tomorrow is the last call for 2010, please be there!
> -------------------------------
> 1. Convene
> Media Annotations WG
> Zakim Bridge +1.617.761.6200, conference 6294 ("MAWG") Alternative
> dial numbers:
> France (Nice): +
> UK (Bristol) : +44.117.370.6152
> IRC channel: #mediaann
> Tuesday 2010-12-21 12:00-13:00 UTC, (ie, Amsterdam, Paris, Stockholm
> 13:00)
> Regrets: Tobias
> Chair: Joakim
> Scribe: TBA
> Minutes to appear: _http://www.w3.org/2010/12/21-mediaann-minutes.html_
> Propose to accept F2F minutes:
> _http://www.w3.org/2010/11/30-mediaann-minutes.html_
> 2. Next meeting
> TBA (2011)
> 3. Items
> [A] Action items:
> http://www.w3.org/2008/WebVideo/Annotations/track/actions/open
> [B] Discuss the set of changes to the (abstract) Ontology, summarized
> here by Jean-Pierre:
> 1) It is proposed to add track as a sub-class of fragment to help
> aligning with MFWG
> 2) It is proposed to add videoTrack and audioTrack to which currently
> existing specialised properties like frameRate or sampleRate will be
> more specifically linked as well as a better use of the compression
> property
> 3) It is proposed to add captioningTrack to better align with MFWG and
> also to address subtitling more properly
> 4) It is proposed to change createDate (or creationDate) as "date" and
> list createDate (or creationDate) at the same level as releaseDate,
> etc. This allows better hierarchical representation of dates in the
> RDF ontology as, for example, releaseDate cannot be considered as a
> subclass of createDate?
> 5) RatingValue should be float but it should now have been corrected
> in the API following today review of actions.
> 6) language and compression should allow string but also anyURI
> values, which would allow using SKOS concepts from classification schemes
> 1) We are not providing any information about signing, which is
> definitely important for accessibility
> 2) We are not providing very detailed information on captioning
> 3) I would therefore propose for discussion tomorrow the addition of
> signing and a number of properties such as the ‘purpose’ (is signing
> or captioning there for translation, subtitling, audio description,
> etc.), the language used (valid for signing as well as captioning) and
> maybe an attribute like closed vs. open signing or captioning
> [C] Follow up on Implementation of LC comments
> 1- Media Ontology spec
> -- LC Comment -2405: JP Evain:
> Introduction
> - Note to implementers, content authors - not really explicit, maybe
> these roles should be mentioned saying things like "it is expected
> that implementers will do." ". to the benefit of content providers", etc.
> - There is no section 1.1 on the purpose of the specification (yet)
> Section 4.1 core property definitions -> now section 5.1
> - The ma: prefix still appears in the table but since the comment was
> made Pierre Antoine, while working on the mapping table suggested that
> the prefix should only be used with the ma-ont namespace in the RDF ->
> reconsider position?
> Section 4.2.2 - no change as explained in previous response - tables
> in line -> now 5.2.2
> Joakim: "our specification" is replaced by "this specification" (OK),
> But "our Ontology" (two occurrences in section 1)
> Other comments from JP review
> The abstract and introduction should mention the definition of the RDF
> ontology and the mapping table that will come with it.
> -- LC Comment -2389 : NO - partially implemented
> http://lists.w3.org/Archives/Public/public-media-annotation/2010Nov/0086.html
> -- LC Comment -2404 : NO - partially implemented
> http://lists.w3.org/Archives/Public/public-media-annotation/2010Nov/0093.html
> http://lists.w3.org/Archives/Public/public-media-annotation/2010Nov/0085.html
> http://lists.w3.org/Archives/Public/public-media-annotation/2010Nov/0094.html
> -- LC Comment -2418: NO - partially implemented (Edits are missing)
> see edits at
> http://lists.w3.org/Archives/Public/public-media-annotation/2010Nov/0073.html
> ____________
> 2- Media API spec
> -- LC Comment -2406 : NOT reviewed
> -- LC Comment -2419 : NO partially implemented
> http://lists.w3.org/Archives/Public/public-media-annotation/2010Nov/0090.html
> -- LC Comment -2410 : OK But Chris must add Véronique's edits see
> edits at:
> http://lists.w3.org/Archives/Public/public-media-annotation/2010Nov/0107.html
> http://lists.w3.org/Archives/Public/public-media-annotation/2010Nov/0106.html
> [D] Future plans for the working group
> Proposal from Florian to have a rechartering Workshop collocated with
> the i-Know/i-Semantics
> Best Regards
> /Joakim
> ------------------------------------------------------------------------
> *************************************************** This email and any
> files transmitted with it are confidential and intended solely for the
> use of the individual or entity to whom they are addressed. If you
> have received this email in error, please notify the system manager.
> This footnote also confirms that this email message has been swept by
> the mailgateway ************************************************** *

 Dr. Mari Carmen Suárez-Figueroa
 Teaching Assistant

 Ontology Engineering Group (OEG)

 Departamento de Inteligencia Artificial
 Facultad de Informática
 Universidad Politécnica de Madrid
 Campus de Montegancedo, s/n
 Boadilla del Monte - 28660 Madrid

 Phone: (+34) 91 336 36 72
 Fax: (+34) 91 352 48 19
 e-mail: mcsuarez@fi.upm.es
 Office: 3205
This email and any files transmitted with it 
are confidential and intended solely for the 
use of the individual or entity to whom they
are addressed. 
If you have received this email in error, 
please notify the system manager.
This footnote also confirms that this email 
message has been swept by the mailgateway

Received on Thursday, 23 December 2010 18:00:30 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:24:45 UTC