- From: Antoine Isaac <aisaac@few.vu.nl>
- Date: Sun, 23 Sep 2012 23:09:13 +0200
- To: Paolo Ciccarese <paolo.ciccarese@gmail.com>
- CC: <public-openannotation@w3.org>
Yes, Paolo. By deprecation I understood simply "remove it". Antoine > 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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <tel:%2B1-857-366-1524> (mobile) +1-617-768-8744 <tel:%2B1-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 Sunday, 23 September 2012 21:09:50 UTC