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

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

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



Received on Wednesday, 6 June 2012 11:23:25 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 6 June 2012 11:23:26 GMT