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

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

From: Thierry MICHEL <tmichel@w3.org>
Date: Mon, 11 Jun 2012 11:53:14 +0200
Message-ID: <4FD5C00A.8040708@w3.org>
To: "Höffernig, Martin" <Martin.Hoeffernig@joanneum.at>
CC: "public-media-annotation@w3.org" <public-media-annotation@w3.org>

Hi Martin,

I have uploaded your revised JSON  files at

http://www.w3.org/2008/WebVideo/Annotations/drafts/API10/JSON


I see that you have only taken care of category [2] updates.

I will now updates these files with category [1] (status code 
replacement 206 with 200).


I am not sure why you say there is a need to also update the TestSuite 
implementation page.
http://www.w3.org/2008/WebVideo/Annotations/drafts/API/implementation-report.html

Please check, and let me know if there is a need for it.

Thierry.

Le 06/06/2012 13:22, Höffernig, Martin a écrit :
> Dear all,
>
> the fixed JSON documents related to issue [2] are enclosed as a zip file
>
> Thierry, can you please upload these files and update the TestSuite implementation page?!
>
> Best,
> Martin
>
>> -----Ursprüngliche Nachricht-----
>> Von: Höffernig, Martin [mailto:Martin.Hoeffernig@joanneum.at]
>> Gesendet: Dienstag, 05. Juni 2012 15:07
>> An: Daniel Park; public-media-annotation@w3.org
>> Betreff: AW: [ACTION-472] Compile list of status code issues /
>> additional issues
>>
>> Dear Daniel, all
>>
>> as discussed with Werner, I will do a cleanup of all JSON examples to
>> ensure that only attributes with associated values [2] are included and
>> provide these fixed documents as soon as possible.
>>
>> Best,
>> Martin
>>
>>> -----Ursprüngliche Nachricht-----
>>> Von: Daniel Park [mailto:soohongp@gmail.com]
>>> Gesendet: Dienstag, 05. Juni 2012 14:00
>>> An: Höffernig, Martin
>>> Cc: public-media-annotation@w3.org; Bailer, Werner
>>> Betreff: Re: [ACTION-472] Compile list of status code issues /
>>> additional issues
>>>
>>> Thanks Martin for your valuable efforts.
>>>
>>> I split your suggestions as three categories like below.
>>>
>>> [1] status code replacement 206 with 200
>>>
>>> [2] JSON exaplme including only associated value
>>>
>>> [3] Ont document sync with JSON document
>>>
>>>
>>> During the call, we decided to deal with both [1] and [2] categories
>>> as soon as possible since these are related to the API  doc movement.
>>> After resolving those issues, we should ask Director for the API doc
>>> movement. Then [3] will be discussed later on.
>>>
>>> MAWG members:
>>> Please review Martin's suggestions particularly [1] and [2], and
>>> comments and feedbacks on the mailing list immediately. We will
>>> discuss them in the next teleconference and move the API doc forward
>>> PR accordingly.
>>>
>>>
>>> Martin:
>>> Regarding [2], could you give us more JSON examples like DIG35,
>> Dublin
>>> Core, EBUCore, Exif, ID3, IPTC, LOM, MediaRSS, DMS-1, TV-Anytime,
>>> TXFeed, XMP, YouTube ?  That might be very helpful for us to resolve
>>> this issue quickly.
>>>
>>>
>>>
>>> Regards, Daniel.
>>>
>>>
>>> On Tue, Jun 5, 2012 at 7:52 PM, Höffernig, Martin
>>> <Martin.Hoeffernig@joanneum.at>  wrote:
>>>>
>>>>
>>>> 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
>>>>
>>>> DublinCore:
>>>>
>>>> Contributor, MADate, Location, Relation, Copyright
>>>>
>>>> EBUCore:
>>>>
>>>> Locator, Location, Creator, Relation, TargetAudience,
>>>> NamendFragment, Fragment, FrameSize
>>>>
>>>> Exif:
>>>>
>>>> Copyright, FrameSize
>>>>
>>>> ID3:
>>>>
>>>> Contributor
>>>>
>>>> YouTube:
>>>>
>>>> TargetAudience
>>>>
>>>> IPTC:
>>>>
>>>> Location, Copyright, Policy, TargetAudience, Fragment, FrameSize
>>>>
>>>> LOM 2.1:
>>>>
>>>> FrameSize
>>>>
>>>> Media RSS:
>>>>
>>>> Location, Rating, Copyright, Policy, FrameSize
>>>>
>>>> TV-Anytime:
>>>>
>>>> Relation, TargetAudience
>>>>
>>>> TXFeed:
>>>>
>>>> Copyright
>>>>
>>>> XMP:
>>>>
>>>> Contributor, Creator, MADate, Location, Rating, Relation,
>> Copyright,
>>>> Policy
>>>>
>>>> YouTube:
>>>>
>>>> TargetAudience
>>>>
>>>>
>>>>
>>>> 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-
>>> cod
>>>> es
>>>>
>>>> [2]:
>>>>
>>>
>> http://www.w3.org/2008/WebVideo/Annotations/wiki/TestSuite_implementat
>>>> ion
>>>>
>>>>
>>>>
>>>> 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
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Soohong Daniel Park
>>> Samsung Electronics, SWC
Received on Monday, 11 June 2012 09:53:37 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 11 June 2012 09:53:38 GMT