- From: Höffernig, Martin <Martin.Hoeffernig@joanneum.at>
- Date: Wed, 6 Jun 2012 13:22:52 +0200
- To: "public-media-annotation@w3.org" <public-media-annotation@w3.org>, "tmichel@w3.org" <tmichel@w3.org>
- Message-ID: <CD9846F872C7874BB4E0FDF2A61EF09FEE76E10B4E@RZJC1EX.jr1.local>
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
Attachments
- application/x-zip-compressed attachment: normative_json_files.zip
Received on Wednesday, 6 June 2012 11:23:25 UTC