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

RE: ma-ont RDF latest version

From: Chris Poppe <Chris.Poppe@UGent.be>
Date: Sun, 24 Oct 2010 21:09:31 +0200
Message-ID: <20101024210931.11534ujq5oa8lg17@webmail.ugent.be>
To: "Evain, Jean-Pierre" <evain@ebu.ch>
Cc: "Tobias Bürger" <tobias.buerger@salzburgresearch.at>, "Bailer, Werner" <werner.bailer@joanneum.at>, "Davy Van Deursen" <davy.vandeursen@ugent.be>, "public-media-annotation@w3.org" <public-media-annotation@w3.org>
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?

Could isImageRelatedTo be made a subproperty of isRelatedTo?

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?

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";

I think there is something missing to state that a MediaFragment is a  
fragment of a specific MediaResource (maybe isFragmentOf and  
hasFragment Object properties).

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.

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 Sunday, 24 October 2010 19:34:22 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 24 October 2010 19:34:23 GMT