Re: comments about the Use Case and Requirements document

Hello Veronique,

I cannot be on the call, but just my comments below. If you reach agreement
on everything, I would propose you just implement the changes in the draft.

2009/3/28 <vmalaise@few.vu.nl>

    Dear all,

    I think that the document is very nice now, but I still have a list of
comments.
    I copy-paste it below, -> means a rewriting proposition or a
question/comment
    that I have. Can the authors of the different use cases check out that I
    understood their text correctly and would the people of the group agree
with the
    proposed changes? What is your opinion about the questions/comments?

    Best regards,
    Véronique


    Purpose of the Ontology and the API
    The following figure visualizes the purpose of the ontology of the API
and their
    relation to applications.
    ->


+1




    Mobile use case:
    To be done or removed from the list (and all the references to this use
case)



Propose to remove it, this UC has slept for a looong time.




    Interoperability between Media resources across Cultural Heritage
Institutions
    Editorial note to be removed


+1.




    Recommendation across different media types


+1 to all comments  for this UC.



    One of their service is to recommend users potentially like programs
based on
    watching history or explicit rating on programs.
    -> One of their service is to recommend users programs that are
potentially
    close to their interests, based on watching history
    To recommend programs uniformly without a common set of vocabularies,
they need
    to design own integrated media annotation model.
    -> they have to design their own (integrated) media annotation model.

    Life Log



+1 to all comments  for this UC.



    A person captures his experience as well as their entire lives by
creating
    images, audios and videos in the web.
    "as well as their entire lives" ->
    "videos in the web" -> on the Web.
    They are namely a life logs today.
    -> These are called "Life Logs" nowadays.
    Those life logs are made by various information such as time, location,
    creator's profile, human relations, and even emotion.
    -> Those Life Logs contain various information
    In case the life logs are accessibly by means of the ontology, he/she
can easily
    and efficiently search for his/her personal life log information
    -> If accessed via an ontology providing links between the different
metadata
    used to describe these various information, a user could easily and
efficiently
    search for his or her personal Life Log information
    -> remove ", whenever necessary" at the end of the sentence.
    -> one question: are people only interested in their own data? Or also
other
    people's data? The latter would also make sense to me.



I agree, though I think the answer to this question does not create new
requirements or changes the UC a lot.





    Access via web client to metadata in heterogeneous formats
    Nevertheless it is mentioned separately since, different to other
requirements,
    its implementation requires only a small set of requirements.
    -> Nevertheless it is mentioned separately since, at the difference from
other
    requirements,
    Also, the purpose of this use case is not to require or to propose
developing a
    query language on its own. However, the ontology can be used as an input
for the
    development of such a language.
    -> these two sentences are quite unclear to me...


Let's drop these sentences, the figure in the document says it all.




    -> how is this use case different from the ex-Cultural Heritage use
case? It
    looks like a task-oriented description of the same use case to me...



Propose to add "The difference from this use case to the Cultural Heritage
use case is that the former is very strongly tied to the requirement of a
read-only client side API.", to make the difference clear.





    User generated Metadata
    -> I think that only one of the two examples would be sufficient.


+1.



    -> I do not see explicitely what the Media Ontology would bring to this
case:
    would it bridge the gap between the vocabularies and provide only one
interface
    for the personal annotation?


I agree with this concern.




    Requirements section
    6.3 Requirement r03: Providing in the API a means for supporting
structured
    annotations
    -> does the group still agree to implement this requirement?
    6.10 Requirement r10: Being able to describe fragments of media objects
    -> would this not be the purpose of the Media Fragment Working Group?

Yes. Still, let's keep this requirement here, to make obvious that we have a
strong interest and connection to the outcome of the fragments group.

Felix