W3C

List of comments on “Ontology for Media Resource 1.0” (dated 8 June 2010)

Quick access to

There are 9 comments (sorted by their types, and the section they are about).

question comments

Comment LC-2389: Two questions:
Commenter: Thomas Steiner <tomac@google.com> (archived message)
Context: Document as a whole
assigned to Werner Bailer
Resolution status:

Dear Media Annotations WG,

I really like the efforts of the WG to come up with a common
(Internet) media description / annotation ontology. Thanks for your
hard work to consolidate similar efforts!

Two questions:

1) Subtitles
Other than by means of mentioning _external_ subtitles via ma:relation
as in TXFeed...

* TXFeed: <link rel=”subtitle” href=”http://example.org/video.en.srt”
type=”text/x-srt” hreflang=”en” />
* Ontology for Media Resource (if I got this correctly?!):
<http://example.org/video.en.srt> ma:relation
<http://dbpedia.org/property/subtitle> or just
<http://example.org/video.en.srt> ma:relation subtitle (?)

....did you consider allowing for the _embedding_ of actual subtitles
(where subtitles can be movie subtitles, or also song lyrics, or
speech transcripts) into the media description more or less like in
Media RSS's <media:text> (http://video.search.yahoo.com/mrss) element?
This might happen by the introduction of an ma:event container that
could hold the particular time spans, and the actual subtitle
snippets.

2) Semantic annotation
I'm currently thinking of whether the level of detail of Audio
Description (see http://www.acb.org/adp/ad.html, there: "Samples of
Audio Description") could be expressed with an (this?) ontology. The
main concept would be very similar to 1), however, allowing for richer
annotations than just plain text subtitles including e.g.
<http://dbpedia.org/resource/Audience> example:humanActivity
<http://dbpedia.org/resource/Applause>. Do you see a place for this in
the Ontology for Media Resource?

I know that the document is in "Last Call" status, so my sincere
apologies if these questions should be inappropriate given the
ontology status. Also I might have overlooked the fact that what I
outline here is already possible, or explained elsewhere; thanks for a
pointer to resources in either case and sorry for the potential
confusion my comment might have caused then. Thanks.

Cheers,
Tom

BCC: @webr3, whom I discussed this idea with and who coined the event
container idea.

--
Thomas Steiner, Research Scientist, Google Inc.
http://blog.tomayac.com, http://twitter.com/tomayac
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2398
Commenter: JOSE MANUEL CANTERA FONSECA <jmcf@tid.es> (archived message)
Context: Document as a whole
assigned to Thierry Michel
Resolution status:

Is this specification going to be a Rec or a Note?

because if this is going to be a Rec, you might be in trouble with your lightweight approach to mappings

best
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

general comment comments

Comment LC-2403: Comment from POWDER
Commenter: Phil Archer <phil@philarcher.org> on behalf of POWDER (archived message)
Context: Ontology for Media Resource 1.0
assigned to WonSuk Lee
Resolution status:

Hi Thierry, everyone,

You asked for review of your LCWDs from a POWDER perspective. IU've
taken a look at both documents and don't have any substantive comments
on either since they are some distance removed from what POWDER was
designed to do (which is good because it means there's been no pointless
duplication of effort!).

The document that perhaps has most relevance is your Ontology for Media
Resources. You might consider adding a short section in the manner that
was done for mobileOK [1], or elsewhere in your group output, to show
how a publisher can easily apply terms from the ontology to multiple
resources. Recall that a key feature of POWDER is its ability to derive
semantic meaning from URIs that are otherwise completely "dumb" from a
machine's perspective.

For example, a human would have no difficulty interpreting this URI

http://example.com/movies/sci-fi/

as being the base for perhaps a whole catalogue of science fiction
films. Specific URIs might then be:

http://example.com/movies/sci-fi/alien.mpg
http://example.com/movies/sci-fi/aliens.mpg
http://example.com/movies/sci-fi/alient3.mpg
http://example.com/movies/sci-fi/alienresurrection.wmv
http://example.com/movies/sci-fi/bladerunner.mov

