- From: Evain, Jean-Pierre <evain@ebu.ch>
- Date: Sun, 17 Jun 2012 20:12:37 +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,
In order to correct the RDF and TTL:
Add the following namespace declaration
xmlns:EBUNMSCountryCode="http://www.ebu.ch/metadata/ontologies/skos/ebu_ISO3166CountryCodeCS#" in the RDF file
@prefix EBUNMSCityCode: <http://www.ebu.ch/metadata/ontologies/skos/EBUNMSCityCode#> . in the TTL file
Add in RDF
<rdf:Description rdf:about="EBUNMSCountryCode:VE"><rdf:type
rdf:resource="http://www.w3.org/ns/ma-ont#Location"/><rdfs:label
rdf:datatype="http://www.w3.org/2001/XMLSchema#string">VENEZUELA</rdfs:label></rdf:Description>
Add in TTL
<EBUNMSCountryCode:VE>
a ma-ont:Location ;
rdfs:label "VENEZUELA"^^<http://www.w3.org/2001/XMLSchema#string> .
Best regards,
Jean-Pierre
-----Original Message-----
From: Thierry MICHEL [mailto:tmichel@w3.org]
Sent: mardi, 12. juin 2012 12:41
To: "Höffernig, Martin"
Cc: public-media-annotation@w3.org
Subject: 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/EBUCoreXML_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/EBUCoreXML_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:label></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/EBUCoreXML_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/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>
>> ...
>> 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/EBUCoreXML_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/EBU
>> 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/ID3_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/LOM_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/mrss_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/TVAXML_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>
>>>>>>
>>>>>>
------------------------------------------------------------------------------
**************************************************
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error, please notify the system manager. This footnote also confirms that this email message has been swept by the mailgateway
**************************************************
Received on Sunday, 17 June 2012 18:13:12 UTC