W3C home > Mailing lists > Public > public-media-annotation@w3.org > November 2010

Re: RE : ma-ont RDF latest version

From: Pierre-Antoine Champin <pierre-antoine.champin@liris.cnrs.fr>
Date: Tue, 02 Nov 2010 09:51:28 +0100
Message-ID: <4CCFD110.8050501@liris.cnrs.fr>
To: "Evain, Jean-Pierre" <evain@ebu.ch>
CC: "Bailer, Werner" <werner.bailer@joanneum.at>, "Höffernig, Martin" <Martin.Hoeffernig@joanneum.at>, 'Chris Poppe' <Chris.Poppe@UGent.be>, Tobias Bürger <tobias.buerger@salzburgresearch.at>, "public-media-annotation@w3.org" <public-media-annotation@w3.org>
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
>
Received on Tuesday, 2 November 2010 08:52:02 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:24:44 UTC