- From: Robert Sanderson <azaroth42@gmail.com>
- Date: Sun, 23 Sep 2012 21:12:53 -0600
- To: public-openannotation@w3.org
I'm fine with removing the existing offset/range and replacing with the equivalent, but easier to query, begin/end text selector. Rob On Sun, Sep 23, 2012 at 3:09 PM, Antoine Isaac <aisaac@few.vu.nl> wrote: > 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 Monday, 24 September 2012 03:13:22 UTC