RE: [TTML2] Current draft - ttm:item concept

I was thinking more about a centralised repository that would encourage convergence of metadata definitions, rather than just providing a mechanism to ring fence them into specific domains.
I see this divergence as a major impediment to true interoperability.

Unless metadata is universally consistent (or map able), there will be functional interoperability, but not interoperability in the sense of the correct asset being computationally identifiable.

J

John Birch | Strategic Partnerships Manager | Screen
Main Line : +44 1473 831700 | Ext : 2208 | Direct Dial : +44 1473 834532
Mobile : +44 7919 558380 | Fax : +44 1473 830078
John.Birch@screensystems.tv<mailto:John.Birch@screensystems.tv> | www.screensystems.tv<http://www.screensystems.tv> | https://twitter.com/screensystems


Visit us at
BVE, Excel London 24-26 February 2015 Stand No. N19

P Before printing, think about the environment

From: Nigel Megitt [mailto:nigel.megitt@bbc.co.uk]
Sent: 12 December 2014 09:47
To: John Birch; Glenn Adams; Andreas Tai
Cc: public-tt
Subject: Re: [TTML2] Current draft - ttm:item concept

From: John Birch <John.Birch@screensystems.tv<mailto:John.Birch@screensystems.tv>> Date: Friday, 12 December 2014 09:36

Re: Note that we do have some existing, item specific vocabulary, e.g., copyright, desc, title, which at this point, I view as legacy vocabulary (we might even want to define counterpart named metadata items so these could be alternatively expressed with ttm:item).
I think such a rationalisation would be extremely useful in promoting the new generic ttm:item based metadata concept. Future versions of TTML derived standards could then adopt a strategy of defining mappings of domain specific metadata using the generic scheme.

Would it be useful to consider some means of avoiding ‘name collision’ between different derived standards defining mappings at the TTML level? E.g. a repository / registry?

Classification scheme URI on an item parent, inherited by children?

E.g.

<ttm:item scheme="http://acme.org/classificationscheme" name="acme metadata">
<ttm:item name="fruit">banana</ttm:item> <!— inherits scheme from parent —>
<ttm:item name="vegetable">carrot</ttm:item>
</ttm:item>



Best regards,
John


John Birch | Strategic Partnerships Manager | Screen
Main Line : +44 1473 831700 | Ext : 2208 | Direct Dial : +44 1473 834532
Mobile : +44 7919 558380 | Fax : +44 1473 830078
John.Birch@screensystems.tv<mailto:John.Birch@screensystems.tv> | www.screensystems.tv<http://www.screensystems.tv> | https://twitter.com/screensystems


Visit us at
BVE, Excel London 24-26 February 2015 Stand No. N19

P Before printing, think about the environment

From: Glenn Adams [mailto:glenn@skynav.com]
Sent: 11 December 2014 17:41
To: Andreas Tai
Cc: public-tt
Subject: Re: [TTML2] Current draft - ttm:item concept


On Thu, Dec 11, 2014 at 4:01 AM, Andreas Tai <tai@irt.de<mailto:tai@irt.de>> wrote:
Hi Glenn,

>From my view the introduction of the “ttm:item element concept” needs more investigation. Currently I see problems a) with current validation mechanisms and b) a good change to encounter the same content in different parts of a TTML 2 document.

a) The semantic identity of a ttm:item element is defined by the value of the name attribute instead of the element name (e.g. there is a ttm:item element defined with the attribute name set to "creationDate" instead of a new element creationDate). In this scenario it is not possible to validate with XML Schema 1.0 that the content of <ttm:item name"creationDate">[Content]</ttm:item> conforms to the XML Schema 1 DataType "date". Although this is possible with XML Schema 1.1 I do not see this as a validation option. The use of XML Schema 1.1 is not very wide spread yet and I do not know of any free parser that fully (!) supports XML Schema 1.1.

AFAIC, this is a non-issue: firstly, we don't specify a standard schema system, but support two RNC and XSD (early on, we had actually been explicit in favoring RNC as the primary, and XSD as secondary, but this distinction has fallen away); secondly, as you well know, there are many constraints in TTML itself and in its various profiles that are not schema validatable, e.g., see the enumeration "Additional Semantic Tests" in the TTV documentation [1]; thirdly, there are tools, like TTV [1], that has no trouble verifying the adherence of additional constraints;

[1] https://github.com/skynav/ttv


To take a case in point, the syntax of the <length> [2] and <timeExpression> [3] value expressions are not validatable by any schema system I have used, partly because additional constraints apply depending on context of use.

[2] http://www.w3.org/TR/2013/REC-ttml1-20130924/#style-value-length

[3] http://www.w3.org/TR/2013/REC-ttml1-20130924/#timing-value-timeExpression



b) One use case of ttm:item is to integrate metadata that is already defined in other specification (e.g. in EBU Tech 3350/EBU-TT Part 1). It seems easier to me just to leave the metadata in the namespace where there are defined and integrate them by reference. Otherwise there is a good change that you have in two place (e.g. an ebuttm:creationDate element and a ttm:item element where the name is set to “creationDate”).

That would create a reference circularity. In the case of defining named metadata items, I have assumed that there is general utility in use of most if not all of the items defined in EBU-TT, so have defined them in a manner independently from EBU-TT, in some cases, generalizing the description.

If there is a very strong need to keep some EBU-TT metadata distinct from the general purpose item, then we could define extra items prefixed with 'ebu', or you could use a URI in an EBU defined namespace to name the item, e.g.,

<ttm:item name="urn:ebu:tt:metadata:documentCreationDate">...</ttm:item>


In general I very much appreciated the clear definition of the metadata section in the TTML 2 draft and the use of very helpful code examples to illustrate the usage of TTML vocabulary! Thanks for that!

One of the highest order design priorities I have applied in TTML is vocabulary minimization. The overhead of introducing new vocabulary, both in terms of specification and implementation, is significantly higher for specialized vocabulary compared to general purpose vocabulary.

If one element definition (ttm:item) can serve the purpose of representing dozens or hundreds of specialized vocabulary, then that is a big win overall. Furthermore, generalized vocabulary and syntax tends to support extensibility better. For example, it will not require a modification to TTML2 to introduce new named metadata items, since the size of this set is uncountable (due to use of an extensible set of names), while the approach you advocate would require just that when new metadata comes along.

So, given the above, I have to respectfully decline the proposal to define item specific vocabulary. Note that we do have some existing, item specific vocabulary, e.g., copyright, desc, title, which at this point, I view as legacy vocabulary (we might even want to define counterpart named metadata items so these could be alternatively expressed with ttm:item).


Best regards,

Andreas

--
------------------------------------------------
Andreas Tai
Production Systems Television IRT - Institut fuer Rundfunktechnik GmbH
R&D Institute of ARD, ZDF, DRadio, ORF and SRG/SSR
Floriansmuehlstrasse 60, D-80939 Munich, Germany

Phone: +49 89 32399-389<tel:%2B49%2089%2032399-389> | Fax: +49 89 32399-200<tel:%2B49%2089%2032399-200>
http: www.irt.de<http://www.irt.de> | Email: tai@irt.de<mailto:tai@irt.de>
------------------------------------------------

registration court&  managing director:
Munich Commercial, RegNo. B 5191
Dr. Klaus Illgner-Fehns
------------------------------------------------


This message may contain confidential and/or privileged information. If you are not the intended recipient you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. Screen Subtitling Systems Ltd. Registered in England No. 2596832. Registered Office: The Old Rectory, Claydon Church Lane, Claydon, Ipswich, Suffolk, IP6 0EQ
  ­­