Re: [ISSUE 34] Quality error category proposal

Hi Yves,

Thanks for the feedback

See below:

> Hi Arle, Phil, Felix, all,
> 
> So, now that's we've established we can work with implementation that use a referenced annotation rather than directly markup the content, we can move forward with the actual data of the quality-error.
> 
> Going back to the three attributes Arle/Felix proposed:
> 
>> *its-error: yes|no*
>> Identifies whether the element is an error or not. Default = no. (I don't
>> see that you'd ever explicitly set this locally for a value of no, but you
>> could, in theory.
>> 
>> *its-errorinfo: plain text*
>> Contains human-readable information about the error. For example, Yves'
>> tool could pass on its user error messages for consumption in this.
>> 
>> *its-error????: URI*
>> Contains a link to machine-readable information about the error. What that
>> information is we have yet to work out, but it could include a pointer for
>> the definition, the severity, etc.. Note: We need a name for this, but we
>> don't have a good one yet.
> 
> I see that this is pushing to get a very simple set of information and define more later.
> 
> - when is "later": after the summer or for ITS 3.0?

We're actually starting work on this topic in another DFKI project now, but I do not anticipate seeing anything suitable until later this year at the earliest (certainly later than September).

> - depending on what additional info is needed the URI pointer attribute may be useless (because we may end up defining just a few more attribute inline), so do we want to define something that we may not need later?

I think the URI pointer will be vital, even if it doesn't take the form described, because we will still need a way to point to the machine-readable definition of the error, however it will be defined. I was going to put up a trial-balloon XML file for what I think one of these might look like (still very preliminary), but the web space I was going to put it on has some problems, so I can't provide an actual example.

> Personally I see three more information:

> severity,

Agreed.

> type/code of error,

This is actually what I see the URL as supplying. Just a code by itself does not support interoperability. However, if we point to machine-readable information (and define what that information looks like, which obviously won't happen in the next week or so), then we can work towards interoperability. Would that be OK for you, or are you thinking of (a) a defined picklist or (b) simple native codes (like the ones you supplied me a while back)? I'm really hoping that your answer is that you don't want A or B.

> and a flag indicating if the given issue is active or not.

Good suggestion. What values would you suggest? I think there is more to it than whether it is active or not. For instance, a reviewer might catch and error and flag it in the file (making it active). It then goes back to the translator, who cannot resolve it or needs confirmation about the proposed resolution, in which case it is still active but you would treat it differently than in the first case. I tried to think of a good set of values, and what I came up with isn't worth the trouble of reading, but maybe you and Phil have some other ideas.


> Cheers,
> -yves

Best,

Arle

Received on Wednesday, 18 July 2012 07:35:40 UTC