RE: Initial draft of Use Cases and Requirements for Media Ontology 1.0

Dear Veronique, all,

Here is my attempt to come up with more detailed requirements derived from the CH use case:

- covering the scope of basic standards such as DC library application profile
- support for different realisations and version of content and instances thereof
- support for concept of collections (eg news broadcast containing news stories, series of programme containing episodes) and relations between content items (movie, making of, documentation about director, etc.), this includes cross-media relations (eg photographs related to a performance of an orchestra, of which the recording is available)
- use of controlled vocabulary for several metadata fields
- support for dynamic metadata over space and/or time

I hope that contributes to the clarification of this UC, let us know your thoughts/comments.

Best regards,
Werner

> -----Original Message-----
> From: vmalaise@few.vu.nl [mailto:vmalaise@few.vu.nl] 
> Sent: Dienstag, 11. November 2008 11:49
> To: Felix Sasaki
> Cc: Bailer, Werner; Troncy, Raphael; 이원석; 
> public-media-annotation@w3.org
> Subject: Re: Initial draft of Use Cases and Requirements for 
> Media Ontology 1.0
> 
> Hello Felix, Werner, Raphael, all,
> 
> I do agree with your comments (and with Raphael's comments, I 
> was waiting for 
> other people to express their opinion to gather a "set" of 
> remarks :) ), here 
> some answers on some points:
> 
> - about the requirements to be more explicitly stated in the 
> CH use case: I 
> found it hard to derive requirements that would be explicitly 
> and exclusively 
> related to this use case, as as you and/or Raphael has/ve 
> pointed out, the 
> requirements there can also apply to other use cases.
> - about defining better the notion of "bridging the gap" into 
> "not full 
> compatibility but supporting a wide common subset and 
> defining appropriate 
> mappings", I totally agree and I find this phrasing quite good!
> - about the Ontology being the main mean for interoperability 
> and the API being 
> a tool to use it, I totally agree too and I will have to 
> rewrite the section if 
> the readers can understand something else about it!
> - about splitting the list of tasks: the first list was an 
> initial proposal, I 
> am more than open to redesign the list, by taking into 
> account everyone's 
> opinion about "minimal" or "complex" tasks.
> 
> About re-organising the document:
> what would you all think about 
> - integrating the 3 dimensions (media, content, context) in 
> the introduction, as 
> 3 ways of apprehending media documents (Frank and Werner, I 
> would need your help 
> about this, if it is OK with you?), 
> - along with a list of tasks (here again, I realized that the 
> notion of context 
> can be unclear when really writing the document: is the task 
> the context, or the 
> fact that the annotations are performed for displaying on a 
> mobile phone, 
> searching in large archives, integrating Internet information 
> with IPTV?)
> - and organizing the use cases into the following subsections: 
>  - "media related use cases" (video and audio use case), 
>  - "task related use cases" (annotation use case, 
> personalization use 
> case?)
>  - "context related use case" (mobile use case, Cultural 
> heritage use 
> case, IPTV? -I don't know whether it should fit here or as a 
> personalization use 
> case-)
> "content related use cases" should be out of scope, if I 
> understand correctly 
> the notion of "content" as the "physical characteristics of 
> the media", is it 
> correct? This is what I was trying to state with the 
> ambiguous word of 
> "content", which was indeed used for denoting "semantic 
> content" (in scope) and 
> "physical characteristics" (out of scope), I had not realized 
> that it could be 
> ambiguous, so: thanks for pointing this out, Raphael, and... 
> do you agree with 
> the fact that describing the physical content of a media is 
> out of this WG's 
> scope? I'll try to ask for +/-1 this evening :)
> 
> This dispatching into subsections would make the writing (and 
> reading of the 
> document) easier as the title itself would already contain 
> one dimension, and it 
> would disambiguate the notion of "context"... if ever I got 
> this notion right?
> 
> Best regards,
> Veronique
> 
> Quoting Felix Sasaki <fsasaki@w3.org>:
> 
> > Hello Werner, all,
> > 
> > I agree with your comments and have a remark to one of them.
> > 
> > Bailer, Werner さんは書きました:
> > > Dear all,
> > >
> > > My comments concern the following issues:
> > >
> > > - tagging / tagging vs. CH:
> > > I agree to Raphaels view that the actual alignment of 
> tags is out of scope
> > for the media ontology, just as the alignment of different 
> vocabularies in
> > the CH use case. This would prevent the goal of creating a general
> > lightweight ontology. However, as pointed out by Raphael, 
> interoperability
> > ontologies designed for tagging should be supported.
> > >
> > > - requirements from CH use cases:
> > > Yes, the requirements should be stated more clearly, I 
> can work on that
> > later this week. While the interop issue is crucial in this 
> use case it
> > probably cannot be directly translated into an interop 
> requirement for the
> > ontology and/or API.
> > >
> > > - requirements summary (section 4):
> > > 1. standards: it should be stated what we understand here 
> by bridging, i.e.
> > not full compatibility but supporting a wide common subset 
> and defining
> > appropriate mappings
> > > 3. same comment about bridging; I suggest to drop the 
> reference to the CH
> > use case here, as IMO the requirement of 
> deploying/displaying metadata
> > aligned with content is broader and comes from other use 
> cases as well  
> > > 5. I am not sure about the role of the API w.r.t 
> interoperability. I see
> > the role of the API rather as access point to the ontology 
> we are developing,
> > but not something that implements mapping. In the media 
> ontology properties
> > have well defined meaning, and well defined mappings are 
> described in the
> > specification, but not built into the API (at least not in 
> a core part). I
> > also suggest to replace the term "tag" with "property" in 
> this sentence.
> > >   
> > 
> > I agree with the terminology "property" instead of "tag" 
> and with the 
> > design you describe: mapping is defined in the ontology, the API is 
> > *one* access point to it. I tried to exemplify this with 
> this example:
> > createDate property in the ontology, including mappings 
> > 
> http://dev.w3.org/cvsweb/~checkout~/2008/video/mediaann/mediaont-api-

