W3C home > Mailing lists > Public > public-media-annotation@w3.org > June 2012

Re: [ACTION-472] Compile list of status code issues / additional issues

From: Thierry MICHEL <tmichel@w3.org>
Date: Mon, 11 Jun 2012 12:20:44 +0200
Message-ID: <4FD5C67C.6060708@w3.org>
To: tmichel@w3.org
CC: "Höffernig, Martin" <Martin.Hoeffernig@joanneum.at>, "public-media-annotation@w3.org" <public-media-annotation@w3.org>, "Bailer, Werner" <werner.bailer@joanneum.at>

Remains now the third category that we may want to naildown before going 
to PR

 > I made the observation
 > that some JSON response documents are not in sync with the
 > corresponding ontology examples.
 >
 > Therefore, MediaAnnotation objects include data which are not
 > present in the corresponding ontology document.
 >
 > I thought that the ontology documents should be the basis for the
JSON
 > responses?
 >
 > Concerning formats:
 >
 > EBUCore, Exif, ID3, LOM, MediaRSS, TV-Anytime




Could you precise which data are out of sync ?

How should we resolve it:
Should we update the output (the JSON Files) or the input (example and 
the RDF files in the Ontology testsuite?

Best,

thierry












Le 11/06/2012 11:55, Thierry MICHEL a écrit :
> Martin,
>
>
> With the previous publication of your updated JSON files, I have also
> updated these with the proper status code 200, as requested bellow.
>
>
> This should now close the issue for the category 1 and 2.
>
> Best,
>
> thierry.
>
> Le 05/06/2012 12:52, Höffernig, Martin a écrit :
>>
>> Dear all,
>>
>> I have reviewed the API status codes [1] in the normative JSON files
>> of the testsuite implementation [2] and I found some issues that
>> should be addressed.
>> All of these issues are related to the usage of status code 206
>> (partial content).
>> For me, 206 is misused in many cases since its semantics is possibly
>> not quite clear.
>>
>> I think, 206 should be returned in cases where only partial data of
>> available data for a media resource is returned.
>> For example, when requesting the FrameSize property and Height will be
>> returned only, while data about Width is available as well should
>> result in status code 206.
>> On the other side, when retrieving a location property for which the
>> name of the location (locationLabel) is available only - further
>> information like latitude and longitude is not available -
>> I suggest to return status code 200 (OK), since all the available
>> information will be returned.
>>
>> Taken my interpretation of the usage of satus code 206 into account, I
>> suggest to change the status code 206 to 200 in for the following
>> MediaAnnotation objects:
>> DIG35:
>> Location, Copyright
>
> Done.
>
>> DublinCore:
>> Contributor, MADate, Location, Relation, Copyright
>
> Done.
>
>> EBUCore:
>> Locator, Location, Creator, Relation, TargetAudience, NamendFragment,
>> Fragment, FrameSize
>
> Done.
>
>> Exif:
>> Copyright, FrameSize
>
> Done.
>
>> ID3:
>> Contributor
>
> Done.
>
>> YouTube:
>> TargetAudience
> Done.
>
>> IPTC:
>> Location, Copyright, Policy, TargetAudience, Fragment, FrameSize
>
> Done.
>
>> LOM 2.1:
>> FrameSize
> Done.
>
>> Media RSS:
>> Location, Rating, Copyright, Policy, FrameSize
> Done.
>
>
>
>> TV-Anytime:
>> Relation, TargetAudience
> Done.
>
>
>> TXFeed:
>> Copyright
> Done.
>
>> XMP:
>> Contributor, Creator, MADate, Location, Rating, Relation, Copyright,
>> Policy
> Done.
>
>> YouTube:
>> TargetAudience
>
> already Done from above.
>>
>> Furthermore, I suggest that in a JSON response, MediaAnnotation
>> objects should only contain attributes with associated values.
>> For example, in the following MediaAnnotation object, the attributes
>> language, fragmentIdentifer, typeLink, and typeLabel should be
>> removed, since no value is available for these attributes.
>> { "Title" : {
>> "propertyName" : "title",
>> "value" : "Oasis Concert Stage @ I Am A Walrus",
>> "language" : "",
>> "sourceFormat" : "dig35",
>> "fragmentIdentifier" : "",
>> "mappingType" : "exact",
>> "titleLabel" : "Oasis Concert Stage @ I Am A Walrus",
>> "typeLink" : "",
>> "typeLabel" : "",
>> "statusCode" : 200
>> }
>>
>> This issue applies to many MediaAnnotation objects in following
>> documents:
>> DIG35, Dublin Core, EBUCore, Exif, ID3, IPTC, LOM, MediaRSS, DMS-1,
>> TV-Anytime, TXFeed, XMP, YouTube
>>
>> Moreover, while examining the status codes, I made the observation
>> that some JSON response documents are not in sync with the
>> corresponding ontology examples.
>> Therefore, MediaAnnotation objects include data which are not present
>> in the corresponding ontology document.
>> I thought that the ontology documents should be the basis for the JSON
>> responses?
>> Concerning formats:
>> EBUCore, Exif, ID3, LOM, MediaRSS, TV-Anytime
>>
>> [1]:
>> http://www.w3.org/TR/2011/WD-mediaont-api-1.0-20111122/#api-status-codes
>> [2]:
>> http://www.w3.org/2008/WebVideo/Annotations/wiki/TestSuite_implementation
>>
>> Hope my observation scan help to improve the JSON documents.
>>
>> Best,
>> Martin
>> --
>> Martin Höffernig
>> Audiovisual Media Group
>> DIGITAL - Institute for Information and Communication Technologies
>>
>> JOANNEUM RESEARCH Forschungsgesellschaft mbH
>> Steyrergasse 17, 8010 Graz, AUSTRIA
>>
>> phone: +43-316-876-1184
>> general fax: +43-316-876-1191
>> web: http://www.joanneum.at/digital
>> e-mail:
>> martin.hoeffernig@joanneum.at<mailto:martin.hoeffernig@joanneum.at>
>>
>>
Received on Monday, 11 June 2012 10:21:05 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 11 June 2012 10:21:06 GMT