- From: Thierry MICHEL <tmichel@w3.org>
- Date: Wed, 20 Jun 2012 12:02:41 +0200
- To: "Höffernig, Martin" <Martin.Hoeffernig@joanneum.at>
- CC: "public-media-annotation@w3.org" <public-media-annotation@w3.org>
Martin,
Thanks for the files,
see my publications as indicated in line
best,
thierry
Le 19/06/2012 14:36, Höffernig, Martin a écrit :
> Dear Thierry, all
>
> Please find enclosed the updated JSON and RDF files for DC and YT.
>
>
> DC (changes have been made in JSON as well as RDF):
> MADate:
> added "typeLabel": "creation date" in JSON.
JSON file published at
http://www.w3.org/2008/WebVideo/Annotations/drafts/API10/JSON/normative_json_ma_dc.json
and I also updated the JSON atomic files
http://www.w3.org/2008/WebVideo/Annotations/drafts/API/json-responses/da-date_ma_dc.json
http://www.w3.org/2008/WebVideo/Annotations/drafts/API/json-responses/Db-date_ma_dc.json
>
> Keyword:
> added language information (xml:lang="en") in RDF.
>
> Copyright:
> changed RDF property for copyright description from ma:isCopyrightedBy to ma:copyright.
RDF file published at
http://www.w3.org/2008/WebVideo/Annotations/drafts/metadata_formats/DC_example1.rdf
>
> YT (changes made in JSON only):
> MADate:
> added "typeLabel": "creation date" in JSON.
>
> Keyword:
> fixed keyword results in JSON according to RDF data.
>
> Rating:
> added ratingSystemLabel attribute for Rating in JSON.
JSON file published at
http://www.w3.org/2008/WebVideo/Annotations/drafts/API10/JSON/normative_json_ma_yt_oi.json
and I also updated the JSON atomic files
http://www.w3.org/2008/WebVideo/Annotations/drafts/API/json-responses/ya-date_ma_YT.json
http://www.w3.org/2008/WebVideo/Annotations/drafts/API/json-responses/ya-date_ma_YT.json
http://www.w3.org/2008/WebVideo/Annotations/drafts/API/json-responses/yb-date_ma_YT.json
http://www.w3.org/2008/WebVideo/Annotations/drafts/API/json-responses/ya-keyword_ma_YT.json
http://www.w3.org/2008/WebVideo/Annotations/drafts/API/json-responses/yb-keyword_ma_YT.json
http://www.w3.org/2008/WebVideo/Annotations/drafts/API/json-responses/ya-rating_ma_YT.json
http://www.w3.org/2008/WebVideo/Annotations/drafts/API/json-responses/yb-rating_ma_YT.json
>
>
> Best,
> Martin
>
>
>> -----Ursprüngliche Nachricht-----
>> Von: Höffernig, Martin [mailto:Martin.Hoeffernig@joanneum.at]
>> Gesendet: Montag, 18. Juni 2012 15:58
>> 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,
>>
>> 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</co
>>>> d
>>>>>> 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_implement
>>>> a
>>>>>>>>>> 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 Wednesday, 20 June 2012 10:03:17 UTC