- From: Bailer, Werner <werner.bailer@joanneum.at>
- Date: Mon, 18 Jun 2012 18:23:49 +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>
Dear Thierry, all,
Martin just spotted 2 mistakes in my earlier mail (thanks!):
> copyrightedBy
The property is called copyright.
> - The YT issue with keyframe
This should of course say keyWORD.
Best regards,
Werner
> -----Ursprüngliche Nachricht-----
> Von: Bailer, Werner
> Gesendet: Montag, 18. Juni 2012 17:12
> An: 'tmichel@w3.org'; Höffernig, Martin
> Cc: public-media-annotation@w3.org
> Betreff: AW: AW: AW: AW: [ACTION-472] Compile list of status code issues /
> additional issues
>
> 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 16:24:26 UTC