Re: ANN: Draft text fragment ontology for NIF 2.0

Sebastian,

On Sun, Aug 12, 2012 at 9:46 PM, Robert Sanderson <azaroth42@gmail.com>wrote:

> 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.
>

Eventually, you can always point to that thread on the OA mailing list.
Did you interact with www-tag@w3.org? I believe W3C TAG is spending quite a
bit of time trying to coordinate the various fragid extension efforts. I
would rather play along with the standardization game. The goal is to
create interoperability and reduce surprises and conflicts.


>
>
> > 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
> formats.
>
>
> > 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 :)
>
> Rob
>
>
In general, I think what you call 'semantics of  is of interest for us. In
terms of syntax, personally, I don't like the idea of stuffing the long
list of possible details in URIs just for the sake of being brief. The
Media Fragments have been kept reasonably simple and, for what we needed to
do, we have been suggested by one of the initiators of that effort to go a
different way. What you are doing seems out of specs and one of the goals
of this group is to consider standards when they become available.

Making up random URIs and defining them in some arbitrary way locally is
perfectly consistent with the RDF specs, because strings in RDF that look
like URIs are not required to mean what the same string means according to
the URI spec. But, in your case, I am not sure on how do you deal with any
divergence in meaning depending on context. And on how you can control what
one gets from http://www.w3.org/DesignIssues/LinkedData.html. But again,
for feedback on those topics you should probably write to www-tag@w3.org,
which is the place where I believe things like that get properly discussed.

Paolo