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

"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/ on 2001-12-10 fails valid
HTML
JimsValidator asserts 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/ 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 07:10:09 UTC