A POWDER document could be constructed to make various assertions about
these films available to Semantic Web clients>

<?xml version="1.0"?>
<powder xmlns="http://www.w3.org/2007/05/powder#"
xmlns:ma="http://www.w3.org/ns/ma-ont#">

<attribution>
<issuedby src="http://example.com/company.rdf#me" />
<issued>2007-12-14T00:00:00</issued>
</attribution>

<dr>
<iriset>
<includehosts>example.com</includehosts>
<includepathstartswith>/movies/sci-fi/</includepathstartswith>
</iriset>

<descriptorset>
<ma:genre src="http://example.com/ontology.rdf#sf />
<ma:publisher src="http://example.com/company.rdf#me" />
<displaytext>Movies in this section of the website are all
in the science fiction genre</displaytext>
<displayicon src="http://example.com/sf-icon.png" />
</descriptorset>
</dr>
</powder>

You can add in further description resources to say things about all the
Alien films, or all those that end in .mpg. Given this information a
POWDER processor can return triples that describe specific URIs.

HTH

Phil


[1] http://www.w3.org/TR/mobileOK/#sec_mobileOK_Labels
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

substantive comments

Comment LC-2411
Commenter: Karen Colye <kcoyle@kcoyle.net> (archived message)
Context: Document as a whole
assigned to Chris Poppe
Resolution status:

Hello all,

with this mail I am forwarding LC comments from Karen Colye
kcoyle@kcoyle.net . She does not want to join the mailing list, but will be happy to reply to hour resolution.

Best,
Felix

1. The scope of the ontology should be clarified as being stored digital resources. It should also be made clear whether these resources MUST be accessible online, or could be offline.

