OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

uima message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [CAS Specification Subgroup] Getting Started


Hi,

I am not sure whether I thoroughly understood all the points of the earlier UIMA designers or not. However, based on the white paper, and UIMA TC's recent discussion about 5.3 issues, I have some comments for section 5.1 persuant to the 6-point skeleton  :

1. Goals of spec element.
I think the goals of CAS spec have been already well-defined at the beginning of section 5.1.

2. Overall Critique of section.
-Current spec meets the goal of interoperability thanks to Object model for CAS and XMI repsentation of CAS.
-However, section 5.1.3 is still unclear. To me, the concept of annotation, sofa, and regional reference are still not sufficient. With the current concepts, UIMA-users are too freely to design their own artifact metadata, which may also cause a confusion.

4. Open issues.
I think at first, we should make clear what "regional reference" means. On page 23, line 4, regional references are only mentioned with "e.g. offsets", which is unclear. (or did I miss the definition somewhere?) 

We should discuss more about:
         +Regional reference is the reference to a "continuous" or "discontinuous" region? (as Dave mentioned)
         If it is a continuous region then the current "Annotation" is just the first-level (or base) annotation concerning about multi-level annotation schemes.
         In my opinions, annotations are all regional referring and they are different in the way they refer. It can be directly-referring to continuous regions or indirect ones through other annotations. These "indirect" regional referring annotations express relations among annotations, for example, an "Protein-protein interaction"-event annotation relates 2 protein-annotations.

         +So, should we provide mechanisms to explicitly define the construction of higher-level annotations from base annotation? What are the difficulties of doing so? Is it possible and necessary or not?

         +About sofa, I think every annotation has its sofa. If we have higher-level annotations, there must be some constraints on their sofas. For example, the sofa of a high-level annotation must cover sofas of their subordinate annotations.

I know the UIMA-specification might become more complicated if we take relations of annotations into account but it deserves.

5. Compliance points.
I agree with 3 candidate compliant points. They are:
- 5.1.2, compliance point: objects in CAS conform to type-system
- 5.1.3, compliance point: "annotation model compliance"
- 5.1.4, compliance point: standard XMI CAS Representation

3. Votable issues.
- I think section 5.1.1, 5.1.2 are complete. They do not need any change I think.
- Vote to achieve agreement on 3 compliance points

6. Action plan.
-Discuss more about the design of "annotation model" and try to achieve the best solution (vote if necessary).


Regards,
NGAN Nguyen


Eric Nyberg wrote:
> Folks,
> 
> This message is intended to initiate the discussion for the CAS 
> Specification subgroup of the UIMA T-C. The current membership of the 
> subgroup:
> 
> Eric Nyberg (coordinator)
> Thilo Goetz
> Sofia Ananiadou
> Nguyen Ngan
> 
> Our report date is March 2 - at the end of next week. We are tasked with 
> reviewing section 5.1, "The CAS Specification", in the white paper, and 
> producing a 1-3 page report for presentation to the TC telecon on that date.
> 
> As per the instructions from Dave, the report should cover the following 
> outline:
> 
>    1. Goals of spec element. (What is it trying to achieve in terms of
> interoperability?)
> 
>    2. Overall Critique of section. High-level summary of findings. How
> good/bad is it in meeting goals? What's the damage? Looks good, just 
> needs some wordsmithing, has some serious conceptual issues, etc.
> 
>    3. "Votable" issues. Crisp decisions the TC should vote on required to
> harden/complete spec element.
> 
>    4. Open-Issues. Issues that need extended discussion to resolve
> 
>    5. List of compliance points. What aspects of this spec element "can",
> "must" be adhered to in order to  be "compliant"
> 
>    6. Action Plan. Very important -- List of tasks required to bring spec
> element to completion.
> 
> Given the time we have remaining, we should begin to gather input for 
> the report. It would be useful if each of the sub-group members could 
> complete their review of Section 5.1 and share their comments (pursuant 
> to points 1-6 above) with the list by Wednesday, February 28th. I will 
> take responsibility for merging the inputs into the draft report and 
> distributing it for comment.
> 
> Thanks for your prompt participation,
> 
> -ehn
> 
> 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]