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

Thanks a lot for the summary, Arle. One additional point below.

2012/7/4 Arle Lommel <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