W3C home > Mailing lists > Public > public-openannotation@w3.org > January 2013

Re: Annotation Concept vs Document (was Level 1 comments)

From: Robert Sanderson <azaroth42@gmail.com>
Date: Mon, 28 Jan 2013 15:34:39 -0700
Message-ID: <CABevsUHPR9cGsX1zNsB9J4y4bOfidT1BY77HL40-q0Y113rM1A@mail.gmail.com>
To: Antoine Isaac <aisaac@few.vu.nl>
Cc: public-openannotation <public-openannotation@w3.org>
I think we're close to straying off topic and would propose that we
take this off list :)

But ...


On Mon, Jan 28, 2013 at 3:06 PM, Antoine Isaac <aisaac@few.vu.nl> wrote:
> On 1/28/13 9:45 PM, Robert Sanderson wrote:
>> * The assumption was that if Annotation == Aggregation, then the
>> bodies and targets are the aggregated resources.
>> * The ORE docs say that non resolvable URIs cannot be aggregated.
>> This kills any UUID or blank node resource as an aggregated resource.
>
> Yes, that would be indeed a big contradiction. We should ask the ORE editors
> to change their spec ;-)

Ahem. Yes.

> Seriously, just asking in case: was it a strong position when making ORE?
> I'm not sure why it would break anything. I'm surprised anyone would never
> try to use a DOI for an aggregated resource (cough, handwave, mumble ;-) ).

There was significant discussion about it.

The major issues were:
* DOIs are not URIs. eg There's no DOI in:
http://www.iana.org/assignments/uri-schemes.html
Note in http://www.openarchives.org/ore/1.0/datamodel.html#ore:similarTo
the URI is an info:doi/ URI

* There was a strong feeling that as a set of _web_ resources, non
resolvable URIs did not have a place in the world view.  While I agree
with the principle, the stance taken may have been too strongly
worded.
(eg in http://www.openarchives.org/ore/1.0/datamodel#Aggregated_Resource)


>> * The Proxy construction for talking about the
>> resource-in-the-context-of-the-Annotation was not especially liked.
>> This would be the equivalent of a Specific Resource that we have now.
>
> I would disagree. In all examples I can think ok, the resources considered
> by the annotation are described in "objective" terms, not "specific to the
> annotation at hand". A text body and an image target do not change across
> context.

It was seen somewhat as the equivalent of reifying annotea's context predicate.

Eg there is some context described by the proxy in which the use of
the Source resource takes place.
And that context could include state, segment of interest, style [not
that we had it then] etc.

So it could be read as:  In the context of the annotation, I'm
referring to this segment of the resource.


> Hmm, in fact there is a problem: the styles. These can be
> annotation-specific. On the other hand, the OA spec seems to ignore happily
> to ignore the issue of reconciling annotations that would style differently
> a same body or target. So I'm not sure why we should consider proxies, when
> aligning annotations to ORE... Unless you want to embark on fixing the issue
> in OA as it is now ;-)

handwave, mumble, cough...   :)

We could add text to the paragraph starting "When rendering a Specific
Resource,...":

If a Specific Resource has a styleClass, but no such class is
described by a CssStyle attached to the Annotation, then the
styleClass MUST be silently ignored.


>> * The mandatory separation of Annotation/Aggregation and
>> (serialization)/ResourceMap
>
> Interesting point. In fact I had always understood ResourceMap to be
> slightly different from the kind of serialization we have in OA. Sentences
> like "a Resource Map that describes an Aggregation can readily be expressed
> in RDF/XML and other RDF serialization formats such as n3 and turtle" [1] or
> "Where RDF/XML is used to provide representations of ORE Resource Maps" [2]
> always made me think a Resource Map was not specific to a given syntax,
> especially. But I now realize I might have been wrong.

Thankfully I wasn't the lead editor on either of those docs ;)  but
yes, they are intended to have a specific media type [thank you
Stian!].


Rob
Received on Monday, 28 January 2013 22:35:07 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 28 January 2013 22:35:07 GMT