I strongly supported this yesterday so go for me f 2015-05-31 16:05 GMT+02:00 Peter Stadler :

I see this as an improvement and can’t see any pitfalls.

Cheers Peter

...

Am 31.05.2015 um 10:02 schrieb Martin Holmes :

Hi all,

This ticket:

https://sourceforge.net/p/tei/feature-requests/561/

arose out of our re-working yesterday of Laurent's standoff proposal. I'd like to fast-track it if we can; it seems straightforward to me, and doesn't involve any Birnbaum issues. While I get around to figuring out the actual change to the Spec file, could you all check to see if you have any objections to it in principle?

Cheers, Martin -- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

PLEASE NOTE: postings to this list are publicly archived

-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

PLEASE NOTE: postings to this list are publicly archived

-- Fabio Ciotti Dipartimento Studi Umanistici, Università di Roma Tor Vergata Presidente Associazione Informatica Umanistica Cultura Digitale

Yes, as we discussed this this is an improvement and I can see any caveat. Cheers, Stefan Am 31.05.2015 10:58 schrieb "Hugh Cayless" :

I think this is fine, and addresses a need I've heard expressed in other contexts.

Sent from my phone.

...

On May 31, 2015, at 10:41, Fabio Ciotti wrote:

I strongly supported this yesterday so go for me f

2015-05-31 16:05 GMT+02:00 Peter Stadler :

...

I see this as an improvement and can’t see any pitfalls.

Cheers Peter

...

Am 31.05.2015 um 10:02 schrieb Martin Holmes :

Hi all,

This ticket:

https://sourceforge.net/p/tei/feature-requests/561/

arose out of our re-working yesterday of Laurent's standoff proposal. I'd like to fast-track it if we can; it seems straightforward to me, and doesn't involve any Birnbaum issues. While I get around to figuring out the actual change to the Spec file, could you all check to see if you have any objections to it in principle?

Cheers, Martin -- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

PLEASE NOTE: postings to this list are publicly archived

-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

PLEASE NOTE: postings to this list are publicly archived

-- Fabio Ciotti Dipartimento Studi Umanistici, Università di Roma Tor Vergata Presidente Associazione Informatica Umanistica Cultura Digitale -- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

PLEASE NOTE: postings to this list are publicly archived -- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

PLEASE NOTE: postings to this list are publicly archived

I think it has to happen on both @certs, otherwise there will be serious confusion. Syd, you seem to be arguing that data.certainty itself ought to enable both options -- are you? Cheers, Martin On 2015-05-31 03:59 PM, Syd Bauman wrote:

Are we talking about the @cert of <certainty> or that of att.global.responsibility, or both?

And while we're at it, do we think data.certainty too lame for its other uses? They are: att.dimensions/@precision precision/@precision purpose/@degree

(The idea what we took the precision out of <precision> by replacing the arbitrarily precise @degree with the necessarily imprecise @precision is mind-boggling to me.)

At one point in my history on this issue I argued for exactly what Martin is proposing -- an alternation between the arbitrarily precise numerical representation and the necessarily imprecise words. After all, the two can never be confused with one another.

I think it would make sense to take a look at all uses of both data.certainty and data.probability and perhaps rationalize 'em. In the meantime, I see nothing wrong with checking this change in.