- From: Bailer, Werner <werner.bailer@joanneum.at>
- Date: Mon, 18 Jun 2012 17:11:56 +0200
- To: "tmichel@w3.org" <tmichel@w3.org>, Höffernig, Martin <Martin.Hoeffernig@joanneum.at>
- CC: "public-media-annotation@w3.org" <public-media-annotation@w3.org>
Hi Thierry,
I've discussed the impact of the changes on the implementation with Martin and Florian. Here are our conclusions:
- The DC Copyright issue is the only one in DC that touches a required property. The JSON is correct, although but the value should be split in the RDF file (or assigned to copyrightedBy instead of copyrightHolder). As the implementation starts from the DC file, this does not impact the implementation.
- The YT issue with keyframe is an error in the JSON file (two strings put into one), the correct string is thus contained in the one returned (which obviously was used for checking the result). Correcting this does not impact the implementation report.
- The Date issues in both formats concern optionally returning the type of the date (creationDate). As this is optional, the test would still be passed if an implementation does not return the optional attribute.
- The same holds for the rating system type in YT.
- Location (in both formats) seems to be the most critical, as the correct JSON contains 0 for values not-existing in the source data. As the attribute is optional, omitting it in the response returned from the implementation would still result in a passed test, however not the case when it is returned with 0, when it is deleted from the JSON. While we think it would be cleaner to drop the attribute in cases where no value is there (as "0" IS somewhere), on could argue that the integer 0 is not a valid deg/min/sec nor floating point value, and thus is interpreted as undefined. This would avoid changes to the implementation. The alternative could be to introduce a weaker notion of passed for this case, that only concerns the mandatory attributes.
Best regards,
Werner
> -----Ursprüngliche Nachricht-----
> Von: Thierry MICHEL [mailto:tmichel@w3.org]
> Gesendet: Montag, 18. Juni 2012 08:53
> An: Höffernig, Martin
> Cc: public-media-annotation@w3.org
> Betreff: Re: AW: AW: AW: [ACTION-472] Compile list of status code issues /
> additional issues
>
> Martin,
>
> Modifying the DC and Youtube JSON results now as a direct impact on the
> result of our implementation report.
>
> It means also modifying the corresponding atomic JSON test cases, for
> which we currently have 2 "passed" implementations.
>
>
> Therefore, changing these JSON files also means changing the
> implementation.
>
> Is this something implementors are ready to do ?
>
> Thierry
>
>
>
>
>
> Le 15/06/2012 13:36, Höffernig, Martin a écrit :
> > 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
> /EBU
> >> 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
> /EBU
> >> 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</rd
> fs:la
> >> 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
> /EBU
> >> 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_format
> s/EB
> >> 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_format
> s/ID
> >> 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_format
> s/LO
> >> 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_format
> s/mr
> >> 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_format
> s/TV
> >> 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_implemen
> ta
> >>>>>>>> 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 15:12:28 UTC