- From: Florian Stegmaier <stegmai@dimis.fim.uni-passau.de>
- Date: Tue, 5 Apr 2011 11:03:12 +0200
- To: public-media-annotation@w3.org
Hi Pierre-Antoine, all, at first, thank you for your response. Since i cannot join the teleconf today, i wanted to tell you my feelings on this issue. In the first place, b) would be most suitable, but there may be conflicts for implementors with too specific properties. There are some properties in MediaAnnotation, that have to be filled, e.g., property name, value and of course status code, otherwise it makes no sense. Sometimes language makes sense, sometimes not. Sometimes you will not have a Fragment identifier. On the other side, there are specific properties, that can be filled with more or less the same content as stored in value (e.g., identifierLink in Identifier interface). I agree, that a unstructured Geolocation is not that really expressive, but maybe in some metadata formats an unstructured string is all you may get. An attempt to parse one single string into several properties might be exact, but might be blurred - depending on the precision of annotations in the source format. From my point of view it is way easier for people implementing our API to have an API wide regulation (e.g., as we have it with xyLink and xyLabel). Otherwise people might get confused with a mixture of optional and requiered attributes at property level. In order to have a "global regulation" over our property set, i would prefer to go for variation a). There should be a set of attributes of MediaAnnotation interface that we require to be filled (e.g., property name, value, source format and status code). All the rest and especially the specific attributes may be filled optionally. Best, Florian Am 02.04.2011 um 11:52 schrieb Pierre-Antoine Champin: > Hi Florian, all, > > My first reaction would be to vote for b), although I have to check it > with the actual list of attributs (I'm writing this mail while offline). > > It seems to me that it would make no much sense to return a location > with no geographical coordinates, or a ranking with no value... > > On the other hand, IIRC there are some attributes in the common > interface that could be considered optional. > > pa > > On 03/30/2011 06:45 PM, Florian Stegmaier wrote: >> Dear all, >> >> Werner and i have integrated the resolutions decided in last weeks teleconf [1]. Here you can find the revised version of the API: >> >> http://dev.w3.org/2008/video/mediaann/mediaont-api-1.0/mediaont-api-1.0.html >> >> We encountered another important issue: We have a general MediaAnnotations interface with attributes valid for all properties and sub-interfaces covering specific attributes for a property (e.g., longitude for location). The main question is, what attributes we declare as required. These options would be possible: >> >> a) An API MUST fill all attributes defined in the MediaAnnotation interface and MAY (optionally) fill specific attributes defined in the corresponding sub interface. >> b) An API MUST fill a specific subset of attributes of the MediaAnnotation interface and MUST fill a specific subset of the sub-interface attributes. >> >> Nevertheless at the moment we only declare these things in a note (following version a) in section 4.4.2. >> >> Best, >> Florian >> >> [1] http://lists.w3.org/Archives/Public/public-media-annotation/2011Mar/0100.html >> _____________________________ >> Dipl. Inf. Florian Stegmaier >> Chair of Distributed Information Systems >> University of Passau >> Innstr. 43 >> 94032 Passau >> >> Room 248 ITZ >> >> Tel.: +49 851 509 3063 >> Fax: +49 851 509 3062 >> >> stegmai@dimis.fim.uni-passau.de >> https://www.dimis.fim.uni-passau.de/iris/ >> http://twitter.com/fstegmai >> _____________________________ >> >> _____________________________ Dipl. Inf. Florian Stegmaier Chair of Distributed Information Systems University of Passau Innstr. 43 94032 Passau Room 248 ITZ Tel.: +49 851 509 3063 Fax: +49 851 509 3062 stegmai@dimis.fim.uni-passau.de https://www.dimis.fim.uni-passau.de/iris/ http://twitter.com/fstegmai _____________________________
Received on Tuesday, 5 April 2011 09:03:47 UTC