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

Re: ANN: Draft text fragment ontology for NIF 2.0

From: Robert Sanderson <azaroth42@gmail.com>
Date: Sun, 12 Aug 2012 19:46:01 -0600
Message-ID: <CABevsUGSJ91sbxo_RMjzitG8HmKqT9Lw7LmtThhoUFWVnoJGOg@mail.gmail.com>
To: Sebastian Hellmann <hellmann@informatik.uni-leipzig.de>
Cc: public-openannotation <public-openannotation@w3.org>
Hi Sebastian

On Fri, Aug 10, 2012 at 5:30 PM, Sebastian Hellmann
<hellmann@informatik.uni-leipzig.de> wrote:
> Dear Robert,
> I am really surprised of your reaction. I think you are seeing this too
> narrow-minded and you are focusing too much on the '#' syntax, not on the
> semantics.

I guess my "meta-comment" was too brief, sorry for the confusion.  I
agree that we share a similar challenge, however what I was trying to
say is that mails to the list should, in general, be related
*directly* to the open annotation specifications and process.  And
while your announcement is about some documents that are somewhat
related, I don't want people to have to follow conversations on two
lists when one is more appropriate.

> If you think about it for a second, there is a whole group of people who
> have thought about selecting fragments of web resources for decades.

As far as the fragment issue goes, the current stance is that
FragmentSelector imports all of the good thinking of the past, and any
future good thinking :) So we're happy that we're reusing that work
and not re-inventing any wheels.

The issue, which you may not have in NIF, is that State (and the newly
considered Context) must be able to be applied at the Specific
Resource level.  These cannot be applied to a URI with a Fragment, or
there would be collisions when two people annotate the same segment of
a resource, at different times or using different http content
negotiation headers for example.

Thus we prefer a single approach (the explicit Selector approach)
rather than having to check at both client and server whether or not a
fragment URI is possible.

> Please don't get distracted, because they decided to use a compact syntax
> behind a '#' , the underlying question is the same. The difference between:
> <_:Target1>
>    oax:hasSource <http://example.com/example.txt>;
>    oax:hasSelector <_:Selector1> .
> <_:Selector1> a oax:TextOffsetSelector ;
>    oax:offset 44 ;
>    oax:range 15 .
> and
> <http://example.com/example.txt#char=44,15>  .
> is a mere syntactic one and they select the same content.  The
> transformation might not be lossless with OA being more expressive, of
> course.

Or using a FragmentSelector with an rdf:value of char=44,55  :)
The issue, as above, is that the compact URI with fragment version
does not allow different annotations to select those same 11
characters with the resource in different states, or in different

> Before I have to hear from you again, that OA will *never* use fragments,
> let me ascertain you, that I am looking for common semantics, *not* syntax.

:)  And it's not that OA will never use fragments directly, however
the prevailing consensus is that the benefits (compactness) are
outweighed by the disadvantages (not always possible so requires two
different models, and thus more code; can't be used with
state/context; and so forth, as per the discussion with Bernhard)

> With your TextOffsetSelector you have gone into the direction of
> http://tools.ietf.org/html/rfc5147, maybe you could include oax:beginLine
> and oax:endLine next. We can collect all properties together in the
> fragment.ttl and later you can just change the @prefix and NIF and OA will
> have the same semantics, but different syntax. I already renamed beginIndex
> and endIndex into offset/range. There are a lot of caltrops ahead. E.g. the
> XPointer/Xointer scheme was never registered.

The reason we didn't go in the direction of 5147 is twofold:
1.  We already have 5147 for text/plain, with FragmentSelector :)
2.  We wanted something that wasn't limited to text/plain, but could
work on any format that carries text.  Hence the recommendation to
ignore markup etc so as to avoid such issues.

On the other hand, I do hear you! We could rework TextOffsetSelector
to mirror the semantics of 5147 but not be limited to text/plain.  I'm
not against that, as it would make it easier for systems that
understand 5147  (open question as to whether there are any!) to also
process the Selector.

And the open question as to how to distinguish the meaning of the
fragment of course still exists! Should it be via (many) classes, and
if not ... how?

> So don't worry, there is enough work for all of us, even if we work together
> on this and share it.

Absolutely :)

Received on Monday, 13 August 2012 01:46:30 UTC

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