Re: RE : ma-ont RDF latest version

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 10:03:39 UTC