W3C home > Mailing lists > Public > public-media-annotation@w3.org > December 2011

Re: [MAWG-API] Further issues (was: Status code 206)

From: Florian Stegmaier <stegmai@dimis.fim.uni-passau.de>
Date: Thu, 22 Dec 2011 09:09:42 +0100
Message-Id: <83CE8A9D-6D38-4CA4-89BF-5BF11E74A5C4@dimis.fim.uni-passau.de>
To: public-media-annotation@w3.org
Got it! I think these are more or less one of the first tasks to discuss in the next teleconf.

Cheers.
_____________________________
Dipl. Inf. Florian Stegmaier
Chair of Distributed Information Systems
University of Passau
Innstr. 43
94032 Passau

Room 248 ITZ

Tel.: +49 851 509 3063
Fax: +49 851 509 3062

stegmai@dimis.fim.uni-passau.de
https://www.dimis.fim.uni-passau.de/iris/
http://twitter.com/fstegmai
_____________________________

Am 22.12.2011 um 09:03 schrieb Bailer, Werner:

> Hi Florian,
> 
>>> - multiple identifiers for resources or fragments: In some source formats, it
>> could be possible to identify the resource or one of its fragments in multiple
>> ways, e.g. by one or more identifiers, fragment name or temporal/spatial
>> fragment URIs. In the RDF examples, this can be represented (as
>> recommended in the guidelines) by using owl:sameAs. For an API
>> implementation, we should require the querying by any of the valid
>> identifiers must be supported.
>> 
>> Sorry, i do not get it - could you please clarify this?
> 
> Example: you have a fragment, which has an actual identifier (e.g., a numeric ID in the source document), and there exists a temporal media fragment URI as well. When you query the API for metadata about the fragment using either of the two identifiers, the API should return the same result.
> 
>>> - Fragments without identifiers: There are source formats, which may
>> contain metadata about a fragment (e.g. a track) without specifying any kind
>> of identifier for it. For the test suite, a workaround is to add an identifier, in
>> order to ensure a reproducable test result. For the RDF representation this is
>> not a problem, as blank nodes can be used.
>>> In an actual API implementation, an identifier generated by the API would
>> have to be either deterministic or ensured to be valid for a certain time (e.g.
>> a session). Consider e.g. the following case: a client requests all metadata for
>> a video, and receives also metadata for the audio and video tracks. The tracks
>> do not have any identifier in the source file, so the API generated it. If the
>> client wants to query other metadata of these tracks later, it has to be
>> ensured that the identifiers generated by the API are still valid.
>> 
>> I agree - we should keep this in mind to add this information to the test suite
>> spec.
> 
> Not only, as this concerns the behaviour of the API, this should also go into the API doc.
> 
> Best regards,
> Werner
> 
>> -----Ursprüngliche Nachricht-----
>> Von: Florian Stegmaier [mailto:stegmai@dimis.fim.uni-passau.de]
>> Gesendet: Donnerstag, 22. Dezember 2011 07:08
>> An: public-media-annotation@w3.org
>> Betreff: Re: [MAWG-API] Further issues (was: Status code 206)
>> 
>> Hi Werner,
>> 
>> thank you for these comments, a mostly agree with them!
>> 
>>> - source format identifiers: The API document should contain a list of
>> recommended identifiers for the formats considered in the API document,
>> to ensure that uniform values are used for the source format (e.g., "mpeg7"
>> vs. "mpeg-7").
>> 
>> In addition we could link to the identifiers given in the ontology document.
>> 
>>> - status code 404: The use of this status code also needs clarification. We
>> propose the following: 404 should only be used when querying for specific
>> properties, in case that one/several of those are not contained in the
>> document. When quering for all properties, only those for which values exist
>> shall be returned, but not others with status 404.
>> 
>> +1
>> 
>>> - multiple identifiers for resources or fragments: In some source formats, it
>> could be possible to identify the resource or one of its fragments in multiple
>> ways, e.g. by one or more identifiers, fragment name or temporal/spatial
>> fragment URIs. In the RDF examples, this can be represented (as
>> recommended in the guidelines) by using owl:sameAs. For an API
>> implementation, we should require the querying by any of the valid
>> identifiers must be supported.
>> 
>> Sorry, i do not get it - could you please clarify this?
>> 
>>> - API doc section 4.4.1: fragmentIdentifier is defined as "This attribute
>> should be an URI determining the fragment for which the metadata is
>> relevant." We propose to be more precise here and require this to be a
>> complete URI, not just a fragment part.
>> 
>> +1
>> 
>>> - Fragments without identifiers: There are source formats, which may
>> contain metadata about a fragment (e.g. a track) without specifying any kind
>> of identifier for it. For the test suite, a workaround is to add an identifier, in
>> order to ensure a reproducable test result. For the RDF representation this is
>> not a problem, as blank nodes can be used.
>>> In an actual API implementation, an identifier generated by the API would
>> have to be either deterministic or ensured to be valid for a certain time (e.g.
>> a session). Consider e.g. the following case: a client requests all metadata for
>> a video, and receives also metadata for the audio and video tracks. The tracks
>> do not have any identifier in the source file, so the API generated it. If the
>> client wants to query other metadata of these tracks later, it has to be
>> ensured that the identifiers generated by the API are still valid.
>> 
>> I agree - we should keep this in mind to add this information to the test suite
>> spec.
>> 
>>> Best regards,
>>> Martin and Werner
>>> 
>>>> -----Ursprüngliche Nachricht-----
>>>> Von: Florian Stegmaier [mailto:stegmai@dimis.fim.uni-passau.de]
>>>> Gesendet: Mittwoch, 21. Dezember 2011 12:38
>>>> An: public-media-annotation@w3.org
>>>> Betreff: [MAWG-API] Status code 206
>>>> 
>>>> Dear all,
>>>> 
>>>> while creating the JSON responses it was quiet unclear, how the status
>> code
>>>> 206 should be used. I had a few discussions with Werner and Martin about
>>>> this. We have defined it as follows in the spec:
>>>> 
>>>> "206 - Partial Content - only a subset of the available data stored in the
>> result
>>>> set"
>>>> 
>>>> There are quiet a few ways, how it could be interpreted.
>>>> 
>>>> Currently, code 206 (partial content) seems to be use in cases, where not
>> all
>>>> fields of the response data structure are filled, as the information was not
>>>> present in the source document. IMO this is incorrect due to the following
>>>> reasons.
>>>> 
>>>> According to RFC2616, 206 is a partial GET request, i.e. only part of the
>>>> existing document is returned. Thus, 206 should in our case only be used.
>> If
>>>> only part of the information in the source document can be returned. If all
>>>> information from the source document is returned, 200 should be used,
>>>> even if this does not fill all possible return values.
>>>> 
>>>> It is the usual case, that not all return values can be filled (e.g., language
>> for
>>>> each and every property). Thus using not OK return code seems very
>>>> impractical, as an error status would be the default. Also, many of the
>>>> example JSON responses seem to fill these values with a kind of default
>>>> (e.g., set language to "en"). This should not be done, as it invents
>>>> information that is (i) not in the source document and (ii) optional. In such
>>>> cases, the respective attributes should not be returned.
>>>> 
>>>> To make this clear, the definition of this status code should be revised in
>> the
>>>> API document.
>>>> 
>>>> For the test suite, both files (RDF as well as the examples) have to be
>> taken
>>>> into account to ensure this behavior of 206. Further, we have to decide
>> how
>>>> we handle a "known" loss of information. This is the case if we have a
>>>> mapping into our core ontology where the according property in the
>> source
>>>> format is more specific.
>>>> 
>>>> Best regards,
>>>> Florian
>>>> _____________________________
>>>> Dipl. Inf. Florian Stegmaier
>>>> Chair of Distributed Information Systems
>>>> University of Passau
>>>> Innstr. 43
>>>> 94032 Passau
>>>> 
>>>> Room 248 ITZ
>>>> 
>>>> Tel.: +49 851 509 3063
>>>> Fax: +49 851 509 3062
>>>> 
>>>> stegmai@dimis.fim.uni-passau.de
>>>> https://www.dimis.fim.uni-passau.de/iris/
>>>> http://twitter.com/fstegmai
>>>> _____________________________
>>>> 
>> 
Received on Thursday, 22 December 2011 08:10:40 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 22 December 2011 08:10:40 GMT