- From: Danny Ayers <danny.ayers@gmail.com>
- Date: Fri, 8 Apr 2011 14:58:09 +0200
- To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Cc: Leonard Rosenthol <lrosenth@adobe.com>, "public-html@w3.org" <public-html@w3.org>
On 7 April 2011 09:42, Silvia Pfeiffer <silviapfeiffer1@gmail.com> wrote: > Let's also not forget the work of the W3C Media Annotations Working Group. > http://www.w3.org/2008/WebVideo/Annotations/ Personally I'm not convinced of the appropriateness of this work to the HTML effort, for two reasons: Primarily - it defines what you (should) get in too rich a fashion. While complexity is certainly a consideration, my main gripe is that the API effectively constrains what is (made) available. I can probably best explain what I mean alongside an example, below. Secondarily - I personally believe the way the ontology is used here is wrong-minded. It's certainly useful to have a mapping between terms common to the numerous metadata standards, but as presented here it goes beyond being a "pivot ontology" and more into the realms of "upper ontology". Web-based vocabularies allow the data producer and consumer to use models that are appropriate for their application requirements e.g. if you want to refer to a film then in some circumstances just the title will be adequate, at other times you might want access to, say, the bitrate of a particular encoding. The promotion of a single ontology to cover all (or at least most) cases moves the emphasis back from the open, distributed world back into a legacy centralized picture. Ok, an example. From [1] : [[ language = video.getMediaProperty(["language"]); if(noErrorStatus(language[0].status) == true) { ... } /** Resulting in: * [ { "Language" : { * "propertyName" : "language", * "languageLabel" : "en-us", * "statusCode" : 200 * } * } ] */ ]] How to get the value is largely a matter of taste: language = video.getMediaProperty(["language"]); is ok as it stands, though I quite like : language = video.meta("language"); (or even language = video.language as long as the next point is taken into consideration) Where my issues with it start is with the error check. I don't think that's necessary at this point. Either a property-value pair is available or it isn't, so it should be considered reasonable to ask for *anything* and either a value will be returned or null. The results? Most of what is returned above is redundant. Why not just: ["en-us"] (returning an array seems the best bet as properties can have multiple values) Note this doesn't preclude the use of the Media Annotations approach as well - there's only a fairly simple transformation needed in either direction. >> (Even though my personal opinion is that we need only name-value pairs >> for metadata.) Right. But also name-value pairs can support richer structures when the value is a pointer. In this particular case the obvious choice for a pointer is a URI, which could be dereferenced to get more information. It's arguable that this would suggest adding another field to the result data to say whether it's a string or URI. I'm open to persuasion, but I reckon a regex match would be adequate. Cheers, Danny. [1] http://dev.w3.org/2008/video/mediaann/mediaont-api-1.0/mediaont-api-1.0.html#example-in-javascript-3 -- http://danny.ayers.name
Received on Friday, 8 April 2011 12:58:37 UTC