W3C home > Mailing lists > Public > public-openannotation@w3.org > August 2012

Re: Streamlining the OA Model

From: Robert Sanderson <azaroth42@gmail.com>
Date: Wed, 1 Aug 2012 14:18:17 -0600
Message-ID: <CABevsUFeKsktxv7qu=hbpfj7t_W8siJy2CwvH4z_1jM8fb5M2A@mail.gmail.com>
To: Sebastian Hellmann <hellmann@informatik.uni-leipzig.de>
Cc: public-openannotation <public-openannotation@w3.org>
Hi Sebastian,

Perhaps I misunderstood! I thought you were proposing a (radical!)
change to the current OA model to follow the NIF approach.  And of
course it's no business of ours to say how NIF should deal with its
annotation syntax :)

On Wed, Aug 1, 2012 at 1:58 PM, Sebastian Hellmann
<hellmann@informatik.uni-leipzig.de> wrote:
> Dear Robert,
> Am 01.08.2012 21:16, schrieb Robert Sanderson:
>> To be clear, you know that this breaks the IETF restrictions on URI
>> fragments, right?
>> You can't just invent new fragment schemes for existing mime-types,
>> they MUST be specified in the mime type registration document.
> This is only for the retrieval actions. Specifying senses for URIs in RDF
> and OWL is *allowed* and even *promoted*.

It's part of the URI specification, RFC 3986.  See:
But the relevant part is:

The semantics of a fragment identifier are defined by the set of
   representations that might result from a retrieval action on the
   primary resource.  The fragment's format and resolution is therefore
   dependent on the media type [RFC2046] of a potentially retrieved
   representation, even though such a retrieval is only performed if the
   URI is dereferenced.

> See http://www.w3.org/TR/rdf-concepts/#section-fragID

This is true for RDF/XML where the mimetype registration specifies the
meaning of the fragment identifier.
See: http://tools.ietf.org/html/rfc3870#section-3

> Technical question: How come the MediaFragments are defined separately from
> the mime type?

They're willfully ignoring IETF's RFC 3986.  Early on in the Media
Fragment process we brought this up with them, along with
extensibility and several other issues and it was completely ignored
by the WG.

[snip design decisions]

> If you start
> calculating number of triples produced by the current Open Annotation Spec
> for part of speech tags, you will soon reach a very practical limit on how
> much text you can handle.

Yes. I agree that there are many use cases when it becomes a
significant burden to expose all of the possible data using RDF in
general, let alone Open Annotation.

"cat/NN" is a nice and compact representation that would be many many
times larger in RDF, yet it could be considered an annotation.  Using
the right tools for the job is *always* the first consideration :)

> NIF and Open Annotation complement each other nicely.

I would like to propose a joint work item to create a mapping document
between NIF and OA, if you think that would be useful?

Received on Wednesday, 1 August 2012 20:18:46 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:22:01 UTC