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

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 Monday, 26 July 2010 18:02:15 UTC