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...

> 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 ??

   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 13:17:30 UTC