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

Re: New Draft comments: Publishing

From: Robert Sanderson <azaroth42@gmail.com>
Date: Mon, 28 Jan 2013 10:31:37 -0700
Message-ID: <CABevsUHHEWwdrQnhLUu7XLz9F1m4esznyFczP4YvTJDO-Lcsiw@mail.gmail.com>
To: Antoine Isaac <aisaac@few.vu.nl>
Cc: public-openannotation <public-openannotation@w3.org>
On Sun, Jan 27, 2013 at 10:37 AM, Antoine Isaac <aisaac@few.vu.nl> wrote:

> Continuing my comments

And continuing our thanks :)


> 1. Names in JSON serialization specification
> This has probably been discussed before I joined the group. But why are the
> names "body", "target", ..., "scope" not exactly following the labels of OA
> properties (oa:hasBody, oa:hasTarget, etc) just like all other names in the
> JSON serialization spec?

This was just to be more "JSON-friendly" rather than a strict 1:1
mapping into RDF.  The expectation was that developers wanting a JSON
serialization which happens to be RDF would be more comfortable with
these object/hash property names.

This doesn't quite work with the provenance predicates any more, but
they're at least not of the format "hasClass".

I'm pretty certain that no one has implemented this yet (other than
me), so we can go back the other way and have a strict name mapping.
The change would be to reintroduce the "has" for those predicates and
to map oa:styleClass to "styleClass" instead of "style".


> 2. The paragraph on embedding RDF graphs in 5.2 ("An unusual [...]
> serialized resource") could be quite confusing. Especially, it reads a bit
> out of synch with 5.4, which recommends using named graphs.

I agree that paragraph is confusing and that 5.4 isn't clearly
structured.  The intent, which I will fix, is:

* SHOULD just refer to a dereferencable HTTP URI for the graph
* if the graph is embedded:
   * SHOULD use Content in RDF
   * MAY use Named Graphs IFF trig/trix is requested with content negotiation

> I'd suggest:
> a. to keep the part on this in 5.2 minimal and refer to 5.4: "Embedding
> resources also allow to embed RDF graphs as a whole, as described in Section
> 5.4."

Agreed.

> b. to merge the current 5.2 paragraph in 5.4, which could be done by
> - giving a more general header to 5.4, "Annotations using Graphs"

+1

> - having the first paragraph of 5.4 become:
> [...]

Will fix.


> 3. Is oa:equivalentTo transitive?

I believe so.  If A equiv B, and B equiv C, then A equiv C.
(and C equiv B, and C equiv A, and B equiv A)


> 4. Is oa:equivalentTo meant to be used only for oa:Annotations?

No, it could also be used productively for embedded resources.  The
use case would be if two systems extract and republish an embedded
resource, they would give it different HTTP URIs.  However if both
asserted that the new URI was equivalent to the original's UUID, then
given the transitivity above, a further system could determine that
all three identifiers were related to the same content.

> *If yes* is it mappable to ore:similarTo [1]? This would relate to my very
> last comment on
> http://lists.w3.org/Archives/Public/public-openannotation/2013Jan/0044.html
> which I think was not really answered.

Sorry! Will go back to that :)

> Now that the spec has has been (rightly so) shifted to make oa:Annotation a
> more conceptual, less serialization-focused notion, it could be harmful to
> have it likened to an ORE Aggregation.

The intent of ore:similarTo was to link to other identifiers for the
"work" that are not identifiers for the aggregation.
For example a particular aggregation of PDF, plus DOC plus a dataset
and an experiment could be ore:similarTo a DOI that identifies (cough,
handwave, mumble) a journal article.

I think that equivalentTo is a stronger statement than that level of
similarity, but we get close to ontology in the philosophical sense of
the word.  If every plank/URI of a ship/Annotation is replaced, is it
still the same/equivalent ship/Annotation?

The intent of equivalentTo is to help federating systems to determine
that two Annotations are similar enough that only one needs to be
maintained or processed.  That even though they have different URIs,
they express the same concept and hence should not both be rendered to
a user, processed for reputation models, or even take up space on
disk.

Technically, the domain of ore:similarTo is ore:Aggregation.  Which
would then have reasoners assume that the Annotation is an
Aggregation. Which doesn't work

I can strengthen the discussion of equivalentTo in this way if that would help?

Rob
Received on Monday, 28 January 2013 17:32:05 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 28 January 2013 17:32:06 GMT