- From: Thierry MICHEL <tmichel@w3.org>
- Date: Mon, 18 Jun 2012 08:52:45 +0200
- To: "Höffernig, Martin" <Martin.Hoeffernig@joanneum.at>
- CC: "public-media-annotation@w3.org" <public-media-annotation@w3.org>
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</rdfs: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_formats/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_formats/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_formats/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_formats/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_formats/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_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 06:53:06 UTC