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 Tuesday, 5 June 2012 13:10:18 UTC