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

Re: Streamlining the OA Model oax:range vs, endIndex

From: Paolo Ciccarese <paolo.ciccarese@gmail.com>
Date: Sat, 22 Sep 2012 18:40:48 -0400
Message-ID: <CAFPX2kDfc9VK4cHN1her+Oo9dHUrxJ=-x44+wiukyb=W++2AgA@mail.gmail.com>
To: Antoine Isaac <aisaac@few.vu.nl>
Cc: public-openannotation@w3.org
I am good either way. However I wonder if, as we are at the draft stave and
we haven't published a first final spec yet, deprecation still makes sense.

On Sat, Sep 22, 2012 at 1:02 PM, Antoine Isaac <aisaac@few.vu.nl> wrote:

> +1 to what Bob said.
> No offense, but it's not as if the current model was a second version of
> some official standard. So it seems fair to deprecate a pattern that would
> be clearly sub-optimal. And probably at this stage the implementors who may
> have implemented the pattern to be removed can be contacted, to check with
> them if it's alright!
>
> Antoine
>
>
>  With this or \any/ change, there is always the problem of backward
>> compatibility.  If the proposed change (which I favor) is adopted, I
>> think the previous should be deprecated and people urged to even
>> consider publishing existing annotations in the new form also, perhaps
>> with an oa:equivalentAnnotation if necessary.
>>
>> Two semantically equivalent ways publishing always run a risk of some
>> kind of issue or other.  If both are in the core--so that both are
>> expected to be treated by compliant consumers, then in the current
>> case it seems like the main problem is that producers are imposing
>> more processing on consumers and this is probably a small burden for
>> small annotation collections.  But it might be serious for data miners
>> harvesting knowledge from large collections of annotations.
>>
>> Bob
>>
>>
>>
>>
>> On Fri, Sep 21, 2012 at 8:17 AM, Paolo Ciccarese
>> <paolo.ciccarese@gmail.com>  wrote:
>>
>>> Hi Sebastian,
>>> that observation has been made many times by people in the text mining
>>> community.
>>> It really seems expensive to calculate the 'end' through the range given
>>> the
>>> high number of annotations that can be machine generated.
>>>
>>> I think I am in favor of that change at this point.
>>>
>>> Maybe we can introduce a new selector with begin/end so that who has
>>> already
>>> implemented begin and offset will be still ok?
>>>
>>> Best,
>>> Paolo
>>>
>>>
>>> On Fri, Sep 21, 2012 at 3:38 AM, Sebastian Hellmann
>>> <hellmann@informatik.uni-**leipzig.de<hellmann@informatik.uni-leipzig.de>>
>>>  wrote:
>>>
>>>>
>>>> Hi all,
>>>> the meeting was really interesting and I learned a lot. For NIF 2.0, I
>>>> will draft such a document specifying a mapping, between the two
>>>> models.  I
>>>> think the most difficult part here are the mappings between the
>>>> selectors.
>>>>
>>>> Here is an initial question:
>>>> In http://www.openannotation.org/**spec/extension/#SelectorOffset<http://www.openannotation.org/spec/extension/#SelectorOffset>was there
>>>> any strong reason to use oax:range instead of something like end index.
>>>> When querying with SPARQL, you can:
>>>>
>>>> with range: order all selections by length, get all selection of a
>>>> specific length, query if any annotation begin at a certain position
>>>>
>>>> with begin, end index: query if any annotation are within a certain
>>>> region, query for overlaps and locality of annotations, i.e. is there an
>>>> annotation in this paragraph?
>>>>
>>>>
>>>> Addition/subtraction is quite an expensive aggregate. So what do you
>>>> think
>>>> is the more common use case. I would vote for begin and end index and
>>>> querying overlaps and inclusion. Maybe, we can do it similar to Apache
>>>> Stanbol, which also uses endIndex.
>>>>
>>>> Any opinions on this? Should I copy/paste and open an issue in the Wiki?
>>>> Or could there be consensus right the first time?
>>>>
>>>> Sebastian
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Am 15.09.2012 00:54, schrieb Randall Leeds:
>>>>
>>>>>
>>>>> On Wed, Aug 1, 2012 at 1:18 PM, Robert Sanderson<azaroth42@gmail.com>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>> 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?
>>>>>>
>>>>>
>>>>> I think it would be invaluable to people discovering OA and NIF to
>>>>> have such a document.
>>>>> +1
>>>>>
>>>>>
>>>>
>>>> --
>>>> Dipl. Inf. Sebastian Hellmann
>>>> Department of Computer Science, University of Leipzig
>>>> Events:
>>>> * http://sabre2012.infai.org/**mlode <http://sabre2012.infai.org/mlode>(Leipzig, Sept. 23-24-25, 2012)
>>>> * http://wole2012.eurecom.fr (*Deadline: July 31st 2012*)
>>>> Projects: http://nlp2rdf.org , http://dbpedia.org
>>>> Homepage: http://bis.informatik.uni-**leipzig.de/SebastianHellmann<http://bis.informatik.uni-leipzig.de/SebastianHellmann>
>>>> Research Group: http://aksw.org
>>>>
>>>>
>>>
>>>
>>> --
>>> Dr. Paolo Ciccarese
>>> http://www.paolociccarese.**info/ <http://www.paolociccarese.info/>
>>> Biomedical Informatics Research&  Development
>>>
>>> Instructor of Neurology at Harvard Medical School
>>> Assistant in Neuroscience at Mass General Hospital
>>> +1-857-366-1524 (mobile)   +1-617-768-8744 (office)
>>>
>>> CONFIDENTIALITY NOTICE: This message is intended only for the
>>> addressee(s),
>>> may contain information that is considered
>>> to be sensitive or confidential and may not be forwarded or disclosed to
>>> any
>>> other party without the permission of the sender.
>>> If you have received this message in error, please notify the sender
>>> immediately.
>>>
>>>
>>
>>
>>
>
>


-- 
Dr. Paolo Ciccarese
http://www.paolociccarese.info/
Biomedical Informatics Research & Development
Instructor of Neurology at Harvard Medical School
Assistant in Neuroscience at Mass General Hospital
+1-857-366-1524 (mobile)   +1-617-768-8744 (office)

CONFIDENTIALITY NOTICE: This message is intended only for the addressee(s),
may contain information that is considered
to be sensitive or confidential and may not be forwarded or disclosed to
any other party without the permission of the sender.
If you have received this message in error, please notify the sender
immediately.
Received on Saturday, 22 September 2012 22:41:17 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 22 September 2012 22:41:18 GMT