> 1.0/mediaont-api-1.0.html?rev=1.10#property-createDate
> > getDate method from the API, which only references mappings
> > 
> http://dev.w3.org/cvsweb/~checkout~/2008/video/mediaann/mediaont-api-

> 1.0/mediaont-api-1.0.html?rev=1.10#method-getDate
> > of course the question now arises what "well defined meaning of 
> > properties" is. But I put this out of this thread for now.
> > 
> > Felix
> > 
> > > Best regards,
> > > Werner 
> > >
> > >   
> > >> -----Original Message-----
> > >> From: public-media-annotation-request@w3.org 
> > >> [mailto:public-media-annotation-request@w3.org] On Behalf Of 
> > >> vmalaise@few.vu.nl
> > >> Sent: Montag, 10. November 2008 10:47
> > >> To: Troncy, Raphael
> > >> Cc: 이ì>ì"; public-media-annotation@w3.org; 
> Felix Sasaki
> > >> Subject: Re: Initial draft of Use Cases and Requirements for 
> > >> Media Ontology 1.0
> > >>
> > >>
> > >> Dear all,
> > >>
> > >> Thank you very much Raphael for these extensive comments! 
> > >> Indeed the questions 
> > >> were not intended to be left in the later version of the Note 
> > >> (and I did not 
> > >> change the preambule part as Felix said that we should focus 
> > >> only on the content 
> > >> as for now), but were directed to our group's members, to get 
> > >> people's opinion 
> > >> and clarification about the different mentioned points. 
> > >> And you are perfectly right that we should put the document 
> > >> online and refer to 
> > >> its URL, but so far I could not get the CVS environment 
> > >> running, my bad! Wonsuk, 
> > >> if you were more successful, could you take care of putting 
> > >> the draft at the 
> > >> right place and send around the URL? Thanks a lot and sorry 
> > >> about the delay 
> > >> (just got a Mac and I'm trying to figure out what is missing 
> > >> in the environment 
> > >> that I have!)!
> > >>
> > >> Best regards,
> > >> Vero 
> > >>
> > >> Quoting Raphaël Troncy <Raphael.Troncy@cwi.nl>:
> > >>
> > >>     
> > >>> Dear Wonsuk, Felix, all,
> > >>>
> > >>>       
> > >>>> Please find and review the closed file that is initial 
> > >>>>         
> > >> draft of Use 
> > >>     
> > >>>> Cases and Requirements for Media Ontology 1.0.
> > >>>> If you have any comments or opinion, please let me know.
> > >>>>         
> > >>> Please, find below my review for this document. This is a 
> > >>>       
> > >> mix of typos I 
> > >>     
> > >>> have noticed and questions and comments I have ...
> > >>>
> > >>> For the future versions, could we put them on the web 
> with a proper 
> > >>> revision number to reference and just distribute URIs 
> > >>>       
> > >> instead of (html) 
> > >>     
> > >>> attachments?
> > >>>
> > >>> * Abstract: 'ontolgoy' -> ontology
> > >>>
> > >>> * Status of this document: it is outdated for this 
> > >>>       
> > >> document. I think it 
> > >>     
> > >>> is aimed to be a Working Group Note rather than a Rec.
> > >>>
> > >>> * Section 1: 'concret' -> concrete
> > >>>
> > >>> * Section 2.1: Overview
> > >>>    - The 3 dimensions fall a bit from the sky, making the 
> > >>>       
> > >> reading a bit 
> > >>     
> > >>> dry. Is it possible to add some references showing 
> where these 3 
> > >>> dimensions come from?
> > >>>    - The current text contains a lot of questions ... "for 
> > >>>       
> > >> us", so I 
> > >>     
> > >>> guess not meant for the working draft reader. Are they? For 
> > >>>       
> > >> example: 
> > >>     
> > >>> should we keep the sentence: "Taking in consideration what 
> > >>>       
> > >> the cognitive 
> > >>     
> > >>> power of a medium is might help us to distill the basics to 
> > >>>       
> > >> be described 
> > >>     
> > >>> to achieve the widest coverage"? Or should be turn it into 
> > >>>       
> > >> something 
> > >>     
> > >>> like: "Taking in consideration what the cognitive power of 
> > >>>       
> > >> a medium is 
> > >>     
> > >>> enables to distill the basics to be described to 
> achieve the widest 
> > >>> coverage"?
> > >>>    - Similarly, the text that describes the 3rd dimension 
> > >>>       
> > >> (the task) 
> > >>     
> > >>> contains numerous questions. Would we like to keep them as 
> > >>>       
> > >> it is? It 
> > >>     
> > >>> seems to me that the text should answer to these 
> questions and not 
> > >>> exposed to the reader of the document.
> > >>>    - The last sentence of the 5th paragraph is ambiguous: 
> > >>>       
> > >> "The scope of 
> > >>     
> > >>> the Media ontology 1.0 is limited to content description". 
> > >>>       
> > >> Do you mean 
> > >>     
> > >>> the physical content? the semantic content? both?
> > >>>    - What means DC at the end of the 6th paragraph? Is 
> there some 
> > >>> missing text? Is it a reference to the new working drafts 
> > >>>       
> > >> of Dublin Core 
> > >>     
> > >>> that envisages to have wh* relationships? Furthermore, 
> it would be 
> > >>> interesting to detail which explicit relationships the 
> standards 
> > >>> mentioned (CIDOC, MPEG-7, WHOS, MF) allow. Is it possible 
> > >>>       
> > >> to precise them?
> > >>     
> > >>>    - In the 6th paragraph: 'witout' -> without; 'connceted' 
> > >>>       
> > > -> connected
> > >   
> > >>> Furthermore, I suggest to rephrase the following sentence:
> > >>> "making links or graphs to connect the different pieces of the 
> > >>> annotation that belong together is very important for the 
> > >>> precision/enhancing the search".
> > >>>    - Is it a requirement of the Media Ontology to 
> enable relation 
> > >>> relationships?
> > >>>    - The 7th paragraph contains numerous questions that I 
> > >>>       
> > >> guess should 
> > >>     
> > >>> not be there but answered.
> > >>>
> > >>> * Section 2.2: Media
> > >>>    - Do we really consider all the media mentioned?
> > >>>    - Providing examples would help to understand what do 
> > >>>       
> > >> you mean by 
> > >>     
> > >>> 'static', 'interactive', 'fixed', 'mobile', 'realistic', 
> > >>>       
> > >> 'abstract', etc.
> > >>     
> > >>>    - The authors say that "Queries need to be enabled to 
> > >>>       
> > >> search on the 
> > >>     
> > >>> following dimensions:" but then I'm confused. The first two 
> > >>>       
> > >> dimensions 
> > >>     
> > >>> are about the subject matter, the semantic content, which I 
> > >>>       
> > >> thought was 
> > >>     
> > >>> address by the 2nd dimension (context). The 3rd one 
> introduces the 
> > >>> notion of form of the media. Why not then adding the 
> genre, another 
> > >>> component that is indispensable in EPG?
> > >>>
> > >>> * Section 2.3: Context
> > >>> The text ends abruptly, I guess there is some text missing.
> > >>>
> > >>> * Section 2.4: Task
> > >>>    - 'maintaining' -> maintain
> > >>>    - Add a reference to the canonical processes
> > >>>
> > >>> * Section 3.1: Video
> > >>>    - Which video services sites are you considering? 
> Video search 
> > >>> engines? Video sharing web sites? I think they have different 
> > >>> requirements ...
> > >>>    - I do not understand the problem explained in the 
> 2nd and 3rd 
> > >>> paragraph. What is the task? I guess the task is not to 
> > >>>       
> > >> specify what an 
> > >>     
> > >>> API should return for a particular command ... Getting 
> the songs 
> > >>> 'composed by' Dvorak? Then a full text search will work in 
> > >>>       
> > >> both cases.
> > >>     
> > >>>    - I disagree with the NOTE, as I believe the aim of 
> the Media 
> > >>> Ontology is to solve the semantic mismatch between the 
> > >>>       
> > >> existing formats 
> > >>     
> > >>> as much as possible.
> > >>>    - The last paragraph also introduces bad practices. 
> Do not split 
> > >>> properties (first name, family name, etc.) but just use 
> URIs for 
> > >>> identifying resources, and you get them for free.
> > >>>    - The requirements talked about "commonly used 
> properties for 
> > >>> describing video content, from these different 
> standards". Is it 
> > >>> possible to detail these properties that should be covered 
> > >>>       
> > >> by the Media 
> > >>     
> > >>> Ontology?
> > >>>
> > >>> * Section 3.2: Cultural Heritage
> > >>>    - I like the description of the use case but I do not 
> > >>>       
> > >> understand what 
> > >>     
> > >>> are the requirements. The requirements paragraph does 
> not seem to 
> > >>> exhibit any particular requirement, or at least, it is not 
> > >>>       
> > >> clear to me.
> > >>     
> > >>> * Section 3.3: Mobile
> > >>>    - 'foramts' -> formats
> > >>>    - Interoperability with formats for identification on 
> > >>>       
> > >> the Web seems a 
> > >>     
> > >>> requirement in this use case. Is it possible to list 
> these formats?
> > >>>
> > >>> * Section 3.4:
> > >>>    - I don't understand what this use case is about. Is 
> it about 
> > >>> "Interoperability for IPTV"? I would then suggest this 
> new title.
> > >>>    - The authors said: "In MPEG-7, there are parts 
> related to this 
> > >>> problem". Which parts the authors refer to?
> > >>>
> > >>> * Section 3.5: Tagging
> > >>>    - I think this use case is partially out of scope. I 
> > >>>       
> > >> explained: the 
> > >>     
> > >>> XG use case covers two sides of the coin. People tag on 
> different 
> > >>> platforms, and one concern would be to identify uniquely 
> > >>>       
> > >> these tags so 
> > >>     
> > >>> that they can be reused cross platforms. I think this part 
> > >>>       
> > >> is out of 
> > >>     
> > >>> scope for the Media Ontology, and some initiatives such as 
> > >>>       
> > >> TagCare deals 
> > >>     
> > >>> with that problem! The other side of the coin is the 
> > >>>       
> > >> properties that 
> > >>     
> > >>> allow the tagging such as the TAG ontology or MOAT. I think 
> > >>>       
> > >> the Media 
> > >>     
> > >>> Ontology should be interoperable with MOAT.
> > >>>
> > >>> * Section 3.6: Life Log
> > >>>    - What is this use case about? Is it possible to 
> > >>>       
> > >> describe it in terms 
> > >>     
> > >>> of the 3 dimensions (media, context, task) like the 
> other use cases?
> > >>>
> > >>> Hope that helps!
> > >>> Best regards.
> > >>>
> > >>>    Raphaël
> > >>>
> > >>> -- 
> > >>> Raphaël Troncy
> > >>> CWI (Centre for Mathematics and Computer Science),
> > >>> Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
> > >>> e-mail: raphael.troncy@cwi.nl & raphael.troncy@gmail.com
> > >>> Tel: +31 (0)20 - 592 4093
> > >>> Fax: +31 (0)20 - 592 4312
> > >>> Web: http://www.cwi.nl/~troncy/

> > >>>
> > >>>
> > >>>       
> > >>
> > >>
> > >>
> > >>     
> > 
> > 
> > 
> 
> 
> 
>

Received on Monday, 17 November 2008 16:15:42 UTC