Re: RE : [mawg] action-249: new OWL version (rev. 4) of the ontology available

Dear all,

first of all thanks for the lively discussion around the ontology.

Clearly there are some things to sort out, but I guess we are on the 
right way.

I want to comment on the role issue in the ontology for which something 
has to be changed to make the modelling more understandable and clearer 
as current naming of the properties (isAuthor etc.) and the class 
hierary is still not totally clear as the comments by Werner, Veronique, 
and Pierre-Antoine show.

To pick up Pierre-Antoine's comment, our ontology should, wrt. to roles 
a person/organisation can play, reflect the following: "the 
'contributor' role as played by agent X for resource Y".

Our ontology should further adher to the terminology defined in the 
Ontology for Media Resource 1.0 document and it should ideally reflect 
good modeling practices.

Wrt. to persons/organisations and their "contribution" to a media 
resource we should imho reflect two things

(a) that a person/organisation X has a specific role Y
(b) that X plays that role wrt. to a media resource Z

So wrt. to the Ontology for Media Resource 1.0 document, one modeling 
option is the solutions pointed out by Pierre-Antoine with the subproperties

OPTION1:

<a_movie>  ma-ont:hasActor<a_person>  .
ma-ont:hasActor rdfs:subPropertyOf ma-ont:hasContributor .


Here we do reflect that X plays a role wrt. to Z and that X is a person.
If we define a symmetric property ma-ont:isContributorOf (Domain: 
ma-ont:Agent, Range: ma-ont:MediaResource) then the above solution 
reflects (a) and (b).

With our current implementation we can do the following (second option 
discussed by Pierre-Antoine)

OPTION2:

<a_movie> ma-ont:hasContributor <a_contributor>.
<a_contributor> rdf:type ma-ont:Actor.
<a_contributor> ma-ont:isAgent <a_person>.

which also reflects what is written in the Ontology for Media Resource 
1.0 document (also (a) and (b)).

With applying good ontology modelling practices we have a third option:

OPTION3:

<a_resourceContribtion> rdf:type ma-ont:ResourceContribution.
<a_resourceContribution> ma-ont:hasContributor <a_person>.
<a_resourceContribution> ma-ont:ContributosTo <a_movie>.
<a_resourceContribution> ma-ont:ContributionType ma-ont:ActorRole.

This option is also modeling what is written in the Ontology for Media 
Resource 1.0 document (also (a) and (b)). This option will lead to more 
complex SPARQL queries in the end.

The following option clearly does not model everything we need:

OPTION4:

<a_person> ma-ont:hasRole ma-ont:ActorRole.
<a_movie> ma-ont:hasContributor <a_person>.

because it does not tell us that the person plays the actorRole wrt. to 
the movie!

I actually like the simplicity of OPTION1 with the subproperties. What 
are the opinion's of others?

Other things to discuss remain how the roles are put into the subclass 
hierarchy (creator under contributor, both seperate, the opposite way, 
etc.): Here I cleary am with Jean-Pierre that we should keep the names 
of both contributor and creator as they are defined in the document.

I actually would also leave Agent in (same reasons as they ones 
mentioned by Pierre-Antoine).

I have no strong opinion wrt. to postfixing the roles with Role at the 
moment as it depends on the modelling option we choose (OPTION 1-4).

Thanks again for your comments and looking forward to more!

Best regards,

Tobias


