RE: Moving the MA Ontology to 2nd LC, ma:compression, yet again

Thanks for taking the burden of listing them all.

No doubt that the change should apply to genre, keyword (not my favourite but requirements exist), location:name, language.

There are several consistency issues e.g. publisher is not defined like contributor or creator. This needs to be aligned.

When attName is declared as an identifier, it can be seen as an overlap to the URI value in attValue. In this case, the change may be possibly done by removing URI from attValue (but then the notion of attValue would be different between the implementation in compression or genre and in creator or contributor.

My suggestions in line... 

Jean-Pierre

-----Original Message-----
From: public-media-annotation-request@w3.org [mailto:public-media-annotation-request@w3.org] On Behalf Of David Singer
Sent: jeudi, 10. février 2011 20:13
To: public-media-annotation@w3.org
Subject: Re: Moving the MA Ontology to 2nd LC, ma:compression, yet again

Jean-Pierre suggests that we should review every place where the spec. says "URI" | "String" and see whether the doublet approach would be an improvement there.

So, here they are.  I don't think doing what JP suggests (making these all doublets, so it's clear) is harmful, but in some places they are already inside tuples with {} so the structure might get a little unwieldy.  I think they need a read-through.  Here they are for your reference, with some initial comments by me. But I think JP, and people more familiar with some of the controlled vocabularies and industry practices here should probably dig a little deeper.

(by the way, there is a typo I just noticed: in "location" - "optionnaly") 



Technical properties:

language	(attName="language", attValue="URI" | "String")	The language used in the resource. We recommend to use a controlled vocabulary such as [BCP 47]. An BCP 47 language identifier can also identify sign languages e.g. using ISO 639-3 subtags like bfi (British sign language).

JPE: the change would apply here

Personal or organizational names/identifiers:

contributor	{ (attName="identifier", attValue="URI" | "String"), (attName="role", attValue="String")? }	A tuple identifying the agent, using either a URI (recommended best practice) or plain text. The role can be used to optionally define the nature of the contribution (e.g., actor, cameraman, director, singer, author, artist, or other role types). An example of such a tuple is: {imdb:nm0000318, director}.

JPE: Should identifier read "contributor"? Or if identifier is a duplicate of URI would removing string of attValue solve the problem?

creator	{ (attName="identifier", attValue="URI" | "String"), (attName="role", attValue="String")? }	A tuple identifying the author of the resource, using either a URI (recommended best practice) or plain text. The role can be used to optionally define the category of author (e.g., playwright or author). The role is defined as plain text. An example of such a tuple is: {dbpedia:Shakespeare, playwright}.

JPE: Should identifier read "creator"? Or if identifier is a duplicate of URI would removing string of attValue solve the problem?

publisher	(attName="publisher", attValue="URI" | "String")	The publisher of a resource, defined as either a URI or plain text. We recommend, as a best practice, to define the publisher as a URI.

JPE: the change would apply here. See above for the consistent use of attName and attValue... If attName is right for publisher, then the change with two attributes for URI and string would apply here and also for contributor and creator

rating	{ (attName="value", attValue="Double"), (attName="identifier", attValue="URI" | "String")?, {(attName="min", attValue="Double"), (attName="max", attValue="Double")}? }	A tuple defining the rating value, an optional rating person or organization defined as either a URI (recommended best practice) or as plain text, and an optional voting range. The voting range can optionally be used to define the minimum and maximum values that the rating can have.

JPE: same ambiguity on the use of identifier for attName (rating??). See possible options above.

(Presumably) User-defined tags:

location	{ (attName="name", attValue="URI" | "String")?, (attName="longitude", attValue="Double")?, (attName="latitude", attValue="Double")?, (attName="altitude", attValue="Double")?, (attName="coordinateSystem", attValue="String")? }	A tuple identifying an optional name and/or an optional set of geographic coordinates, in a given system (which is also optionnaly specified), that describe where the resource has been created, developed, recorded, or otherwise authored. The optional name can be defined using either a URI (recommended best practice) or plain text. The optional geographic coordinates MAY include longitude, latitude, and/or altitude information, in a given geo-coordinate system (such as the World Geodetic System) that MAY also be specified.

JPE: This seems to show that the change with two attributes for URI and string should apply to name (and contributor, creator, publisher, rating (wrongly named identifier

keyword	(attName="keyword", attValue="URI" | "String")	A concept, descriptive phrase or keyword that specifies the topic of the resource, using either a URI (recommended best practice) or plain text. In addition, the concept, descriptive phrase, or keyword contained in this element SHOULD be taken from an ontology or a controlled vocabulary.

JPE: This seems to show that the change with two attributes for URI and string should apply to name (and contributor, creator, publisher, rating (wrongly named identifier), keyword

genre	(attName="genre", attValue="URI" | "String")	The category of the content of the resource, using either a URI (recommended best practice) or plain text. In addition, the genre contained in this element SHOULD be taken from an ontology or controlled vocabulary, such as the EBU vocabulary.

JPE: This seems to show that the change with two attributes for URI and string should apply to name (and contributor, creator, publisher, rating (wrongly named identifier), keyword, genre

May be user or system defined:

targetAudience	{ (attName="identifier", attValue="URI"), (attName="classification", attValue="URI" | "String") }	A tuple identifying the classification scheme (e.g., a parental guidance issuing agency, or a targeted geographical region) and the value given in this classification.

JPE: attName="identifier", see above??

Structural:

relation	{ (attName="identifier", attValue="URI" | "String"), (attName="relation", attValue="String")? }	A tuple that identifies a resource that the current resource is related with (using either a URI -recommended best practice- or plain text), and optionally, specifies the nature of the relationship. An example is a listing of content that has a (possibly named) relationship to another content, such as the trailer of a movie, or the summary of a media resource.

JPE: attName="identifier", see above??


Comments:
language: Since we want to allow BCP47 values for language, we seem to need string here.  Can we insist people map into BCP47?  I am not sure what to do for the best here, as the common industry practice is not URI-based.

JPE: it depends, it should not be prevented to develop BCP47 compliant classification scheme, which terms could be referred to using URIs

Contributor etc.: it seems like a name here is harmless.

JPE see comments above. Problem of consistency with publisher.

location, keyword, genre: it's pretty common to use a string here, and I don't think "At home in Stockholm" and "Funky" are likely to cause confusion.

JPE: I would say it's also absolutely possible to use classification schemes in particular for genre. Location can be referred to by a URI in particular for linked data in the RDF implementation. Keyword is trickier but I have seen requests to consider keywords as predefined lists. Difficult to take an authoritative position.

targetAudience: I think this would benefit from JP's suggestion; people might use the values to decide whether something is rated or not, and whether to display it to a rating-controlled user (e.g. a child); the more ability we have to be precise, the better, it seems.

JPE: see comments above

relation: it seems like a good idea here also, as if you know that the relation's kind is a valid RDF-ready URI, you can make an RDF mapping.  At the moment, you have to do inspection of the value to decide whether it's an OK RDF relationship, or just a string.

JPE: see comments above


David Singer
Multimedia and Software Standards, Apple Inc.

Received on Thursday, 10 February 2011 20:16:15 UTC