RE : review of comment LC-2404

RDF/ontology consistency section:

There are a few things like the use of identifier for mediaResource, which has been discussed. It is defined in the ontology and should remain in the RDF in addition of the class ID because mediaResources often have more than one ID. These ID should be either a URI or a string !!

hasLanguage is eligible for using A SKOS concept from a classification scheme and shouldn'tt be only a dataProperty. Idem for TargetingAudience.classification.

Location type is a good option as location is a class.

Jean-Pierre
________________________________________
De : public-media-annotation-request@w3.org [public-media-annotation-request@w3.org] de la part de Pierre-Antoine Champin [pierre-antoine.champin@liris.cnrs.fr]
Date d'envoi : jeudi, 11. novembre 2010 17:26
À : public-media-annotation@w3.org
Objet : review of comment LC-2404

Hi all,

per my action item, I reviewed Ivan's comment LC-2404, and checked that
the resolution is reflected in the document.

To properly respond to Ivan's comment, I think the ontology document
should not only include the ontology, but also *explain* how this RDF
ontology maps to the "abstract" ontology.

I wrote a correspondence table with an introductory paragraph, that I
attach to this mail. This would have to be inserted in the RDF section,
together with the RDF ontology.

I also think this requires a number of minor changes in the ontology
document and the RDF ontology, to make the correspondence as clear as
possible; I list those changes below and propose we review them briefly
at the next telecon.

About the ma: prefix
++++++++++++++++++++

* the namespace URI should be associated to the RDF vocabulary only:
   the abstract ontology does not technically require a namespace URI,
   and keeping it may induce confusion between the abstract terms and
   their RDF counterpart.

* This implies removing the 'ma:' prefix everywhere it appears in the
   ontology document (I scanned the document and wrote a guideline for
   making this change in a relatively automated way -- attached as
   removing-ma-pefix.txt)

* I would also remove the sentence in the introduction about the
   namespace URI, and replace it with a sentence like: "Each of those
   metadata formats can therefore be considered as an *expression* of
   the ontology, but this specification also provides a specific RDF
   vocabulary in section 7."

* I would move section 5.1.1 (about namespace definition) to the RDF
   section

* I would remove the parenthesis "(prefix ma in this document)" in the
   definition of 'Ontology' as this only applies to the RDF vocabulary


RDF ontology
++++++++++++


* I have a made a few minor changes (attached as ma-ont-rev-23.owl).

* I submitted a number of other changes to Tobias and Jean-Pierre
   (mostly deleting properties and classes which have no counterpart in
   the ontology document).


properties table
++++++++++++++++

* type definition of 'identifier' does not use the same syntax as the
   others; should simply read 'URI'

* rating description: s/voting/rating/

* rating: the API has an attribute 'type' which is missing from the
   core definitions table (should have type "URI|String", IMHO)

* relation.identifier should have type "URI|String" according to
   description


consistency between the two
+++++++++++++++++++++++++++

* either make 'identifier' accept "URI|string" instead of "URI",
   or remove 'ma:identifier' from RDF
   (if only URIs are allowed, a property is not needed)

* either make 'language' accept a "URI|string", or make
   'ma:hasLanguage' a datatype property in RDF
   (but why exclude URIs here?)

* either make 'targetAudience.classification' accept "URI|String", or
   make 'has:Classification' a datatype property in RDF
   (but why exclude URIs here?)

* the table states that 'location' can be either the place of creation,
   recorded... whithout giving a mean to specify which
   (nor does the API);
   on the other hand, the RDF ontology provides subproperties to do that;
   we can be happy with that, or enrich the 'location' complex type with
   a 'type' attribute, which seems just as fine to me.
   → this implies changing the API document as well

  regards

   pa
-----------------------------------------
**************************************************
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 Friday, 12 November 2010 21:32:53 UTC