Re: Identification Problem [was: Re: Suggested EARL Changes]

I believe the EARL proposal at the moment lacks a URI from which one can
retrieve, verbatim, a copy of the representation instance that was
evaluated in
an EARL-reported test-exposure a.k.a. test-experience episode.

It is all well and good to identify what was tested by URI (and related
expressions).  For precision one needs to be able to, as Jim suggests, re-test
the old-date representation with the new tool if one wishes, after getting
different outcomes with two test exposures which differ in both date and tool.

This is exactly what I meant by trying to "localize the frontier in
experienced
outcomes."  You want to go back and locally fill in a regular pattern of test
exposures to see which difference made the difference.  Is the pass/fail
different because of the tool change, or because of the date change?

Al

At 07:08 AM 2001-12-10 , Jim Ley wrote:
>"Sean B. Palmer" <sean@mysterylights.com>
>> > Certainly, although I don't see how we, when we're
>> > external to the resource, can know enough to state
>> > that some resource is newer version of the old.
>>
>> The resource doesn't change, just the representations.
>
>That is a somewhat utopian view, but I take your point.  :-)
>
>> > My point is [not?] that we're introducing anything new,
>> > just that we're introducing the idea that testSubject/reprOf
>> > is threaded [...]
>>
>> Well, the idea of a resource is threaded in a sense. That doesn't
>> enable us to *necessarily* conclude that we should drop old
>> evaluations, just that there is a thread of entities assocaited with
>> that resource.
>
>There are evaluations of various states of that resource, there's no
>definitive thread, just because some evaluation is dated later, it
>doesn't have any intrinsic bearing on the former evaluation unless it's
>an identical tool doing the evaluation.  The meaning can all be infered,
>and this includes threading issues.
>
>> To ground it in a scenario... the thing that started this was of the
>> broken page that is fixed by an author and re-evaluated. If you put
>> both of the evaluations into a database, you want to test if the
>> representation of the resource has been fixed.  You can do that by
>> using the threading of a resource as an assumption.
>
>PageValet asserts <http://www.e-media.co.uk/>http://www.e-media.co.uk/ on
2001-12-10 fails valid
>HTML
>JimsValidator asserts <http://www.e-media.co.uk/>http://www.e-media.co.uk/ on
2001-12-11 passes
>valid HTML
>
>If we make the threading assumption then we would conclude that it was
>valid - rather than my validator is completely flawed (this would be a
>more likely scenario with something less well defined than validity.)
>
>> There is nothing
>> in EARL that says you must make that assumption, it is a function of
>> the person controlling the database.
>
>Indeed, so we need to make no allowances for threading or a resource.  If
>we evaluate things, and describe their state (which we already do) then
>all threading can be infered, but it requires knowledge outside of the
>EARL about the resource, and the people making the assertions.
>
>The original scenario would seem to be better served by an assertion
>about the previous assertion.
>
>theEvaluation: Sean asserts (
<http://www.e-media.co.uk/>http://www.e-media.co.uk/ fails validity )
>Jim asserts theEvaluation  fixed
>
>So if we want to say something about the previous assertion, we say
>something about the previous assertion, we don't try to impose structure
>on the resource (which it may not have, or certainly won't externally
>know what it is.) and then infer from that what we originally wanted to
>say.
>
>Jim.
>

Received on Monday, 10 December 2001 10:08:01 UTC