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

On Fri, Dec 12, 2014 at 1:46 AM, Nigel Megitt <nigel.megitt@bbc.co.uk>
wrote:
>
>  From: John Birch <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?
>

I defined the value space for @name on ttm:item as follows.
14.3.1 <item-name>

A <item-name> expression is used to specify the name of a metadata item
expressed with a ttm:item <#metadata-vocabulary-item> element.
Syntax Representation – <item-name>

<item-name>
  : <named-item> <#metadata-value-named-item>
  | xsd:token <http://www.w3.org/TR/xmlschema-2/#token>
  | xsd:anyURI <http://www.w3.org/TR/xmlschema-2/#anyURI>

If an item name expression takes the form of an xsd:anyURI
<http://www.w3.org/TR/xmlschema-2/#anyURI>, then it must express an
absolute URI.
All values of <item-name> that do not take the form of (1) an absolute URI
or (2) a token that has the prefix x- are reserved for future
standardization by the W3C.

>
>  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 | 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 <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> 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 | Fax: +49 89 32399-200
> http: www.irt.de | Email: 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
>    ­­
>
>