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

Dear Thierry, all,

as announced in my last email, here are my comments regarding the JSON youtube result set:

MADate:
JSON:
{ "MADate" : {
  "propertyName" : "date",
  "value" : "2010-01-26T10:00:00Z",
  "sourceFormat" : "yt",
  "mappingType" : "exact",
  "date" : "2010-01-26T10:00:00Z",
  "statusCode" : 200
}

RDF:
<ma:creationDate rdf:datatype="http://www.w3.org/2001/XMLSchema#dateTime">
2010-01-26T10:00:00Z
</ma:creationDate>

Optional typeLabel attribute "creation date" missing JSON, although related information available in RDF.

Location:
JSON:
{ "Location" : {
  "propertyName" : "location",
  "value" : "35.669998 139.770004",
  "sourceFormat" : "yt",
  "mappingType" : "exact",
  "longitude" : 35.669998,
  "latitude" : 139.770004,
  "altitude" : 0,
  "statusCode" : 200
}

RDF:
<ma:Location>
  <ma:locationLongitude rdf:datatype="http://www.w3.org/2001/XMLSchema#decimal">
  35.669998
  </ma:locationLongitude>
  <ma:locationLatitude rdf:datatype="http://www.w3.org/2001/XMLSchema#decimal">
  139.770004
  </ma:locationLatitude>
</ma:Location>

No altitude data available in RDF, however altitude in JSON is set to zero.

Keyword:
JSON:

  { "Keyword" : {
    "propertyName" : "keyword",
    "value" : "SM ENTERTAINMENT Oh!",
    "sourceFormat" : "yt",
    "mappingType" : "exact",
    "keywordLabel" : "SM ENTERTAINMENT Oh!",
    "statusCode" : 200
    }
  },

RDF:
<ma:hasKeyword rdf:parseType="Resource">
  <rdfs:label>
    SM ENTERTAINMENT
  </rdfs:label>
</ma:hasKeyword>

<ma:hasKeyword rdf:parseType="Resource">
  <rdfs:label>
   Oh!
  </rdfs:label>
</ma:hasKeyword>

JSON Keyword "SM ENTERTAINMENT Oh!" is concation of 2 different keywords in RDF.
Seems to be a minor issue regarding the implementation report, since the JSON result sets for 3 remaining keywords have been returned correctly.


Rating:
JSON:
 { "Rating" : {
    "propertyName" : "rating",
    "value" : "4.6510544",
    "sourceFormat" : "yt",
    "ratingValue" : 4.6510544,
    "minimum" : 1,
    "maximum" : 5,
    "statusCode" : 200
    }
  },

<ma:hasRatingSystem rdf:parseType="Resource">
  <rdfs:label>
   higherBetter
  </rdfs:label>
</ma:hasRatingSystem>

Optional attribute ratingSystemLabel is not present in JSON result set, required data would be available in RDF.

> -----Ursprüngliche Nachricht-----
> Von: Höffernig, Martin [mailto:Martin.Hoeffernig@joanneum.at]
> Gesendet: Freitag, 15. Juni 2012 13:36
> An: tmichel@w3.org; public-media-annotation@w3.org
> Betreff: AW: AW: AW: [ACTION-472] Compile list of status code issues /
> additional issues
>
> Dear Thierry, all,
>
> here are my comments regarding the DC JSON result document:
>
> MADate:
> JSON:
>  { "MADate" : {
>     "propertyName" : "date",
>     "value" : "2007-01-06T00:00:00.00",
>     "sourceFormat" : "dc",
>     "mappingType" : "related",
>     "date" : "2007-01-06T00:00:00.00",
>     "statusCode" : 200
>     }
>
> RDF:
> <ma:creationDate
> rdf:datatype="http://www.w3.org/2001/XMLSchema#dateTime">
> 2007-01-06T00:00:00.00
> </ma:creationDate>
>
> Since this MADate result set refers to a creation date
> (ma:creationDate), typeLabel can be used to carry this information in
> addition to the current result set:
> "typeLabel": "creation date"
>
> Location:
> JSON:
>   { "Location" : {
>     "propertyName" : "location",
>     "value" : "Hennepin Technical College",
>     "sourceFormat" : "dc",
>     "mappingType" : "exact",
>     "locationLabel" : "Hennepin Technical College",
>     "longitude" : 0,
>     "latitude" : 0,
>     "altitude" : 0,
>     "statusCode" : 200
>     }
>
> RDF:
> <ma:createdIn>
>   <ma:Location>
>     <ma:locationName>
>       Hennepin Technical College
>     </ma:locationName>
>   </ma:Location>
> </ma:createdIn>
>
> Since there is no information about longitude, latitude, and altitude
> in RDF available, I suggest to remove these attributes in the
> corresponding JSON result set as well.
>
> Keyword:
> JSON:
>  { "Keyword" : {
>     "propertyName" : "keyword",
>     "value" : "Dublin Core Meta Tags",
>     "language" : "en",
>     "sourceFormat" : "dc",
>     "mappingType" : "exact",
>     "keywordLabel" : "Dublin Core Meta Tags",
>     "statusCode" : 200
>     }
> RDF:
> <ma:hasKeyword rdf:parseType="Resource">
>   <rdfs:label>
>     Dublin Core Meta Tags
>   </rdfs:label>
> </ma:hasKeyword>
>
> There is no language information about keyword in RDF, therefore I
> would suggest to remove the language attribute in the JSON result set.
>
>
> Copyright
> JSON
>  { "Copyright" : {
>     "propertyName" : "copyright",
>     "value" : "Copyright 2007, Alan Kelsey, Ltd. All rights reserved.",
>     "sourceFormat" : "dc",
>     "mappingType" : "related",
>     "copyrightLabel" : "Copyright 2007, Alan Kelsey, Ltd. All rights
> reserved.",
>     "statusCode" : 200
>     }
> RDF:
> <ma:isCopyrightedBy>
>   <ma:Organisation>
>     <rdfs:label rdf:datatype="http://www.w3.org/2001/XMLSchema#string">
>      Copyright 2007, Alan Kelsey, Ltd. All rights reserved.
>     </rdfs:label>
>   </ma:Organisation>
> </ma:isCopyrightedBy>
>
> DC:
> <dc:rights>
>  Copyright 2007, Alan Kelsey, Ltd. All rights reserved.
> </dc:rights>
>
> ma:isCopyrightedBy is used to describe the copyright holder not the
> copyright itself (copyrightLabel in JSON). Corresponding JSON attribute
> for ma:isCopyrightedBy is holderLabel.
> Moreover, a copyright.holder is optional, whereas copyright is required
> (http://www.w3.org/TR/2012/REC-mediaont-10-20120209/#core-property-
> lists).
> To solve this issue I suggest to turn the existing ma:isCopyrightedBy
> relation into a ma:copyright relation in RDF like this:
>
> <ma:copyright>Copyright 2007, Alan Kelsey, Ltd. All rights
> reserved.</ma:copyright>
>
> Another possible solution would be to split the orginal DC data about
> rights into 2 different RDF relations (ma:rights and
> ma:isCopyrightedBy).
>
>
> My comments about the youtube JSON result document should be available
> next Monday.
>
> Best,
> Martin
>
>
> > -----Ursprüngliche Nachricht-----
> > Von: Thierry MICHEL [mailto:tmichel@w3.org]
> > Gesendet: Dienstag, 12. Juni 2012 12:41
> > An: Höffernig, Martin
> > Cc: public-media-annotation@w3.org
> > Betreff: Re: AW: AW: [ACTION-472] Compile list of status code issues
> /
> > additional issues
> >
> > Martin,
> >
> >
> > OK it seems there are inconsistencies between the TTL, RDF and XML
> > examples.
> >
> > The TTL files are informative only.
> > The RDF files are normative and serves as the input to the API
> > outputting JSON Responses.
> >
> > Therefore RDF and JSON Files MUST be in Synch.
> >
> >
> > for example, let see this for the EBUCore tests
> >
> >
> > The XMl is incorrect (should not list VENEZUELA location) The RDF is
> > correct ( lists only VENEZUELA location) The TTL is correct ( lists
> > only VENEZUELA location) The JSON is incorrect (should not list
> > VENEZUELA location)
> >
> >
> > see explanation following.
> >
> >
> > the EBUCore XML
> > ---------------
> >
> http://www.w3.org/2008/WebVideo/Annotations/drafts/metadata_formats/EB
> > U
> > CoreXML_ITM528229_extended.xml
> >   ...
> > <coverage><spatial><location
> > typeLink="cptype:city"><name>CARACAS</name></location><location
> >
> typeLink="cptype:country"><name>VENEZUELA</name><code>country:VE</code
> > >
> > </location></spatial></coverage>
> >   ...
> >
> >
> > --> It provides the "VENEZUELA" location and the "CARACAS" location
> >
> > the EBUCore RDF
> > ---------------
> >
> http://www.w3.org/2008/WebVideo/Annotations/drafts/metadata_formats/EB
> > U
> > CoreXML_ITM528229_extended.owl
> >
> >   ...
> > <rdf:Description rdf:about="EBUNMSCityCode:CARACAS"><rdf:type
> > rdf:resource="http://www.w3.org/ns/ma-ont#Location"/><rdfs:label
> >
> rdf:datatype="http://www.w3.org/2001/XMLSchema#string">CARACAS</rdfs:l
> > a
> > bel></rdf:Description>
> >   ...
> > --> It does not provide the "VENEZUELA" location, only the "CARACAS"
> > location
> >
> > the EBUCore TTL
> > ---------------
> >
> http://www.w3.org/2008/WebVideo/Annotations/drafts/metadata_formats/EB
> > U
> > CoreXML_ITM528229_extended.ttl
> >
> >   ...
> > <EBUNMSCityCode:CARACAS>
> >        a       ma-ont:Location ;
> >        rdfs:label
> "CARACAS"^^<http://www.w3.org/2001/XMLSchema#string>
> > .
> >   ...
> >
> >
> > --> It does not provide the "VENEZUELA" location, only the "CARACAS"
> > location
> >
> >
> >
> >
> >
> >
> > the EBUCore JSON
> > ---------------
> >   ...
> >   { "Location" : {
> >        "propertyName" : "location",
> >        "value" : "CARACAS",
> >        "language" : "English",
> >         "sourceFormat" : "ebucore",
> >        "mappingType" : "exact",
> >        "locationLabel" : "CARACAS",
> >         "longitude" : 0,
> >         "latitude" : 0,
> >        "altitude" : 0,
> >         "statusCode" : 200
> >         }
> >       },
> >       { "Location" : {
> >        "propertyName" : "location",
> >         "value" : "VENEZUELA",
> >        "language" : "English",
> >         "sourceFormat" : "ebucore",
> >         "mappingType" : "exact",
> >         "locationLabel" : "VENEZUELA",
> >        "longitude" : 0,
> >         "latitude" : 0,
> >         "altitude" : 0,
> >         "statusCode" : 200
> >         }
> >      },
> >   ...
> >
> >
> > --> It provides the "VENEZUELA" location and the "CARACAS" location
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Le 12/06/2012 11:49, Höffernig, Martin a écrit :
> > > Thierry,
> > >
> > > please note that I assume that the corresponding ontology document
> > only - not the original metadata example - is the basis for creating
> > JSON response data sets for a given format.
> > >
> > > see my comments in-line.
> > >
> > >> -----Ursprüngliche Nachricht-----
> > >> Von: Thierry MICHEL [mailto:tmichel@w3.org]
> > >> Gesendet: Montag, 11. Juni 2012 16:04
> > >> An: Höffernig, Martin
> > >> Cc: public-media-annotation@w3.org
> > >> Betreff: Re: AW: [ACTION-472] Compile list of status code issues /
> > >> additional issues
> > >>
> > >> Martin,
> > >>
> > >> I would like to focus first on the DC and Youtube formats as these
> > >> are the 2 formats we use for the implementation report.
> > >>
> > >> But indeed we should fix the other formats and have the JSON
> > >> responses in Synch.
> > >>
> > >> I am not sure I understand all the issue raised.
> > >>
> > >> See my responses in line ...
> > >>
> > >>
> > >> Thierry
> > >>
> > >>
> > >> Le 11/06/2012 14:27, Höffernig, Martin a écrit :
> > >>> Dear Thierry, all,
> > >>>
> > >>> here is an incomplete list of issues regarding category 3:
> > >>>
> > >>> EBUCore:
> > >>> Location - 2 location data sets in JSON response, only 1 location
> > >>> present in ontology
> > >>
> > >> Not sure what the issue is. Both seem to have 2 occurences:
> > >> the EBUCore XML
> > >>
> > http://www.w3.org/2008/WebVideo/Annotations/drafts/metadata_formats/E
> > >> BU
> > >> CoreXML_ITM528229_extended.xml
> > >> ...
> > >> <coverage><spatial><location
> > >> typeLink="cptype:city"><name>CARACAS</name></location><location
> > >>
> > typeLink="cptype:country"><name>VENEZUELA</name><code>country:VE</cod
> > >> e>
> > >> </location></spatial></coverage>
> > >> ...
> > >> and the JSON
> > >> ...
> > >> { "Location" : {
> > >>       "propertyName" : "location",
> > >>       "value" : "CARACAS",
> > >>       "language" : "English",
> > >>       "sourceFormat" : "ebucore",
> > >>       "mappingType" : "exact",
> > >>       "locationLabel" : "CARACAS",
> > >>       "longitude" : 0,
> > >>       "latitude" : 0,
> > >>       "altitude" : 0,
> > >>       "statusCode" : 200
> > >>       }
> > >>     },
> > >>     { "Location" : {
> > >>       "propertyName" : "location",
> > >>       "value" : "VENEZUELA",
> > >>       "language" : "English",
> > >>       "sourceFormat" : "ebucore",
> > >>       "mappingType" : "exact",
> > >>       "locationLabel" : "VENEZUELA",
> > >>       "longitude" : 0,
> > >>       "latitude" : 0,
> > >>       "altitude" : 0,
> > >>       "statusCode" : 200
> > >>       }
> > >>     },
> > >> ...
> > >>
> > >
> > > Yes that's correct. However, in the corresponding ontology example
> >
> (http://www.w3.org/2008/WebVideo/Annotations/drafts/metadata_formats/E
> > B
> > UCoreXML_ITM528229_extended.ttl) only 1 location has been described,
> > namely EBUNMSCityCode:CARACAS (see below).
> > >
> > > <tag:ebu.ch,2011:528229>
> > >        ma-ont:createdIn<EBUNMSCityCode:CARACAS>  ;
> > >        ...
> > >
> > > <EBUNMSCityCode:CARACAS>
> > >        a       ma-ont:Location ;
> > >        rdfs:label
> > "CARACAS"^^<http://www.w3.org/2001/XMLSchema#string>  .
> > >
> > > Therefore, as the ontology document serves as the basis for the
> JSON
> > response, only CARACAS can be part of the JSON result set.
> > >
> > >>
> > >>> NamedFragment - NamedFragements in JSON, however no
> > >>> ma:hasNamedFragment relations in ontology
> > >>
> > >> the EBUCore XML
> > >>
> > http://www.w3.org/2008/WebVideo/Annotations/drafts/metadata_formats/E
> > >> BU
> > >> CoreXML_ITM528229_extended.xml
> > >>
> > >> in the Ontlogy exact mapping from
> > >> namedFragment      to      hasPart
> > >>
> > >
> > > Since there are no ma:hasNamedFragments relation in the ontology
> > example, no NamedFragments can be part of the JSON result. However,
> > ma:hasFragment relations exist, Fragment properties - not
> > NamedFragments - can be retrieved and part of the JSON response.
> > >
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>> Locator - property has been mixed up with Location, contains the
> > >>> same data
> > >>>
> > >>> Exif:
> > >>> FrameSize -  JSON contains 2 FrameSize data sets for same media
> > >>> resource, one FrameSize should refer to related thumbnail image
> > >>
> > >> Right the second relates to the thumbnail.
> > >>
> > >>
> > >>>
> > >>> ID3:
> > >>> Contributor - roleLabels for Contributor (e.g. "TCOM Composer")
> > >>> not present in ontology
> > >
> > >
> > > In the ID3 ontology example
> >
> (http://www.w3.org/2008/WebVideo/Annotations/drafts/metadata_formats/I
> > D
> > 3_bach.ttl) there is no further role information about contributors,
> > formalized as sub properties, available.
> > >
> > >>>
> > >>> LOM 2.1:
> > >>> FrameSize - present in JSON, no data available in ontology
> > >>> Duration
> > >>> - same issue
> > >>
> > >>
> > >> Not sure what the issue is:
> > >>
> > >> ma:frameSize       more general mapping to "size"
> > >>
> > >> lom example:
> > >> ...
> > >> <technical><size>1000</size>
> > >> ...
> > >>
> > >> lom Json:
> > >>
> > >>     { "FrameSize" : {
> > >>       "propertyName" : "frameSize",
> > >>       "value" : "1000",
> > >>       "language" : "English",
> > >>       "sourceFormat" : "lom21",
> > >>       "mappingType" : "more general",
> > >>       "width" : 0,
> > >>       "height" : 0,
> > >>       "statusCode" : 200
> > >>       }
> > >>     },
> > >>
> > >>
> > >> ma:duration  is exact mapping to duration
> > >>
> > >> there seems to be a bug here in the Lom example: the duration is
> in
> > a
> > >> comment:
> > >> ...
> > >> <!--duration><duration>1H</duration>
> > >>     </duration-->
> > >> ...
> > >>
> > >> Lom Json:
> > >>
> > >> The duration value set to zero seems wrong (should be one hour)
> > >>
> > >>    { "Duration" : {
> > >>       "propertyName" : "duration",
> > >>       "language" : "English",
> > >>       "sourceFormat" : "lom21",
> > >>       "fragmentIdentifier" : "exact",
> > >>       "duration" : 0,
> > >>       "statusCode" : 204
> > >>       }
> > >>     },
> > >>
> > >
> > > In the LOM ontology example
> >
> (http://www.w3.org/2008/WebVideo/Annotations/drafts/metadata_formats/L
> > O
> > M_sample_v1.ttl) there is no data about frame size as well as
> duration.
> > >
> > >>>
> > >>> Media RSS:
> > >>> Copyright - holderLink present in JSON, no information available
> > >>> in ontology
> > >>
> > >> Not sure what the issue is:
> > >>
> > >> ma:copyright       exact mapping to
> > >> "rss/channel/item/media:content/media:copyright"
> > >>
> > >>
> > >> MediaRSS example:
> > >> ...
> > >> <media:copyright url="http://blah.com/additional-info.html">2005
> > >> FooBar Media</media:copyright>  ...
> > >>
> > >> MediaRSS Json:
> > >> ...
> > >>     { "Copyright" : {
> > >>       "propertyName" : "copyright",
> > >>       "value" : "2005 FooBar Media",
> > >>       "language" : "en",
> > >>       "sourceFormat" : "mrss",
> > >>       "mappingType" : "exact",
> > >>       "copyrightLabel" : "2005 FooBar Media",
> > >>       "holderLink" : "http://blah.com/additional-info.html",
> > >>       "statusCode" : 200
> > >>       }
> > >> ...
> > >
> > > There is no ma:copyright relation in the corresponding ontology
> > document
> >
> (http://www.w3.org/2008/WebVideo/Annotations/drafts/metadata_formats/m
> > r
> > ss_sample_rdf.ttl ).
> > >
> > >>>
> > >>> TV-Anytime:
> > >>> TargetAudience - multiple targetAudience result sets present in
> > >>> JSON, only 1 target audience in ontology
> > >>
> > >> Not sure what the issue is:
> > >>
> > >> ma:targetAudience  related mapping to "Genre"
> > >>
> > >> TVA  example:
> > >>
> > >> ...
> > >> <Genre
> > >> href="urn:tva:metadata:cs:ContentCS:2005:3.1.1.1"><Name>Daily
> > >> news</Name></Genre><Genre
> > >> href="urn:tva:metadata:cs:ContentCS:2005:3.1.1.13"><Name>Weather
> > >> forecasts</Name></Genre><Genre
> > >>
> > href="urn:tva:metadata:cs:FormatCS:2005:2.1.1"><Name>Bulletin</Name><
> > >> /G
> > >> enre><Genre
> > >>
> > href="urn:tva:metadata:cs:IntentionCS:2005:1.2"><Name>INFORM</Name></
> > >> Ge
> > >> nre><Genre
> > >>
> > href="urn:tva:metadata:cs:ContentCS:2005:3.1.1.9"><Name>Sports</Name>
> > >> </
> > >> Genre>
> > >> ...
> > >>
> > >> TVA  Json:
> > >> ...
> > >> { "TargetAudience" : {
> > >>       "propertyName" : "targetAudience",
> > >>       "value" : "Weather forecasts",
> > >>       "language" : "EN-UK",
> > >>       "sourceFormat" : "tva",
> > >>       "mappingType" : "related",
> > >>       "audienceLink" :
> > "urn:tva:metadata:cs:ContentCS:2005:3.1.1.13",
> > >>       "audienceLabel" : "Weather forecasts",
> > >>       "statusCode" : 200
> > >>       }
> > >>     },
> > >>     { "TargetAudience" : {
> > >>       "propertyName" : "targetAudience",
> > >>       "value" : "Bulletin",
> > >>       "language" : "EN-UK",
> > >>       "sourceFormat" : "tva",
> > >>       "mappingType" : "related",
> > >>       "audienceLink" : "urn:tva:metadata:cs:FormatCS:2005:2.1.1",
> > >>       "audienceLabel" : "Bulletin",
> > >>       "statusCode" : 200
> > >>       }
> > >>
> > >> ...
> > >>
> > >
> > > Only 1 ma:TargetAudience instance in ontology docoument
> >
> (http://www.w3.org/2008/WebVideo/Annotations/drafts/metadata_formats/T
> > V AXML_2_MAONTRDF_20100914BBCNewsTF_pl_pi_prog22_extended.ttl )
> > available.
> > >
> > >
> > >>
> > >>>
> > >>> Since my list is incomplete, more sync issues are potentially
> > >> possible. Therefore I suggest to fully revise the JSON files and
> > >> update these files w.r.t the unchanged ontology files.
> > >>>
> > >>> Best,
> > >>> Martin
> > >>>
> > >>>
> > >>>> -----Ursprüngliche Nachricht-----
> > >>>> Von: Thierry MICHEL [mailto:tmichel@w3.org]
> > >>>> Gesendet: Montag, 11. Juni 2012 12:21
> > >>>> An: tmichel@w3.org
> > >>>> Cc: Höffernig, Martin; public-media-annotation@w3.org; Bailer,
> > >> Werner
> > >>>> Betreff: Re: [ACTION-472] Compile list of status code issues /
> > >>>> additional issues
> > >>>>
> > >>>>
> > >>>> Remains now the third category that we may want to naildown
> > >>>> before going to PR
> > >>>>
> > >>>>    >   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
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>> Could you precise which data are out of sync ?
> > >>>>
> > >>>> How should we resolve it:
> > >>>> Should we update the output (the JSON Files) or the input
> > >>>> (example and the RDF files in the Ontology testsuite?
> > >>>>
> > >>>> Best,
> > >>>>
> > >>>> thierry
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>> Le 11/06/2012 11:55, Thierry MICHEL a écrit :
> > >>>>> Martin,
> > >>>>>
> > >>>>>
> > >>>>> With the previous publication of your updated JSON files, I
> have
> > >>>>> also updated these with the proper status code 200, as
> requested
> > >> bellow.
> > >>>>>
> > >>>>>
> > >>>>> This should now close the issue for the category 1 and 2.
> > >>>>>
> > >>>>> Best,
> > >>>>>
> > >>>>> thierry.
> > >>>>>
> > >>>>> Le 05/06/2012 12:52, Höffernig, Martin a écrit :
> > >>>>>>
> > >>>>>> 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
> > >>>>>
> > >>>>> Done.
> > >>>>>
> > >>>>>> DublinCore:
> > >>>>>> Contributor, MADate, Location, Relation, Copyright
> > >>>>>
> > >>>>> Done.
> > >>>>>
> > >>>>>> EBUCore:
> > >>>>>> Locator, Location, Creator, Relation, TargetAudience,
> > >>>> NamendFragment,
> > >>>>>> Fragment, FrameSize
> > >>>>>
> > >>>>> Done.
> > >>>>>
> > >>>>>> Exif:
> > >>>>>> Copyright, FrameSize
> > >>>>>
> > >>>>> Done.
> > >>>>>
> > >>>>>> ID3:
> > >>>>>> Contributor
> > >>>>>
> > >>>>> Done.
> > >>>>>
> > >>>>>> YouTube:
> > >>>>>> TargetAudience
> > >>>>> Done.
> > >>>>>
> > >>>>>> IPTC:
> > >>>>>> Location, Copyright, Policy, TargetAudience, Fragment,
> > >>>>>> FrameSize
> > >>>>>
> > >>>>> Done.
> > >>>>>
> > >>>>>> LOM 2.1:
> > >>>>>> FrameSize
> > >>>>> Done.
> > >>>>>
> > >>>>>> Media RSS:
> > >>>>>> Location, Rating, Copyright, Policy, FrameSize
> > >>>>> Done.
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>> TV-Anytime:
> > >>>>>> Relation, TargetAudience
> > >>>>> Done.
> > >>>>>
> > >>>>>
> > >>>>>> TXFeed:
> > >>>>>> Copyright
> > >>>>> Done.
> > >>>>>
> > >>>>>> XMP:
> > >>>>>> Contributor, Creator, MADate, Location, Rating, Relation,
> > >>>>>> Copyright, Policy
> > >>>>> Done.
> > >>>>>
> > >>>>>> YouTube:
> > >>>>>> TargetAudience
> > >>>>>
> > >>>>> already Done from above.
> > >>>>>>
> > >>>>>> 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-
> > >>>> co
> > >>>>>> des
> > >>>>>> [2]:
> > >>>>>>
> > >>>>
> > >>
> > http://www.w3.org/2008/WebVideo/Annotations/wiki/TestSuite_implementa
> > >>>>>> tion
> > >>>>>>
> > >>>>>> 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<mailto:martin.hoeffernig@joanneum.at>
> > >>>>>>
> > >>>>>>

Received on Monday, 18 June 2012 13:58:53 UTC