Re: [All] domain data category section proposal, please review

I agree - nice summary Arle?

And to be clear, for ITS conformance testing of glue type data 
categories, we only need to test that the correct association is made 
between the select portion of the document and the pointer concerned, 
and that the implemention can fetch what is being pointed at, but not 
how it parses or interprets that external document - right?

cheers,
Dave

On 04/07/2012 12:52, Felix Sasaki wrote:
> Thanks a lot for the summary, Arle. One additional point below.
>
> 2012/7/4 Arle Lommel <arle.lommel@dfki.de <mailto:arle.lommel@dfki.de>>
>
>     Hi all,
>
>     Just to follow up on what Felix wrote, I was in discussion with
>     Pedro and we realized that there is a potential issue for our work
>     as we delve into process-related data categories, provenance, and
>     so forth. If we try to define values, our specification will
>     already by obsolete by the time it is out the door. For example,
>     if we define process trigger very well, we will release the
>     specification and immediately we will discover that there was some
>     relevant usage scenario we did not consider that therefore cannot
>     be covered by the values we have. We discussed adopting the
>     "standards as database" approach being taken by ISO TC 37 (hence
>     my frequent references to the ISO Data Category Repository in the
>     past few week).
>
>     After discussion with Felix, however, we (Felix and I) see a
>     solution: our work is not to define the permissible values for
>     most of this metadata. Rather we provide a mechanism to point to
>     the values people are using, as we discussed with domain. This is
>     the "glue" idea Felix mentions. That sets aside the issue of
>     *where* to define the values to support interoperability
>
>
> This of course only makes sense if there are already values being 
> used. From Thomas and Declan I think this is the case for MT systems. 
> In other words, we should not define new data categories saying that 
> they are on the "glue" level and that some day they might play a rule 
> in bringing systems together. For a new data category fulfilling this 
> "glue" purpose, there needs to be implementations - two, as usual - 
> that can make use of it.
>
> Best,
>
> Felix
>
>     , but by focusing on just the glue it simplifies our
>     implementation requirements and testing greatly. So, for example,
>     Pedro could post the ontology of process trigger he is using and
>     point to it in the implementation with his partners, thus
>     fulfilling the requirement for implementation of the data
>     category. But we do /not/ need to agree and standardize as a group
>     on the possible values, a task that would make our project
>     exponentially more difficult and unwieldy, and we do not need to
>     implement specific values for the data category.
>
>     To take another example, in the quality data categories, this
>     principle means we would not define a quality metric ourselves,
>     but rather ways to point and reference external quality metrics.
>
>     So we need to keep this principle in mind for the complex data
>     categories: in most cases, we are defining /reference mechanisms/,
>     not /content/values/. We simply need to provide a way to point to
>     the work of others (either standardized or proprietary). If we are
>     getting into any sort of prescriptive description of what people
>     /should or should not/ be doing, we are exceeding our mandate.
>
>     Best,
>
>     Arle
>
>
>     On Jul 4, 2012, at 12:21 , Felix Sasaki wrote:
>
>>     Thanks, and I very much agree. Arle recently told me that there
>>     was a discussion at the ISO meeting in Madrid about whether
>>     MLW-LT will define or refer to data categories, as provided by
>>     DCR. I would go the same route as for domain: in these areas
>>     there is already a lot of existing metadata. ITS 2.0 can serve
>>     "as a glue" to make it easier to use the metadata in various systems.
>
>
>
>
> -- 
> Felix Sasaki
> DFKI / W3C Fellow
>