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

On Fri, Dec 12, 2014 at 6:16 AM, Nigel Megitt <nigel.megitt@bbc.co.uk>
wrote:
>
>  From: Glenn Adams <glenn@skynav.com> Date: Friday, 12 December 2014 14:06
>
>
>
> 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 <#14a3edb830c0906b_metadata-vocabulary-item>
>  element.
>    Syntax Representation – <item-name>
>
> <item-name>
>   : <named-item> <#14a3edb830c0906b_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.
>
>
>  It would be helpful to be able to separate the classification scheme URI
> from the term relating to a specific ttm:item.
>

As I previously said, I modeled ttm:item around HTML's meta element type,
which is effectively a name value pair.

The name itself should be sufficient to identify the "classification
scheme", or better put, "name defining authority and name" or a "namespace
and local name".

Using syntactic differences, I divided the value space of names into:

(1) names defined by W3C TTML specifications, i.e., those that take the
form of a token and do not start with "x-";
(2) names defined by private parties for experimental use, i.e., tokens
that start with "x-";
(3) names that take the form of an absolute URI, thus representing an
uncountable set of namespaces each controlled by the 'authority' portion of
the URI value;

The third of these forms provides everything you need to specify a naming
authority (classification scheme) and local name. So anything else would
simply be syntactic sugar and not represent a functional improvement.


>
>  Is that just a usage change to the existing syntax, to define that an
> xsd:anyURI can be used on a ttm:item that contains other ttm:items to
> specify a classification scheme, and that the item-name of those
> descendants should be considered relative? Seems a bit woolly to me, and
> like it would block new classification schemes from being adopted part way
> down the tree.
>

I'm not sure what problem you are attempting to articulate. With the
drafted text, one can have:

<ttm:item name="absoluteUri1">
  <ttm:item name="absoluteUri2">a string value</ttm:item>
  <ttm:item name="absoluteUri3">an integer value</ttm:item>
</ttm:item>

It doesn't really matter if absoluteUri{1,2,3} share the same authority or
not.


>
>  I guess one solution would be to qualify the item-name with another
> attribute "nameIsUriPrefix" which if "true" would be considered an
> item-name URI prefix for all descendants that do not have the attribute
> present themselves.
>

Are you just trying to save on length of the name string? Does that offer
any functional advantage?


>
>  I've assumed that a fully qualified term consists of a prefix plus a
> term identifier, and that the prefix would normally be the URI of the
> classification scheme.
>
>
>>  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
>>    ­­
>>
>>