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

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

Received on Wednesday, 28 July 2010 15:10:52 UTC