RE : ma-ont RDF latest version

BTW, I would also suggest that we do not leave the rating provider as a subclass of contributor.
JP

________________________________________
De : Evain, Jean-Pierre
Date d'envoi : lundi, 1. novembre 2010 17:43
À : Bailer, Werner; Höffernig, Martin; 'Chris Poppe'
Cc : Tobias Bürger; public-media-annotation@w3.org
Objet : RE : ma-ont RDF latest version

Then I guess the easiest way is to also allow a property linking a rating provider to a fragment, which our new model allows.

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 Monday, 1 November 2010 16:47:53 UTC