- From: Daniel Park <soohongp@gmail.com>
- Date: Tue, 5 Jun 2012 21:00:25 +0900
- To: Höffernig, Martin <Martin.Hoeffernig@joanneum.at>
- Cc: "public-media-annotation@w3.org" <public-media-annotation@w3.org>, "Bailer, Werner" <werner.bailer@joanneum.at>
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-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 > > -- Soohong Daniel Park Samsung Electronics, SWC
Received on Tuesday, 5 June 2012 12:09:18 UTC