Re: Annotea And EARL

Hi Jose,

> [...] I think that what you are requesting is a way to be able
> to use structured annotations in Annotea.

Not really - I meant using the Annotea framework to make EARL
evaluations on something, rather than putting EARL in the annotations.
Consider - the Annotea model consists of something like Page =>
Annotation. I know it's a lot more complicated than that, with bags
and so forth, but that's basically it - you're annotating a page. With
EARL, it's a similar with Page => Evaluation. EARL is also more
complicated than that, but that is the basic model. Now, if you put
the EARL evaluation inside the body, you get: Page => (Page =>
Evaluation)... which is a bit messed up - what if the pages are
different? Why repeat the mechanism? So EARL is like an annotation
mechanism of itself, *but* it doesn't make annotations - it makes
evaluations of resources compared to some Test Case, so it's actual
function is different.

IOW, what I think I'm asking for is if the Annotea software could be
modified so that instead of making annotations of pages, it could
instead make EARL Evaluations, and store them in a similar manner.
It's only triples... I've already hacked out a kind-of implementation
of this with the EARL Bookmarklet thing [1], but it's quite crude
because it's just a text-string-in-file thing, rather than a real
database system with authentication and all the glitzy bits that
Annotea has.

> IMO, Merging EARL with Annotea would require having an RDF
> object of type EARL or some other type that would include some
> or most of the Annotea properties, as well as the EARL properties.

It's possible that we could have done it that way, but EARL is in some
senses less clearly scoped than Annotea - you make evaluations about
tools, User Agents, and even bricks for all we care. Of course, in
HTTP space you can only really evaluate HTML documents and such and
such, but that's O.K. (we have earl:WebContent to describe that).

There are some EARL properties that are vaguely related to some
Annotea properties, for example "annot:author", "annot:created",
"annot:modified", but the EARL data model is quite different in its
constraints upon these, and how it uses them. The problem that I find
is that stating equivalences or similarities between a few properties
is all well and good, but if there are only a couple of (for example)
Dublin Core-ish terms in the EARL schema, there's no way that a Dublin
Core processor is going to suddenly go "oh hey, I understand EARL
now". What we need are full-blown inference engines to do that, and
the best we have at the moment is CWM [2] (which is pretty good).

> It's very use to combine properties from different RDF schemas.

Agreed, but note my points above. Also, I must state that I am a huge
advocate of getting people to share their data on the Semantic Web,
and bootstrapping new vocabularies, and indeed I'm a SWAG [3] Working
Group member - we're building an entire database (we call it a
dictionary) of semantic connections!

Partial understanding is one of the core flagstones of the Semantic
Web, but I think that it's better to record this information in the
schemata and third party databases than it is to put it in the
instances. I've thought about this a lot.

> Note that adding new RDF properties won't break other Annotea
> clients which are based on an RDF parsers. [...]

Great! That would be a nightmare... Still, it's awkward if a primitive
is added... for example, CWM wouldn't get anywhere if it didn't
recognize log:implies.

> That's because they would just ignore the properties they don't
> know anything about [...]

That's cool, but couldn't they work it out somehow if the particular
relationships between the new data and the current were stated?

> One thing we had been talking about is to be able to show RDF
> properties that we don't know how to interpret. That would
> mean that we could browse the EARL properties for a given
> resource, but, as we wouldn't know the semantics, we couldn't
> modify them or attach new properties.

Well, if you want to know the semantics, just look at the schema!
We've been very careful to ensure that there is as little prose
(actually, we'd better add some prose for the humans!) and as much
machine processable information in the schema as possible. It's our
hope that some machine will be able to work out what EARL is enough so
that it can process it... well, that's the idea, but the
implementation is falling behind a little, although we are going to be
making use of more DAML in the next version, which will help
considerable. DAML provides one with so much more power of expression.

> The report only exists in the answer from the WAI validator.
> This is interesting because if you modify the page to enhance its
> WAI aspects, some of the annotations would not be valid
> anymore. If you store the report on-line, it would become
> quickly obsolete.

I'm not precisely sure what you mean here, but I think it's something
to do with the dating of resources. In EARL (thanks to a suggestion
from Aaron Swartz), what we do is create new resources, out of a test
subject and a certain date. We also have a property that allows people
to point to a snapshot of the page, although I guess that is
non-normative. In any case, when you make an EARL Evaluation, you do
something like:-

   :Sean earl:asserts { :MyPage earl:passes :CP1 } .

And then you say:-

   :MyPage a earl:WebContent;
      earl:testSubject <http://mypage.org/>;
      earl:date "2001-03-17" .

So that the evaluations you are making are about the page *on that
date*. Thus, the evaluation is always true, unless the thing making
the assertion was lying, or was damaged, or something. Hey, you could
use EARL to evaluate the EARL evaluation processor :-) Actually,
Charles did that to my little bookmarklet thing...

> Of course, my reply here isn't the absolute, definitive reply :)
> Comments, flames, and feedback are welcome.

Same here :-)

[1] http://infomesh.net/2001/05/earl/bookmarklet/
[2] http://www.w3.org/2000/10/swag/cwm.py
[3] http://purl.org/swag/

--
Kindest Regards,
Sean B. Palmer
@prefix : <http://webns.net/roughterms/> .
:Sean :hasHomepage <http://purl.org/net/sbp/> .

Received on Sunday, 20 May 2001 18:16:39 UTC