Re: detailed comments on the use case and reqs 1.0 draft

Hello Dave, all,

would somebody object if I try to integrate the (non structural) comments?
That seems to be pretty straightforward.

Felix


2009/4/16 David Singer <singer@apple.com>

> Hi, after a read-through of <
> http://www.w3.org/TR/2009/WD-media-annot-reqs-20090119/> I have some
> detailed comments...
>
> 1:  change 'needs' to 'need'..."In addition, video services on the
> web...need..."
>
> 3:  below the diagram, change 'both' to 'either' (unless somehow the media
> resource is annotated in both formats at once):  "that will return values
> from either the XMP or IPTC metadata"
>
> 3:  The last paragraph, the words "applications, like:" and what follows
> would be better phrased as "applications.  For example:" and then follow
> with an HTML list (bulleted, probably).
>
> Requirement r4, I would change "custom" to "user-defined" or
> "non-standard", I think.
>
> 5.2: towards the end, "etc." is missing its "."
>
> 5.3:  this has the feel of having been edited a few times and the language
> is now a bit odd.  Can I suggest:
>
> People nowadays are able to enjoy large number of programs from different
> content providers (broadcasting companies, Internet video website, etc.). To
> achieve better user experience, reduce the user's experience of being
> overloaded, and hence retain users, some systems provide recommendations
> based on the user's history, ratings, or stated preferences. However,
> different content providers usually have their specific or proprietary
> metadata models, which is one of the key problems faced by recommendation
> service providers. A common ontology spanning different metadata sets can
> allow recommendation systems to return a better, larger, and more relevant
> selection than when the metadata systems are unrelated.
>
> Company A is an IPTV add-value service provider. One of their services is
> to recommend programs that users might like, based on their watching history
> or explicit rating of programs. In this system, users are able to watch
> regular TV programs with electronic program guide (EPG) format metadata,
> videos such as from YouTube, with website-specific metadata, etc. In order
> to perform uniform and effective recommendation in the absence of a common
> set of vocabularies, they would need to design own integrated media
> annotation model.
>
> 5.5:  the set over which "Find all" is not well identified, I assume it's
> "within a database, such as that of a search engine indexing the internet or
> other web-accessible content (e.g. a corporate repository, library, etc.)".
>
> 5.7:  I think there is a major use case that needs mentioning:
> accessibility.  There are requirements that for users who are unable to
> consume time-based media in general, or some formats in particular, the
> media data have annotations and links that express a summary, transcript,
> and so on.
>
> 6:  Requirements.  Very little is said here about the format of the
> returned result.  Most metadata systems are appallingly vague about the
> format of the stored data (often merely saying it's a string), even when the
> key suggests a restricted value set (e.g. "creation date").  This should
> probably be reflected in 6.13 requirement r13, "allow for
> undefined/unformatted return values for the same property" as well as the
> current text.
>
>
>
> More structural comments:
>
> security: we need to say we understand that user-agent access to metadata
> might give rise to cross-site scripting and other security issues, but that
> we expect those issues to be handled in the same way as the same issue for
> images and other embedded data.
>
> media ID:  we probably want to say that a major question both users and
> search engines might like to know is whether two pieces of media, two URLs
> etc. essentially are referring to the same content.  This can really only be
> done with a uniform media identifier system, and unfortunately there is none
> (despite ISRC etc.).
>
> time varying:  some metadata is naturally time-varying (e.g. "what chapter
> or scene of this movie am I in?") and the cue-ranges design of HTML5 is
> designed to support this (e.g. flipping slides to go with a video of someone
> speaking).  While I realize that many major metadata systems express
> time-invariant metadata ('for the whole file'), it might be prudent to
> document how we intend to handle this. It could be by using URLs that
> include fragment identifiers in the query (i.e. a script could find a URL on
> the page and explicitly add "#t=30s" to the end), or it could be by separate
> arguments to the API.  Some discussion of this captured in the document
> would be prudent, I think.
> --
> David Singer
> Multimedia Standards, Apple Inc.
>
>