- From: Evain, Jean-Pierre <evain@ebu.ch>
- Date: Tue, 2 Nov 2010 23:22:58 +0100
- To: "Evain, Jean-Pierre" <evain@ebu.ch>, Pierre-Antoine Champin <pierre-antoine.champin@liris.cnrs.fr>
- CC: Chris Poppe <Chris.Poppe@UGent.be>, "Bailer, Werner" <werner.bailer@joanneum.at>, "Höffernig, Martin" <Martin.Hoeffernig@joanneum.at>, Tobias Bürger <tobias.buerger@salzburgresearch.at>, "public-media-annotation@w3.org" <public-media-annotation@w3.org>
Pierre Antoine, Mea culpa, you are right the current model allows only one rating value per ratingProvider ID. Chris is right that different Ids are needed. Idon't like this very much as it makes ratingProvider act like a blank node in between the agent and the ratingValue. But I also don't want to have the ratingValue as a class. I am looking for an alternative. JP -----Original Message----- From: public-media-annotation-request@w3.org [mailto:public-media-annotation-request@w3.org] On Behalf Of Evain, Jean-Pierre Sent: mardi, 2. novembre 2010 14:20 To: Pierre-Antoine Champin Cc: Chris Poppe; Bailer, Werner; "Höffernig, Martin"; Tobias Bürger; public-media-annotation@w3.org Subject: RE : RE : RE : ma-ont RDF latest version see below ________________________________________ De : Pierre-Antoine Champin [pierre-antoine.champin@liris.cnrs.fr] Date d'envoi : mardi, 2. novembre 2010 14:16 À : Evain, Jean-Pierre Cc : Chris Poppe; Bailer, Werner; "Höffernig, Martin"; Tobias Bürger; public-media-annotation@w3.org Objet : Re: RE : RE : ma-ont RDF latest version On 11/02/2010 02:00 PM, Evain, Jean-Pierre wrote: > I need to look at all this but 'rating' SHOULD NOT / CANNOT be a > class (IMHO, this is a property). See earlier my example about the > database. Would you classify things by rating values, e.g. all the > resources that have received a rating value 5 then 4, etc. I don't > think so. I don't see how this is relevant... JPE: then we have a problem. But declaring 'rating' as a class is wrong! > In the examples given by Chris, the rating provider ID doesn't need > to change if it is the organisation lmdb that rates resources 1& 2 > with the same scale (max and min). Both resources could be rated by > lmd1. absolutely not! If you replace, in Chris' example, lmd2 with lmd1, then you whould have *two* different values for hasRatingValue ! Then how would you distinguish btw the rating of movie1 and the rating of movie2 ?? JPE: limd1 and lmd2 are the same! You can choose either name to give the same or differnet rating value to movie 1 or movie 2 ! Again, we are not using rating as a class for modelling reasons and the rating is provider through the rating provider. The example given by Chris is entirely coherent with my original proposal and I assure you that my comment is correct :-) pa > But it could be handy to abstarct the roganisation ot lmd2 is > the scale is different (why not after all). > > JP > > ________________________________________ De : Pierre-Antoine Champin > [pierre-antoine.champin@liris.cnrs.fr] Date d'envoi : mardi, 2. > novembre 2010 11:07 À : Chris Poppe Cc : Evain, Jean-Pierre; Bailer, > Werner; "Höffernig, Martin"; Tobias Bürger; > public-media-annotation@w3.org Objet : Re: RE : ma-ont RDF latest > version > > Oh, my bad indeed. So I *was* mistaken by the class labels. > > Ok on the general principle then. I also agree with JP that > RatingProvided (or whatever it is renamed to) should not be a > subclass of Contributor. > > And this amounts to making Rating a class, IMHO. > > pa > > On 11/02/2010 11:03 AM, Chris Poppe wrote: >> Dear all, >> >> as I understood a RatingProvider can only give one rating. It is >> connected to an Agent (Person or Organization) through the >> ratingProviderIs property. So something like this (?): >> >> :lmdb a ma:Organization ; >> >> :lmdb1 a ma:RatingProvider ; ma:ratingMin 0 ; ma:ratingMax 5; >> ma:ratingProviderIs lmdb . >> >> :lmdb2 a ma:RatingProvider ; ma:ratingMin 0 ; ma:ratingMax 5 ; >> ma:ratingProviderIs lmdb. >> >> :movie1 ma:hasBeenRatedBy :lmdb1 . :lmdb1 ma:ratingValue 3. >> >> :movie2 ma:hasBeenRatedBy :lmdb2 . :lmdb2 ma:ratingValue 5. >> >> >> Kind regards, Chris >> >> Quoting "Pierre-Antoine >> Champin"<pierre-antoine.champin@liris.cnrs.fr>: >> >>> On 11/01/2010 05:43 PM, Evain, Jean-Pierre wrote: >>>> Then I guess the easiest way is to also allow a property >>>> linking a rating provider to a fragment, which our new model >>>> allows. >>> >>> I think I agree with Marting and Werner that something there is >>> a problem in the current ontology (and I see it both in >>> TargetAudienceAuthory and RatingProvider). >>> >>> Imagine that I want to state that LinkedMDB rates movie1 3/5 and >>> movie2 5/5 . How would you state that in RDF? As I understand the >>> ontology, this would be >>> >>> :lmdb a ma:RatingProvider ; ma:ratingMin 0 ; ma:ratingMax 5 . >>> >>> :movie1 ma:hasBeenRatedBy :lmdb . :lmdb ma:ratingValue 3. >>> >>> :movie2 ma:hasBeenRatedBy :lmdb . :lmdb ma:ratingValue 5. >>> >>> which is obviously broken, as the four last triples can be >>> rewritten like that: >>> >>> :movie1 ma:hasBeenRatedBy :lmdb . :movie2 ma:hasBeenRatedBy :lmdb >>> . :lmdb ma:ratingValue 3, 5. >>> >>> Again, the same problem raises with TargetAudienceAuthority. >>> >>> So either I'm mislead by the labels of the ontologies (in which >>> case I suggest they are renamed) or the ontology is broken... I >>> would prefer to write something like >>> >>> :movie1 ma:hasRating [ ma:ratingValue 3 ; ma:ratingMin 0 ; >>> ma:ratingMax 5 ; ma:hasRatingAuthority :lmdb ] >>> >>> which is much closer to the Json specified by the API -- and yes, >>> it amounts to define a class for ratings. But frankly, I don't >>> see any other way to convey the same information as the API... >>> >>> pa >>> >>>> >>>> Don't you think so? >>>> >>>> Regards, JP >>>> >>>> ________________________________________ De : Bailer, Werner >>>> [werner.bailer@joanneum.at] Date d'envoi : lundi, 1. novembre >>>> 2010 17:27 À : Evain, Jean-Pierre; Höffernig, Martin; 'Chris >>>> Poppe' Cc : Tobias Bürger; public-media-annotation@w3.org Objet >>>> : RE: ma-ont RDF latest version >>>> >>>> Dear Jean-Pierre, >>>> >>>> I agree that describing rating providers is out of scope of >>>> MAWG. The motivation behind Martin's comment was the following >>>> scenario: Assume you have one RDF graph that containing the >>>> description of media resource and its fragments (resources >>>> themselves). Different of the fragments got different ratings >>>> from the same provider - how could you describe that? hasRated >>>> would always point to the same RatingProvider instance. >>>> >>>> Best regards, Werner >>>> >>>>> -----Original Message----- From: Evain, Jean-Pierre >>>>> [mailto:evain@ebu.ch] Sent: Samstag, 30. Oktober 2010 12:29 >>>>> To: Evain, Jean-Pierre; Höffernig, Martin; 'Chris Poppe' Cc: >>>>> Tobias Bürger; Bailer, Werner; public-media-annotation@w3.org >>>>> Subject: RE: ma-ont RDF latest version >>>>> >>>>> Dear Martin, >>>>> >>>>> As promised, let's continue the discussion about the rating >>>>> value. >>>>> >>>>> 1. If I understand well, the intention is likely to be able >>>>> to find other resources that the rating provider might have >>>>> reviewed because e.g. a user finds his rating accurate and >>>>> expect finding other content of interest based on the ranking >>>>> of the rating provider. Right? If yes, then the current >>>>> ontology allows making queries on all resources rated by the >>>>> rating provider even possibly adding a filter on certain >>>>> rating values. >>>>> >>>>> 2. If the intention of your comment is to develop an ontology >>>>> for the description of rating providers listing all their >>>>> ratings, this is not (at least directly - I believe) within >>>>> the scope of the MAWG. >>>>> >>>>> 3. There is a fundamental modelling issue with your proposal >>>>> to have a rating value to which would be associated >>>>> properties by the rating provider definition. This would >>>>> require a rating value to be a class and it is not advisable >>>>> (again - I believe) to make a class of what is fundamentally >>>>> a property. A question to help sorting this out: would you >>>>> have a database in which you would order the information per >>>>> rating value (each of them would then have an identifier, >>>>> which could be used to relate to them as classes)? - of >>>>> course I have my own opinion but would like to hear yours >>>>> ;-) >>>>> >>>>> In conclusion, my gut feeling is that the current >>>>> representation is accurate from a modelling perspective. Do >>>>> you really believe that it is not considering my explanations >>>>> above? >>>>> >>>>> Best regards, >>>>> >>>>> Jean-Pierre ________________________________________ De : >>>>> Höffernig, Martin [Martin.Hoeffernig@joanneum.at] Date >>>>> d'envoi : jeudi, 28. octobre 2010 14:27 À : Evain, >>>>> Jean-Pierre; 'Chris Poppe' Cc : Tobias Bürger; Bailer, >>>>> Werner; public-media-annotation@w3.org Objet : AW: ma-ont RDF >>>>> latest version >>>>> >>>>> Dear Jean-Pierre, Chris and all, >>>>> >>>>> just a few comments regarding the current ontology spec: >>>>> >>>>> Since TargetAudienceAuthority is no longer a sub class of >>>>> Contributor the object property targetAudienceAuthorityIs >>>>> shouldn't be a sub property of contributorIs as well. Leaving >>>>> this sub property relation would infer that the domain of >>>>> property targetAudienceAuthorityIs is Contributor, since >>>>> Contributor is domain of property contributorIs. >>>>> >>>>> As Chris wrote there is no direct connection between a >>>>> MediaResource and the value of TargetAudienceAuthority, the >>>>> same problem/pattern exists between a MediaResource and a >>>>> given rating value. Since a rating value is directly related >>>>> to a RatingProvider (via data property ratingValue), it is >>>>> not expressible that the same RatingProvider rates different >>>>> MediaResources (or MediaFragments) including different rating >>>>> values. I propose to directly connect a rating value to a >>>>> MediaResource and annotate this rating value with additional >>>>> information (RatingProvider, etc.). A new class RatingValue >>>>> would be necessary for this purpose. >>>>> >>>>> Best, Martin >>>>> >>>>> >>>>> -----Ursprüngliche Nachricht----- Von: >>>>> public-media-annotation-request@w3.org [mailto:public-media- >>>>> annotation-request@w3.org] Im Auftrag von Evain, Jean-Pierre >>>>> Gesendet: Montag, 25. Oktober 2010 10:11 An: 'Chris Poppe' >>>>> Cc: Tobias Bürger; Bailer, Werner; Davy Van Deursen; >>>>> public-media- annotation@w3.org Betreff: RE: ma-ont RDF >>>>> latest version >>>>> >>>>> Chris, >>>>> >>>>> As below and attached... Hope this answers the questions and >>>>> needs. >>>>> >>>>> Regards, >>>>> >>>>> Jean-Pierre >>>>> >>>>> >>>>> >>>>> -----Original Message----- From: Chris Poppe >>>>> [mailto:Chris.Poppe@UGent.be] Sent: dimanche, 24. octobre >>>>> 2010 21:10 To: Evain, Jean-Pierre Cc: Tobias Bürger; Bailer, >>>>> Werner; Davy Van Deursen; public-media- annotation@w3.org >>>>> Subject: RE: ma-ont RDF latest version >>>>> >>>>> Dear all, >>>>> >>>>> congrats with the excellent work, seems like we have a real >>>>> ontology instead of a property list now :). >>>>> >>>>> Some remarks: In the ontology specification the location >>>>> property is defined as the location where a resource is >>>>> created, developed, recorded, or otherwise authored. >>>>> Currently the ontology scheme only has a depictedLocation. So >>>>> maybe a ObjectProperty createLocation could be added? I guess >>>>> the depicted location is not in the ontology specification >>>>> since it could be described using the "description" >>>>> property? >>>>> >>>>> JPE: Although a location could be described in 'description', >>>>> it is the function of location to do this also as a linked >>>>> data hook (and I would says it would make more sense to >>>>> insist on what is shown that where it was developed?!?!). But >>>>> how? It seems the semantics gives a list of properties. We >>>>> could have a general property like 'hasRelatedLocation' >>>>> (which would be as vague as the way it is currently defined) >>>>> as a placeholder to Develop a series of subproperties: >>>>> depicted, created, developed, etc. >>>>> >>>>> >>>>> Could isImageRelatedTo be made a subproperty of isRelatedTo? >>>>> >>>>> JPE: No, not the same domain. But hasRelatedImage could be. >>>>> >>>>> >>>>> Could the link between the Data Property relation and the >>>>> Object Peropty isRelatedTo be formalized somehow? E.g., if a >>>>> MediaResource is used as the range of a isRelatedTo >>>>> objectproperty, it implies that a relation data property >>>>> should exist with the URI of that MediaResource? >>>>> >>>>> JPE: Good point. Actually, if the 'relation' is e.g. >>>>> 'source' (the source from which the mediaresource is derived) >>>>> , then 'source should be a subproperty of isRelatedTo. I have >>>>> used this as an example and removed the 'relation' >>>>> dataproperty. >>>>> >>>>> >>>>> There is no direct connection between a MediaResource and >>>>> the TargetAudienceAuthority. Do I interpret it correct that >>>>> to express that an organization has given a classification >>>>> "adult" to a mediaResource, we express this as: >>>>> a_MediaResource hasContributor a_TargetAudienceAuthority; >>>>> a_TargetAudienceAuthority targetAudienceAuthorityIs >>>>> a_Organization; a_TargetAudienceAuthority targetAudience >>>>> "Adult"; >>>>> >>>>> JPE: 1/ Yes, a few relations to some contributors were >>>>> missing inc. targetAudienceAuthority 2/ Yes again, the only >>>>> way to express different targetAudience e.g. using different >>>>> target audience schemes was to use the trick of linking the >>>>> property to the authority. BTW, I would suggest the authority >>>>> is no longer a subclass of contributor -> agree? >>>>> >>>>> >>>>> I think there is something missing to state that a >>>>> MediaFragment is a fragment of a specific MediaResource >>>>> (maybe isFragmentOf and hasFragment Object properties). >>>>> >>>>> JPE: Yes >>>>> >>>>> Maybe it's better to remove the namedFragmentUri data >>>>> property and create a fragmentName data property (like the >>>>> fragmentRole property). This way a namedFragment is a >>>>> MediaFragment with a fragmentName and the URI can be >>>>> retrieved through fragmentUri. >>>>> >>>>> JPE: That's what I suggested in a previous mail. Actually I >>>>> corrected the existing mediaFragmentName data property into >>>>> fragmentName. I have now kept only locator and renamed >>>>> fragmentUri into fragmentLocator (or we change locator in >>>>> mediaResourceUri :-). >>>>> >>>>> Kind regards, Chris >>>>> >>>>> Quoting "Evain, Jean-Pierre"<evain@ebu.ch>: >>>>> >>>>>> Dear Thierry, >>>>>> >>>>>> Almost a week without additional comment. I would >>>>>> therefore suggest that this becomes the new version of our >>>>>> RDF ontology. >>>>>> >>>>>> Thanks in advance for uploading it and replace the current >>>>>> published >>>>> version. >>>>>> >>>>>> Best regards, >>>>>> >>>>>> Jean-Pierre >>>>>> >>>>>> >>>>>> >>>>>> -----Original Message----- From: Evain, Jean-Pierre Sent: >>>>>> vendredi, 15. octobre 2010 06:19 To: Evain, Jean-Pierre; >>>>>> Tobias Bürger; Bailer, Werner Cc: Davy Van Deursen; >>>>>> public-media-annotation@w3.org Subject: RE : ma-ont RDF >>>>>> latest version >>>>>> >>>>>> Dear all, >>>>>> >>>>>> this is the new version with MediaFragment as a subclass >>>>>> of MediaResource, validated as OWL-DL. >>>>>> >>>>>> Please check and feedback. >>>>>> >>>>>> Best regards, >>>>>> >>>>>> Jean-Pierre >>>>>> >>>>>> >>>>>> ________________________________________ De : Evain, >>>>>> Jean-Pierre Date d'envoi : vendredi, 15. octobre 2010 02:09 >>>>>> À : Tobias Bürger; Bailer, Werner Cc : Davy Van Deursen; >>>>>> public-media-annotation@w3.org Objet : RE : ma-ont RDF >>>>>> latest version >>>>>> >>>>>> Thanks Tobias, all, >>>>>> >>>>>> There seem to be concensus. I'll work on a new version. >>>>>> >>>>>> I was thinking about namedFragment. Although the MFWG makes >>>>>> this disctinction, I wonder if we need to in MAWG as we >>>>>> would have a property 'name' that be be documented or not. >>>>>> Then the URI >>>>> attributed >>>>>> to the fragment would use an MFWG format or another, >>>>>> accordingly. >>>>>> >>>>>> I hope I'll find 5 minutes to do this today during my >>>>>> various >>>>> meetings. >>>>>> >>>>>> Regards, >>>>>> >>>>>> Jean-Pierre >>>>>> >>>>>> >>>>>> ________________________________________ De : Tobias >>>>>> Bürger [tobias.buerger@salzburgresearch.at] Date d'envoi : >>>>>> jeudi, 14. octobre 2010 18:20 À : Bailer, Werner Cc : >>>>>> Evain, Jean-Pierre; Davy Van Deursen; >>>>>> public-media-annotation@w3.org Objet : Re: ma-ont RDF >>>>>> latest version >>>>>> >>>>>> Dear all, >>>>>> >>>>>> given the definition of MF cited below, it makes sense to >>>>>> model MF >>>>> like that. >>>>>> >>>>>> Best, >>>>>> >>>>>> Tobias >>>>>> >>>>>> Am 14.10.2010 15:34, schrieb Bailer, Werner: >>>>>>> Dear Davy, Jean-Pierre, all, >>>>>>> >>>>>>> I agree with the proposal that a media fragment is a >>>>>>> subclass of media resource. >>>>>>> >>>>>>> Actually, this a clean way of modeling it, as we anyway >>>>>>> couldn't prevent someone from expressing that by using a >>>>>>> MFURI as the URI of >>>>> a >>>>>>> media resource. >>>>>>> >>>>>>> Best regards, Werner >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- From: >>>>>>>> public-media-annotation-request@w3.org >>>>>>>> [mailto:public-media- annotation-request@w3.org] On >>>>>>>> Behalf Of Evain, Jean-Pierre Sent: Donnerstag, 14. >>>>>>>> Oktober 2010 15:25 To: Davy Van Deursen Cc: >>>>>>>> public-media-annotation@w3.org Subject: RE : ma-ont RDF >>>>>>>> latest version >>>>>>>> >>>>>>>> Hi Davy, >>>>>>>> >>>>>>>> Thank for summarsing the semantics, that will help me >>>>>>>> answering the question... (I hope :-) >>>>>>>> >>>>>>>> [[ Therefore, we should first look at the definition of >>>>>>>> a media resource [1] and I believe that a media >>>>>>>> fragment falls under that definition (if not, please >>>>>>>> clarify why not): " A media resource is any physical or >>>>>>>> logical Resource that can be identified using a Uniform >>>>>>>> Resource Identifier (URI), as defined by [RFC 3986]) , >>>>>>>> which has or is related to one or more media content >>>>>>>> types." More specifically, a media fragment is a >>>>>>>> physical >>>>> resource, >>>>>>>> with a media content type (i.e., the same as its >>>>>>>> parent resource) and can be identified using a URI >>>>>>>> (i.e., a Media >>>>> Fragments >>>>>>>> URI).]] >>>>>>>> >>>>>>>> This is effectively the key question and I would >>>>>>>> inviote the whole MAWG to consider this question. >>>>>>>> >>>>>>>> My first intention would have been to have media >>>>>>>> fragment as a subclass of media resource composed of >>>>>>>> audio and video tracks. If >>>>> we >>>>>>>> all adopt and recognise more specifically that a >>>>>>>> fragment is a >>>>> media >>>>>>>> resource which is iodentified by a MFURI I am happy >>>>>>>> with this but the group needs to confirm what the >>>>>>>> mediaFragment is. Then we could name (namedFragment, >>>>>>>> itself a subclass of fragment) and keyword a fragment >>>>>>>> and give him a URI. That would be 'clean'. >>>>>>>> >>>>>>>> Then if the question arises of whether a media >>>>>>>> fragment is a subclass of media resource, I would >>>>>>>> answer that any media resource is an atomic media >>>>>>>> fragment. >>>>>>>> >>>>>>>> In other words, I personally can agree with what you >>>>>>>> suggest but would like to hear from the group. >>>>>>>> >>>>>>>> Tobias and team, what do you think? >>>>>>>> >>>>>>>> Best regards, >>>>>>>> >>>>>>>> Jean-Pierre ----------------------------------------- >>>>>>>> ************************************************** This >>>>>>>> email and any files transmitted with it are >>>>>>>> confidential and intended solely for the use of the >>>>>>>> individual or entity to whom >>>>> they >>>>>>>> are addressed. If you have received this email in >>>>>>>> error, please notify the system manager. This footnote >>>>>>>> also confirms that this email message has been swept by >>>>>>>> the mailgateway >>>>>>>> ************************************************** >>>>>>>> >>>>>>> >>>>>> >>>>>> -- >>>>>> ================================================================ >>>>>> >>>>>> Dr. Tobias Bürger Knowledge and Media Technologies Group >>>>>> Salzburg Research FON >>>>>> +43.662.2288-415 Forschungsgesellschaft >>>>>> FAX +43.662.2288-222 Jakob-Haringer-Straße 5/III >>>>>> tobias.buerger@salzburgresearch.at A-5020 Salzburg | >>>>>> AUSTRIA http://www.salzburgresearch.at >>>>>> >>>>>> >>>>>> ----------------------------------------- >>>>>> ************************************************** This >>>>>> email and any files transmitted with it are confidential >>>>>> and intended solely for the use of the individual or entity >>>>>> to whom they are addressed. If you have received this email >>>>>> in error, please notify the system manager. This footnote >>>>>> also confirms that this email message has been swept by the >>>>>> mailgateway >>>>>> ************************************************** >>>>>> >>>>> >>>>> >>>>> >>>>> -- Ghent University - Multimedia Lab Sint-Pietersnieuwstraat >>>>> 41 B-9000 Ghent, Belgium >>>>> >>>>> tel: +32 9 264 89 17 fax: +32 9 264 35 94 e-mail: >>>>> Chris.Poppe@ugent.be >>>>> >>>>> URL: http://multimedialab.elis.ugent.be >>>> >>> >>> >> >> >> >> -- Ghent University - Multimedia Lab Sint-Pietersnieuwstraat 41 >> B-9000 Ghent, Belgium >> >> tel: +32 9 264 89 17 fax: +32 9 264 35 94 e-mail: >> Chris.Poppe@ugent.be >> >> URL: http://multimedialab.elis.ugent.be >> >> >> >
Received on Tuesday, 2 November 2010 22:23:48 UTC