Am 28.07.2010 17:09, schrieb Pierre-Antoine Champin:
> Hi all,
>
> A very nice work indeed.
>
> To answer one of Véronique's questions, first: if we use the role design
> pattern, it is not a good solution to make roles (Creator, Publisher)
> subclasses of Agent, because an agent is not *intrinsically* a Creator
> or a Publisher... The same agent may play different roles *with respect
> to* different media resources. e.g the director *of* a movie, and the
> producer *of* another movie.
>
> However, I wholeheartedly agree with you that it should be more apparent
> in the class naming which ones are part of the Role hierarchy, and which
> ones are part of the Agent hierarchy. "Contributor" is easily
> mis-interpreted as "any agent that plays the 'contributor' role for some
> resource", while it should be understood as "the 'contributor' role as
> played by agent X for resource Y". I suggest to rename them to
> ContributorRole, ActorRole, PubllisherRole, CreatorRole. A bit verbose,
> but at least it is explicit.
>
>
> Another remark to Jean-Pierre: if you hate so much blank nodes, why
> chose the role design pattern rather than sub-properties ? Because it
> appears to me that, instead of
>
>      <a_movie>  ex:hasActor<a_person>  .
>      ex:hasActor rdfs:subPropertyOf ma:hasContributor .
>
> you will now have to write
>
>      <a_movie>  ma:hasContributor [
>          a ma:ActorRole ;
>          ma:isAgent<a_person>
>      ] .
>
> or do I miss something?
> NB: I'm not trying to argue about the choice of that design pattern -
> just trying to put get the discussion going.
>
>
> A last remark to Jean-Pierre: if you remove class Agent, how would you
> specify the range of ma:isAgent ? For the same reason that the
> superclass Contributor provides extensibility for roles, the class Agent
> provides extensibility, as there may be situations where the creator of
> a resource will be neither a person or an organization (an autonomous
> robot? an animal?...).
>
>    pa
>
>
> On 26/07/2010 20:01, Evain, Jean-Pierre wrote:
>    
>> Veronique, all,
>>
>> When we worked on this Tobias suggested to have an agent to group the
>> person and organisation class.  But I have been working on this and I
>> am not certain we need an agent for this purpose.
>>
>> The discussion around agent/contributor/role is somehow a different
>> topic. Actually MAWG has agreed to use Contributor, which a a role
>> property, and under which some specialised categories have been
>> defined (e.g. creator). This is just a choice of name but for
>> instance if you change contributor in role then how will you call the
>> property qualifying the the role of the role (unless you name the
>> class with the role name which relates to anothe rof your comments,
>> see next)? And all that sort of things. I would therefore suggest
>> that we keep contributor with a role property. And we remove agent,
>> which not absolutely needed to encapsulate person and organisation
>> (the main didea was to be able to make a golbal on the relation
>> between contributor and agent knowing that a contributor (and sub
>> classes) can be either a person or an organisation. I am going to
>> discuss this in more details with Tobias to better understand what he
>> wanted to do there but apparently SPARQL queries do not seem to work
>> on class inferences (although it may be a matter of tool).
>>
>> About the question on role under contributor. Do we know exhaustively
>> what the roles will be? If yes why did we decide to use contributor
>> on the first place. Anyway, having a role add flexibility for
>> undefined concepts. Adding a role is a matter of adding a term to a
>> list for interoperability pruposes, which is not the same as changing
>> / updating / upgrading the ontology.  This has no direct connection
>> to the fact that it can be a person or organisation (at least no
>> intentionally).
>>
>> As for the use of a blank node for properties. If you generate
>> instances you will see that this is purely factual and I personally
>> don't like this so much (actually I hate blank nodes ;-). I did it in
>> my first ontologies but realised  it is better to keep the hierarchy
>> as flat as possible. The use of SKOS concept is there because it is
>> often the case that such values come from classification schemes. In
>> fact the option I discussed with Tobias is to have an object property
>> linking to a SKOS concept and ALSO a data property allowing to
>> provide a value such as a string or else.  This is something that I
>> do in the EBUCore to cover all options. ->  a bit like what you seem
>> to suggest for keyword with a string and a URI (I am typing as I read
>> your mail ;-)
>>
>> I have been working on the ontology. I need to go through this with
>> Tobias. As you say, we need to go thorugh the symmetric properties
>> and some of them would deserve to be reversed.. Also different
>> classes need to be disjoint to avoid funny SPARQL results, etc.
>>
>> Thanks for the detailed review and comments.
>>
>> Best regards,
>>
>> jean-Pierre
>>
>>
>> ________________________________________ De :
>> public-media-annotation-request@w3.org
>> [public-media-annotation-request@w3.org] de la part de Veronique
>> Malaise [vmalaise@few.vu.nl] Date d'envoi : lundi, 26. juillet 2010
>> 16:26 À : Tobias Bürger Cc : public-media-annotation@w3.org Objet :
>> Re: [mawg] action-249: new OWL version (rev. 4) of the ontology
>> available
>>
>> Hi Tobias, all,
>>
>> I had a look at the new version of the ontology and I also have some
>> comments and questions.
>>
>> - like Werner, I would suggest to rename isAgent into something like
>> hasRole, if you want to have a generic Agent class that can have
>> different roles like Actor, Creator and Publisher. I would then
>> suggest to rename Contributor to Role, as it represents the head of
>> the hierarchy of the possible roles attached to an Agent. An
>> ontology containing the classes of Agent, Contributor and Actor can
>> seem confusing for a non-expert user at a first glance :) The class
>> of Actor should be described with a comment stating that it is one
>> possible role for and Agent (although this is clear from the
>> property browsing, it might not be extremely clear from an
>> alphabetical list of classes, for example). Should I try to attach
>> some comments to the classes and properties from the new version?
>> This would show you what other people might interpret from the
>> ontology as it is now and could be useful anyway? But yet another
>> question about this design pattern: is it necessary to have the roles
>> separated from the Agent? It would also be possible (and would look
>> simpler to me) to have the different roles as subclasses of Agent...
>> did you choose to have a parallel hierarchy because of the
>> distinction that you want to make between Organization and Person? -
>> I understand the necessity of a placeholder class as a range for
>> properties such as compression, but would it not make sense to
>> harmonize the range of other properties that should point to a URI
>> to skos:Concepts? Would that be too restrictive? In a modeling
>> perspective, what is the added value to have a skos:Concept instead
>> of a classic blank node for the properties like compression (i.e.
>> properties that point to an entity that has to have several
>> properties attached to)? - about the range of some properties like
>> keyword: the range type is set to string, would it not be nice to
>> have possible ranges as string OR URI? Is that too messy for the
>> APIs? - I did not check it out for all of the properties, but it
>> seems that some symmetric properties are not specified as such,
>> although the ontology is defined in OWL, it is probably on the todo
>> list though, right? :)
>>
>> Otherwise, indeed, the ontology looks good! Thanks a lot Tobias and
>> Jean-Pierre!
>>
>> Best, Véronique
>>
>> On Jul 15, 2010, at 7:35 AM, Tobias Bürger wrote:
>>
>>      
>>> Dear all,
>>>
>>> Jean-Pierre and myself recently had some discussions in which we
>>> changed some parts of the implementation of the ontology. You can
>>> find the new version here:
>>> http://www.salzburgresearch.at/~tbuerger/ma-ont-rev4.owl
>>>
>>> Amongst others we introduced an Agent class having subclasses
>>> Person/ Organization and introduced an attribute agentIs following
>>> the role design pattern to assign roles to persons and
>>> organizations wrt. to MediaResources. The possible roles
>>> (Contributor, Author, etc.) are now organized in a subclass
>>> hierarchy. Some properties were changed as well (amongst others the
>>> qualifiers of the properties, i.e. being functional). I removed the
>>> NamedFragment class and introduced a name property for the
>>> MediaFragment class to replace it (this is a point to be
>>> discussed).
>>>
>>> I think we are getting more closely to a stable version.
>>>
>>> Feedback is welcome at any time!
>>>
>>> Best regards,
>>>
>>> Tobia
>>>
>>> -- 
>>> ================================================================
>>> 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
>> **************************************************
>>
>>
>>      
>
>    

-- 
================================================================
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

Received on Friday, 30 July 2010 04:39:39 UTC