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

Hi Tobias,

I completely agree with your analysis below, except that I don't really
see how options 3 is more complex than option 2, regarding the
complexity of SPARQL queries... (besides the fact that you chose longer
names ;-)

Indeed, in option 3, you can omit the rdf:type of the intermediate
resource, as it will be implied by the domain of the properties; so you
end up with 3-triples in each example, with a one-to-one correspondence
regarding the conveyed information...

I acknowledge that the ontological commitment is not exactly the same in
both options, though. From the naming of the resources, in option 2 the
intermediate resource represents a *role*, while in option 3 it
represents an *event*. But as such, I don't see one to be more complex
than the other.

  pa


On 30/07/2010 06:38, Tobias Bürger wrote:
> 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 Saturday, 31 July 2010 09:52:40 UTC