Comments on Ontology and API

Hi, folks-

Sorry for the late comments... I have been on vacation.

At TPAC, I sat in on your F2F sporadically, and commented there on some 
suggestions to make the API a more attractive implementation prospect 
for browsers; some subsequent informal discussions with browser vendors 
seem to bear my intuition out.  I've been pretty busy in the intervening 
months, and haven't had the time to properly follow up with you, for 
which I apologize; however, I'm really interested in a successful 
outcome for your work, so I thought it might help to start simple and 
build out from there.

I recognize that you have done a lot of work on your documents, so I 
don't want you to take my critiques the wrong way; I think there is a 
lot of good stuff there, which can form the basis of a really compelling 
set of functionality.

Just to start the ball rolling, here are some stray thoughts I had while 
skimming your two documents, Ontology for Media Resource 1.0 [1] and API 
for Media Resource 1.0 [2].


Ontology:

As an editorial comment, there seems to be an academic tone here, with 
the use of the word "our" rather than "this specification", detailed 
rationales for decisions (which is good in itself, but ), and a 
generally tentativeness ("Although the set of properties is now limited, 
it already constitutes a proof of concept", section 4.1.1, "proof-read 
our interpretation", etc.). I recommend you simply state in the Status 
section that feedback is welcome (with short inline notes commenting on 
which sections are in particular need of feedback), that there may be 
considerations for possible future versions of the spec, and that you 
leave room for extensions; if this is done right and sees uptake, it 
will almost certainly be the first of a lineage of specs.

1 Introduction
The introduction could benefit by trimming it down.  Split the 
relationship to Dublin Core into a subsection.  Explain the uses of this 
ontology to the expected readers of the spec: possible implementers, 
content authors, and users of the ontology.

1.1 Purpose of this specification
After reading this, I'm left wondering whether this ontology is expected 
to be used in metadata itself, or if it is only a mapping.  If someone 
were to use this ontology by itself, would that be a misuse?  Explain 
why or why not in this section.

4.1.2 Core properties
All the property names are prefixed with "ma:", which could be confused 
as part of the property name.  Simply stating that the properties are in 
the Media Annotations namespace is enough (as long as you provide 
concrete examples of use).

4.2.1 Rationale regarding the mapping table
"Its namespace is "ma", for Media Annotation."  The spec seems to 
conflate the namespace with the prefix; usually, a namespace is 
something like "http://w3.org/MediaAnnotations/", which is often bound 
in a serialized document with a common prefix, like "ma:" using a 
namespace declaration; the prefix is not considered universal.  (In my 
opinion, this is a flawed design for Namespaces in XML, but that's the 
convention.)

4.2.2 The mapping table
I really like the level of detail this spec goes into for performing the 
mapping (though I guess it's still a work in progress.  The mappings 
seem a bit hidden, though, and they are really the meat of the spec.  I 
assume you are trying to keep the spec manageably short, but I would 
suggest either keeping the tables inline in the body of the single-page 
spec, or splitting it out into chapters with each chapter a short 
description of the mapped ontology, followed by the table mapping itself.



API:

I find this spec a little confusing, though it's helped by the concrete 
examples of use.  You are right to identify local/internal and 
remote/external sources for metadata, but the API doesn't feel very 
Javascripty to me.

I think the approach of so many different specialized typed interfaces 
may be too cumbersome for both implementers and authors.  I would take a 
more combinatorial approach, where the author uses the API to extract 
sets of metadata via certain selection criteria, then further filter 
those with selection criteria, or iterate through them generically and 
programmatically.

It seems that you are considering the case of multiple instances of 
orthogonal or even conflicting metadata, possibly in different formats, 
being extracted from the same media resource (thus the returnset being 
an array), but I couldn't see that explicitly described anywhere.

I realize that these are pretty high-level comments, but I'm happy to 
join a telcon sometime to discuss them further, or expand on them via 
email.  Unless you have specific implementer feedback about these, I 
think it might be fruitful to reexamine this approach before the CR phase.


[1] http://www.w3.org/TR/2010/WD-mediaont-10-20100309/
[2] http://www.w3.org/TR/2010/WD-mediaont-api-1.0-20100309/

Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs

Received on Tuesday, 13 July 2010 06:08:23 UTC