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/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 Friday, 15 June 2012 11:37:11 UTC