- From: Evain, Jean-Pierre <evain@ebu.ch>
- Date: Mon, 1 Nov 2010 17:43:16 +0100
- To: "Bailer, Werner" <werner.bailer@joanneum.at>, Höffernig, Martin <Martin.Hoeffernig@joanneum.at>, 'Chris Poppe' <Chris.Poppe@UGent.be>
- CC: Tobias Bürger <tobias.buerger@salzburgresearch.at>, "public-media-annotation@w3.org" <public-media-annotation@w3.org>
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:45:50 UTC