2. You should add PBCORE (http://pbcore.org) to the list. This is a metadata set for broadcast media, and I believe it interrelates to the BBC metadata.
Original broadcast date is key for these materials, as is the name of the show or series (which can be different from the name of the episode).

3. There doesn't seem to be much for describing the content of the media.
There is only the description field. I suspect that many media organizations
have a more complex view, and will need for synopsis to be separate from
subjects for the purposes of display. Also, for broadcast programs with
multiple segments, they need a say to say, for example:
0-1 minute Introductions
1-19 minute: Interview with x
19-22 minutes: news segment
22-31 minute: Interview with y
I don't remember if these are already in PBCore.

3. You will probably eventually need to include some preservation metadata.
This is especially important for any digital media that have been derived
from physical media. PREMIS is probably overkill.... but you may be able to
pick a few elements from that.

Hope this is helpful. If not, feel free to ignore!

kc
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2417: PLING WG
Commenter: Renato Iannella <renato@iannella.it> (archived message)
Context: in
assigned to Werner Bailer
Resolution status:

Dear MAWG, the following are comments on the "Ontology for Media Resource 1.0 W3C Working Draft 08 June 2010" [1] from the W3C Policy Languages Interest Group (PLING) [2].

We apologise for missing the due date, and hope these comments are constructive.

We are happy to respond to any questions you may have..

Cheers

Renato Iannella, Co-Chair, W3C PLING

[1] http://www.w3.org/TR/mediaont-10/
[2] http://www.w3.org/Policy/pling/wiki/Main_Page

==========================================
PLING feedback on the "Ontology for Media Resource 1.0" W3C Working Draft 08 June 2010.

We found the two properties ma:copyright and ma:policy to have overlapping and ambiguous semantics that could lead to improper use of the these two properties.

We suggest that the properties should be subsumed into the single ma:policy property with the following description:

"A tuple containing a policy statement associated with the resource (eg copyright), an identifier of policy (typically machine-resolvable), and the type of the policy to provide more information as to the nature of the policy. At least one of identifier and/or statement is mandatory and type is optional"

The "type definition" of the ma:policy property would include:
- ma:policy.statement - A human-readable description of the Policy (string)
- ma:policy.identifier - The Identifier of the Policy (URI)
- ma:policy.type - The category of the Policy (URI)

Recommended values for policy.type is the Meta information from the XHTML Vocabulary (http://www.w3.org/1999/xhtml/vocab/#)

The ma:copyright would naturally be mapped into ma:policy.statement

Other Examples:
--------
ma:policy[0].statement = "Copyright PLING Inc 2010. All Rights Reserved"
ma:policy[0].type = "http://www.w3.org/1999/xhtml/vocab/#copyright"

ma:policy[1].identifier = "http://p3pbook.com/examples/10-4.xml"
ma:policy[1].type = http://www.w3.org/1999/xhtml/vocab/#p3pv1"

ma:policy[2].identifier = "http://odrl.net/license/license.xml"
ma:policy[2].type = http://www.w3.org/1999/xhtml/vocab/#license"

ma:policy[3].identifier = "http://creativecommons.org/licenses/by/3.0/"
ma:policy[3].type = http://www.w3.org/1999/xhtml/vocab/#license"
==========================================
http://lists.w3.org/Archives/Public/public-media-annotation/2010Aug/0012.html http://lists.w3.org/Archives/Public/public-media-annotation/2010Aug/0013.html http://lists.w3.org/Archives/Public/public-media-annotation/2010Aug/0014.html
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2418
Commenter: Robin Berjon <robin@berjon.com> (archived message)
Context: Document as a whole
assigned to Véronique Malaisé
Resolution status:

Hi,

sorry for being so late in reviewing your document! I see that you were planning to handle the comments at your September F2F however, so I hope that it isn't too late!

Here goes:

ed.: While I'm a big fan of using pedantic plurals I have reservations about using "musea" straight in the abstract, especially as many readers will already have been scared by "ontology" (an issue which you nicely defuse up front). If you do insist on using "musea", then at the very least you ought to be consistent and not use "museums" later (as you do).

ed.: "to foster the interoperability among" -> remove "the"

ed.: You have a CSS rule that sets margin-{top,bottom} to 0.3em on li and p. This makes your document quite hard to read, I have to go tinker with it in Firebug in order to go through it. Please don't change some of the fundamental style rules from the basic W3C style.

ed.: "of media resources hat describe" -> that

ed.: "The vocabulary is defined in this document is based" -> drop the first "is"

ed.: "usessyntacticmappings" Spaces!

ed.: The first parahraph of the introduction is a large chunk of text that talks about several different things. It would be worth splitting it into units of meaning that can be digested one by one.

ed.: You have several instances of things like:

"This section is informative, except those parts that are explicitly defined as normative."
"This section is normative; however, examples contained in this section are informative."

That muddles things up a little. DAP specs normally all have a section called "Conformance" (it's generated automatically, e.g. http://dev.w3.org/2009/dap/contacts/#conformance) that says "As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative." Then each section is either normative or it's not — without specific exclusion rules.

Section 1 also says that it has normative content, but it doesn't!

ed.: "defined in API for Media Resources 1.0 s well as" -> as well as

substantive: "The Working Group MAY potentially modify these definitions, to ensure compatibility with the return data types defined in API for Media Resources 1.0 s well as the data types defined in the HTML5 W3C Working Draft." This is strange to have in an LC document. An LC document is expected to be stable (i.e. the WG believes that it could go to CR). If the WG is going to change the definition of type values, that's a fundamental change that will require another LC. So either the types are final and this should be removed (which downgrades this to an editorial comment), or the WG should make the necessary changes and re-issue an LC.

ed.: "has defined a namespace URI, ma-ont, for use with this specification" The string "ma-ont" isn't the namespace URI that the group has defined (as this sentence seems to suggest), it's just a conventional prefix used in this document.

ed.: "As specifications that use this namespace URI progress through the standardization process, it is important that each subsequent revision of specifications that use this namespace MUST use the same namespace URI." There are several things that are wrong here. First, if it's not the same namespace URI then it can't be the same namespace, so this is self-evident. Also, it's unclear what the product is that the MUST applies to. Likewise for the following "MAY" (though I understand what it is trying to say.

I think that the solution here is to drop the normative statements since they are untestable (you're not going to write a test suite that can validate that MUST applied to future specifications). Simply replace the whole thing with "This namespace URI is expected to remain the same throughout the evolution of this ontology, even in the case new properties are added to it, so long as it remains backwards compatible. If however a new version were produced that was not backwards compatible, the WG reserves the right to change the namespace URI."

ed.: "The ma abbreviation is a prefix for the namespace http://www.w3.org/ns/ma-ont." Anything can be a prefix for that namespace, I think you mean to say that throughout this specification you use that as the conventional prefix. I'm not sure what its relationship to "ma-ont" is though.

substantial: "Applications that are compliant with this specification SHOULD use this namespace." What are the cases in which this rule has an exception?

substantial: "A controlled vocabulary such as [BCP 47] SHOULD be used." What are the cases in which this rule has an exception?

substantial: "it MAY also define a coordinate system that can be used to interpret these measurements" Is there a controlled vocabulary for these? Everywhere that there's something that looks like there could be one (e.g. whenever something has a "type" this should be indicated).

substantial: Does ma:format include media type parameters?

ed.: In general it would be helpful if you could be clearer about what the normative statements apply to. What is it that MUST do this or that? Is it an abstract usage of an ontology? A concrete implementation? Something else?

ed.: It might be worth removing the XPath column from the tables when it's not used, that would save some horizontal scrolling.

ed.: Providing an explanation of the columns in the mapping table would be useful for people who weren't part of the group to figure out what exactly they are intended to convey.

substantial: There is no consistency in how XPath is used. Some expressions start with an element name, others with ./ without indications of what they are relative to. Some are rooted off a document. It is unclear when a namespace may or may not be involved. The TVA one gives a "Base" that is itself unrooted, and then goes on to say that each "term" should be preceded by the "namespace 'tva:'". I don't know what a "term" is, is it elements, attributes, the whole path? It would be clearer to use the prefix in the expression itself, where it belongs. And "tva:" isn't a namespace, it's a prefix that presumably maps to the TVA namespace — that namespace needs to be specified. In general it would be helpful if you reviewed your usage of XPath to make sure that each expression is correctly provided a namespace context matching the prefixes it uses, and is given an element or document context in which it can be evaluated. I'm not sure that the table heading is the best place for that (as done in the TVA section), I'd suggest simply explaining it right before the table. Being clear as to which version of XPath is intended would be helpful, especially since I see some "+" characters in some paths that I don't know how to interpret. In some cases it looks like you actually want something more powerful than what XPath can express — it's worth clarifying what you mean rather than resorting to shorthand for those.

ed.: Section 5 Conformance Requirements is a repeat of content that appears previously.

[0]http://www.w3.org/2008/WebVideo/Annotations/drafts/ontology10/LC/Overview.html
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2393: speex and vp8
Commenter: James Salsman <jsalsman@talknicer.com> (archived message)
Context: Document as a whole
assigned to Thierry Michel
Resolution status:

Ontology for Media Resource questions:

Why is speex not included?

Why is VP8 not included? Ref. http://www.webmproject.org and
http://www.webmproject.org/about/faq/#licensing

On Wed, Jun 9, 2010 at 12:22 AM, Thierry MICHEL <tmichel@w3.org> wrote:
>...
> (8) Report of any Formal Objections....

I would like to formally object to the omission of an audio/x-speex
quality parameter from the API for Media Resource draft, and omission
of speex and vp8 from the Ontology for Media Resource draft.

Sincerely,
James Salsman
invited expert
Device API and Policy (DAP) Working Group
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2405
Commenter: Doug Schepers <schepers@w3.org> (archived message)
Context: in
assigned to Véronique Malaisé
Resolution status:

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.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2404: OM and RDF/OWL
Commenter: Ivan Herman <ivan@w3.org> (archived message)
Context: Ontology for Media Resource 1.0
assigned to Thierry Michel
Resolution status:

Dear all,

I was looking at the MO document

http://www.w3.org/TR/2010/WD-mediaont-10-20100608/

From a Semantic Web point of view. I understand that the ontology you define is not exclusively for its usage on the Semantic Web, ie, it is not only meant to be used in RDF. However, the current document makes it very difficult to understand how this vocabulary _could_ be used on the Semantic Web if this is what one wants.

The 'mo' terms are defined in

http://www.w3.org/TR/2010/WD-mediaont-10-20100608/#core-property-definitions

and you define your own syntax to describe each term. It is, however, not clear (to me...) how that syntax translates into RDF if I want to use it this way. Indeed, if I look at ma:identifier, it is defined as { (identifier:URI), (type:String)? }. But the text does not explain whether I have to use

<...> mo:identifier <a-unique-uri>;
mo:identifier "somethingelse" .

or whether I have to involve an intermediate node...

To make it more complex, what should I do with ma:location, defined by:

{ (name:(URI|String))?, ((longitude:Float), (latitude:Float), (altitude:Float), (coordinateSystem:String)?)?, }

does it mean that I have something like

ma:location [
ma:name <uri...> ;
ma:longitude 1.2344 ;
ma:latitude 4.56789 ;
...
]

or something else?

Note that the namespace document at http://www.w3.org/ns/ma-ont does not refer to any RDF or OWL version of the ontology. Ie, on the semantic Web, I cannot follow my nose in finding out anything about that vocabulary in terms of RDF or OWL.

I do believe an explicit bridge from your document to the Semantic Web is needed, in the form of a clear translation of your syntax to RDF, corresponding examples, and a proper RDF Schema (or OWL, if necessary) for the vocabulary.

I know that the document does include the following remark:

[[[
This specification provides a simple text description and definition of the relationships. An implementation of the vocabulary in RDF [RDF] will be provided as an example in the appendix of this specification.
]]]

but that appendix is missing. That would be acceptable for a Working Draft; I do not think a missing appendix of that sort is acceptable for a Last Call document. It is also not clear whether that appendix would be normative or not; I believe it should.

Finally, looking at the charter of the Working Group[1], the charter says, among other things:

[[[
Ultimately, users of the ontology should also be able to take advantage of Semantic Web technologies, such as the SPARQL Query Language for RDF.
]]]

ie, my criticism is also based on the charter obligation of the group...

Sincerely

Ivan

[1] http://www.w3.org/2008/01/media-annotations-wg.html

----
Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153 begin_of_the_skype_highlighting              +31-641044153      end_of_the_skype_highlighting begin_of_the_skype_highlighting              +31-641044153      end_of_the_skype_highlighting begin_of_the_skype_highlighting              +31-641044153      end_of_the_skype_highlighting begin_of_the_skype_highlighting              +31-641044153      end_of_the_skype_highlighting begin_of_the_skype_highlighting              +31-641044153      end_of_the_skype_highlighting begin_of_the_skype_highlighting              +31-641044153      end_of_the_skype_highlighting begin_of_the_skype_highlighting              +31-641044153      end_of_the_skype_highlighting begin_of_the_skype_highlighting              +31-641044153      end_of_the_skype_highlighting begin_of_the_skype_highlighting              +31-641044153      end_of_the_skype_highlighting begin_of_the_skype_highlighting              +31-641044153      end_of_the_skype_highlighting begin_of_the_skype_highlighting              +31-641044153      end_of_the_skype_highlighting begin_of_the_skype_highlighting              +31-641044153      end_of_the_skype_highlighting begin_of_the_skype_highlighting              +31-641044153      end_of_the_skype_highlighting begin_of_the_skype_highlighting              +31-641044153      end_of_the_skype_highlighting begin_of_the_skype_highlighting              +31-641044153      end_of_the_skype_highlighting
PGP Key: http://www.ivan-herman.net/pgpkey.html
FOAF: http://www.ivan-herman.net/foaf.rdf
http://lists.w3.org/Archives/Public/public-media-annotation/2010Jul/0018.html
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Add a comment.


Developed and maintained by Dominique Hazaël-Massieux (dom@w3.org).
$Id: index.html,v 1.1 2017/08/11 06:46:15 dom Exp $
Please send bug reports and request for enhancements to w3t-sys.org