agtk-devel — AGTK Developers Mailing List

[agtk-devel] success on solaris

[Eugene K. <ek...@sl...>]

Just wanted document my successful installation of aglib-1.1 on Solaris, 
for reference by future Solaris and agtk users :

OS (uname -a): SunOS sunfire-01 5.9 Generic_112233-05 sun4u sparc 
SUNW,Sun-Fire-280R
compiler (gcc --version) : gcc (GCC) 3.2.2

Xerces 1.7.0 configured with :
    sh runConfigure -psolaris -cgcc -xg++ -P/usr/local
    make && make install

aglib-1.1 configured with :
./configure --with-xercesc-lib=/usr/local/xerces-c-1_7_0/lib 
--with-xercesc-include=/usr/local/xerces-c-1_7_0/include/xercesc/ 
--enable-aif --enable-ag_python
  make && make install

after this, agapps-1.1/python/TableTrans.py should work.

-Eugene

success on linux; was Re: [agtk-devel] good starting point for compatible versions on Unix?

[Eugene K. <ek...@sl...>]

Hi Haejoong,

    I'm pleased to report that the "Open Annotation File (in XML)" 
functionality works fine on Linux/x86. I have :

-a Redhat 9.0 distro with installed python2.2.2

-used g++ 3.2.2 to compile :
 -xerces1.7.0
   -compiled with : sh runConfigure -plinux -cgcc -xg++ -P/usr/local
 -aglib1.1
   -compiled with : ./configure 
--with-xercesc-include=/usr/local/include/xercesc --enable-aif 
--enable-ag_python
 -agapps1.1
   -run time environment :
    PYTHONPATH=/usr/local/lib/ag_wrapper/python
    then just run TableTrans.py

So, I think the problem has to do with my Solaris setup. I'll keep 
playing with it, but it's nice to know that the Linux version works.
I'll try to duplicate the above setup as closely as possible on Solaris.

(Maybe it's just me, but it seems far more difficult to get GNU 
development tools to work on Solaris; for example gdb randomly crashes 
or hangs, shared libraries report missing symbols, ..etc)

Thanks a lot for your help again!
-Eugene

Re: [agtk-devel] good starting point for compatible versions on Unix?

[Eugene K. <ek...@sl...>]

Haejoong Lee wrote:

>
>
> That will be definitely helpful.  Please give us more information.


When I run TableTrans.py, I go to the menu and select : File | Open 
Annotation File | Open Annotation File in XML

In the file chooser dialog I choose : demo1.xml

I then get a popup window that says :

Error: 1
AttributeError Exception in Tk callback
  Function: <bound method agTableTrans.bindOpenAnnotationFileInXML of 
<agtk.agTableTrans.agTableTrans instance at 0x2a2930>> (type: <type 
'instance method'>)
  Args: ()
Traceback (innermost last):
  File 
"/usr/local/python-2.2.2/lib/site-python/Pmw/Pmw_1_1/lib/PmwBase.py", 
line 1735, in __call__
    return apply(self.func, args)
  File "./agtk/agTableTrans.py", line 776, in bindOpenAnnotationFileInXML
    self.loadAnnotationFileInXML(file.name)
  File "./agtk/agTableTrans.py", line 889, in loadAnnotationFileInXML
    except ag.AGWError, err:
AttributeError: 'module' object has no attribute 'AGWError'

Also, in the console from which I started TableTrans.py I get this message :

agf:Colons are not allowed in this name when namespaces are enabled

I'm using xercesc2_2, and I configured aglib with the following 
configure line :

./configure --disable-python-pkgdir --disable-ag_tcl --enable-ag_python 
--prefix=/home/ekoontz/install-solaris --enable-aif 
--with-xercesc_include=/usr/local/include/xercesc

(I set --disable-python-pkgdir so that the python libraries would be 
installed in my --prefix rather than in /usr/local/lib/python.

I have the following environment variables set :
LD_LIBRARY_PATH=/home/ekoontz/install-solaris/lib:/usr/local/lib
PYTHONPATH=/home/ekoontz/install-solaris/lib/ag_wrapper/python

My /home/ekoontz/install-solaris/lib directory looks like :

/home/ekoontz/install-solaris/lib/libag.so.1.0.0
/home/ekoontz/install-solaris/lib/libag.so.1
/home/ekoontz/install-solaris/lib/libag.so
/home/ekoontz/install-solaris/lib/libag.la
/home/ekoontz/install-solaris/lib/libag.a
/home/ekoontz/install-solaris/lib/ag_wrapper
/home/ekoontz/install-solaris/lib/ag_wrapper/python
/home/ekoontz/install-solaris/lib/ag_wrapper/python/ag.so.1.0.0
/home/ekoontz/install-solaris/lib/ag_wrapper/python/ag.so.1
/home/ekoontz/install-solaris/lib/ag_wrapper/python/ag.so
/home/ekoontz/install-solaris/lib/ag_wrapper/python/ag.la
/home/ekoontz/install-solaris/lib/ag_wrapper/python/ag.a

I am also trying to figure out what's going on with 
aglib-1.1/demo/AIF_test .
When I run that I get :

agf:Colons are not allowed in this name when namespaces are enabled
Abort (core dumped)

If I can find the reason why this is crashing, I'll post that as well.

Re: [agtk-devel] good starting point for compatible versions on Unix?

[Haejoong L. <hae...@un...>]

Eugene Koontz wrote:

> Haejoong Lee wrote:
>
>>
>>
>> Were you able to compile aglib-1.1 with XercesC 2.2?  I thought 
>> compilation would fail with recent versions of XercesC.
>
>
> Hi Haejoong,
>
> Thanks so much for your reply. What XercesC version do you recommend 
> for aglib/agapps 1.1?


Any version from 1.4.0 ~ 2.0.0 will be fine.  I think we were using 
1.6.0 or 1.7.0 when we released aglib-1.1.

Haejoong

Re: [agtk-devel] good starting point for compatible versions on Unix?

[Eugene K. <ek...@sl...>]

Haejoong Lee wrote:

>
>
> Were you able to compile aglib-1.1 with XercesC 2.2?  I thought 
> compilation would fail with recent versions of XercesC.

Hi Haejoong,

Thanks so much for your reply. What XercesC version do you recommend for 
aglib/agapps 1.1?

-Eugene

Re: [agtk-devel] good starting point for compatible versions on Unix?

[Haejoong L. <hae...@un...>]

Eugene Koontz wrote:

> Hi agtk developers,
>
>    I'm trying to get started with agtk on Linux and/or Solaris. I was 
> wondering if someone can give me a list of versions of aglib and 
> agapps that work well together. For agapps, I only care about being 
> able to run TableTrans (the python application).
>    I've tried several combinations, for example, agapps-1.1 and 
> aglib-1.1, together and things seem to work - *until* I try to open 
> one of the example XML files in the annotations/ directory. 


TableTrans with aglib-1.1 is a working combination, I think.

>    Rather than complain to you about error messages, I thought I'd 
> first make sure I'm using a combination of libs/apps that works well 
> for others. If the error messages would be helpful I can report those 
> too.


That will be definitely helpful.  Please give us more information.

> I'm also using XercesC 2.2, python 2.2.2, and Tcl 8.4 but could 
> up/downgrade these too if necessary.


Were you able to compile aglib-1.1 with XercesC 2.2?  I thought 
compilation would fail with recent versions of XercesC.

Thanks,
Haejoong

[agtk-devel] good starting point for compatible versions on Unix?

[Eugene K. <ek...@sl...>]

Hi agtk developers,

    I'm trying to get started with agtk on Linux and/or Solaris. I was 
wondering if someone can give me a list of versions of aglib and agapps 
that work well together. For agapps, I only care about being able to run 
TableTrans (the python application).
    I've tried several combinations, for example, agapps-1.1 and 
aglib-1.1, together and things seem to work - *until* I try to open one 
of the example XML files in the annotations/ directory.
    Rather than complain to you about error messages, I thought I'd 
first make sure I'm using a combination of libs/apps that works well for 
others. If the error messages would be helpful I can report those too.

I'm also using XercesC 2.2, python 2.2.2, and Tcl 8.4 but could 
up/downgrade these too if necessary.

Thanks,
    Eugene

Re: [agtk-devel] Tags internal to Feature

[Sean H. <she...@ug...>]

Just tried it, and it seems to work fine.  All I have to do is write the 
scripts to transform the entities into brackets, and vice versa.  
Shouldn't be a big deal.  Thanks for the input.

Sean

On 6 Jun 2003 at 6:50, Steven Bird wrote:

> On Fri, 2003-06-06 at 00:04, Sean Hendricks wrote:
> 
> > I tried putting in some markup within the content of a feature tag, 
> > and the markup is stripped out before being loaded into TableTrans.  
> > Then, when I save it to another AG XML file, the tags are no longer 
> > there.
> 
> Haejoong's solution (use < and >) is fine so long as the load
> process converts them to their readable versions for display, and the
> save function stores them again as entities.  To test this, add a ">" to
> a cell in TableTrans, save it to XML, then load it again and see if the
> ">" is still there.
> 
> -Steven Bird
> 
> 
> 

Re: [agtk-devel] Tags internal to Feature

[Steven B. <sb...@cs...>]

On Fri, 2003-06-06 at 00:04, Sean Hendricks wrote:

> I tried putting in some markup within the content of a feature tag, 
> and the markup is stripped out before being loaded into TableTrans.  
> Then, when I save it to another AG XML file, the tags are no longer 
> there.

Haejoong's solution (use < and >) is fine so long as the load
process converts them to their readable versions for display, and the
save function stores them again as entities.  To test this, add a ">" to
a cell in TableTrans, save it to XML, then load it again and see if the
">" is still there.

-Steven Bird

Re: [agtk-devel] Tags internal to Feature

[Haejoong L. <hae...@un...>]

Steven Bird wrote:

>Hi Sean,
>
>On Thu, 2003-06-05 at 01:15, Sean Hendricks wrote:
>  
>
>>Hello all,
>>
>>I apologize if this has been addressed before, but I can't access the archives to find 
>>out.
>>    
>>
>
>Sorry about that - to access the list archives you needed to be logged
>in to sourceforge.  I've now made the list public so that signing in is
>no longer required.  (But posts are still only permitted from list
>members).
>
>  
>
>>I was wondering how one might address tags that are internal to the Feature 
>>element.  For example, if one had the following in an AG:
>>
>><Feature name="content">This is some linguistic data.</Feature>
>>
>>And one wished for the content to be tagged with features such as stress, like the 
>>following:
>>
>><Feature name="content">This is some <stress>linguistic</stress> data.</Feature>
>>    
>>
>
>Within AGLIB the value of a feature is an uninterpreted string.  In the
>XML DTD, the content of a feature is PCDATA.  So it is fine on both
>counts to include well-formed XML markup.
>
>There's one caveat though - I'm not sure what assumptions the file I/O
>module makes about the content of features.  (Haejoong would you please
>let us know if you see any problem with this?)
>  
>
The '<' and '>' and other characters that are reserved for XML should be escaped, I think. So '<' should be '&lt;' and '>' should be '&gt;', etc.  Otherwise the string will be processed by the XML parser and the original content won't be preserved.

An alternative is to use CAG format, which is not XML. Any string (feature value and metadata value) will be preserved in this format.  No escaping needed.

-Haejoong

Re: [agtk-devel] Tags internal to Feature

[Sean H. <she...@ug...>]

On 5 Jun 2003 at 14:20, Steven Bird wrote:

> Within AGLIB the value of a feature is an uninterpreted string.  In the
> XML DTD, the content of a feature is PCDATA.  So it is fine on both
> counts to include well-formed XML markup.
> 
> There's one caveat though - I'm not sure what assumptions the file I/O
> module makes about the content of features.  (Haejoong would you please
> let us know if you see any problem with this?)

I tried putting in some markup within the content of a feature tag, 
and the markup is stripped out before being loaded into TableTrans.  
Then, when I save it to another AG XML file, the tags are no longer 
there.

Is there a good place within the code that I could look into to see 
why this might be?

Sean

Re: [agtk-devel] Tags internal to Feature

[Steven B. <sb...@cs...>]

Hi Sean,

On Thu, 2003-06-05 at 01:15, Sean Hendricks wrote:
> Hello all,
> 
> I apologize if this has been addressed before, but I can't access the archives to find 
> out.

Sorry about that - to access the list archives you needed to be logged
in to sourceforge.  I've now made the list public so that signing in is
no longer required.  (But posts are still only permitted from list
members).

> I was wondering how one might address tags that are internal to the Feature 
> element.  For example, if one had the following in an AG:
> 
> <Feature name="content">This is some linguistic data.</Feature>
> 
> And one wished for the content to be tagged with features such as stress, like the 
> following:
> 
> <Feature name="content">This is some <stress>linguistic</stress> data.</Feature>

Within AGLIB the value of a feature is an uninterpreted string.  In the
XML DTD, the content of a feature is PCDATA.  So it is fine on both
counts to include well-formed XML markup.

There's one caveat though - I'm not sure what assumptions the file I/O
module makes about the content of features.  (Haejoong would you please
let us know if you see any problem with this?)

-Steven Bird

[agtk-devel] Tags internal to Feature

[Sean H. <she...@ug...>]

Hello all,

I apologize if this has been addressed before, but I can't access the archives to find 
out.

I was wondering how one might address tags that are internal to the Feature 
element.  For example, if one had the following in an AG:

<Feature name="content">This is some linguistic data.</Feature>

And one wished for the content to be tagged with features such as stress, like the 
following:

<Feature name="content">This is some <stress>linguistic</stress> data.</Feature>

Such tags might be useful in other contexts, such as transforming data to a readable 
format for presentation, or in transformations to pick out such features.  It is my 
understanding that <Feature> cannot include other elements.

Just curious,

Sean Hendricks

[agtk-devel] question on AGAPI

[Guido Di M. <gui...@TI...>]

Dear all,
I hope you can give a solution to my simple problem ;-)

I wrote a xml parser which is able to build an AG througth the AGLIB
(using the agfio plug-in).
The annotation graph is made of a set of AGId, one for each speaker i=
n
the parsed file along the transcription.
The load method of the agfio plug-in returns a list<AGId>. That's fin=
e
for me, it works.
The problem comes when I have to write to a stream (cout or file outp=
ut)
the whole graph.
How can I build an AGSet from the list<AGId> in order to directly cal=
l
the toXML(AGSetId id) method ?

In the following a piece of code of the demo.cc for my plug-in:
=09agfio io;
=09map<string,string> signalInfo;
=09list<AGId> l =3D io.load("WPC", argv[1], "A1", &signalInfo);
=09cout << toXML(*l.begin()) << endl;

The last line prints just the first AGId and not the whole graph.
How can I get an istance of the AGsetId ?

Below I attach a short example of what I'd like to obtain with the
"toXML(AGSetId id)" method of AGAPI
and that I can actually obtain while building the graph while parsing
the original XML transcription (within the SAX Handler).

Thanks,
Guido Di Maio


<?xml version=3D"1.0"?>
<!DOCTYPE AGSet SYSTEM "ag.dtd">
<AGSet id=3D"WPC" version=3D"1.0" xmlns=3D"http://www.ldc.upenn.edu/a=
tlas/ag/"
xmlns:xlink=3D"http://www.w3.org/1999/xlink"
xmlns:dc=3D"http://purl.org/DC/documents/rec-dces-19990702.htm">
<Metadata>
</Metadata>
<Timeline id=3D"WPC:T1">
<Signal id=3D"WPC:T1:1" mimeClass=3D"test_mimeclass"
mimeType=3D"test_mimetype" encoding=3D"test_encoding" unit=3D"test_un=
it"
xlink:type=3D"simple" xlink:href=3D"test_uri" track=3D"test_track"></=
Signal>
</Timeline>
<AG id=3D"WPC:1" timeline=3D"WPC:T1">
<Metadata>
<MetadataElement name=3D"Speaker">EST</MetadataElement>
</Metadata>
<Anchor id=3D"WPC:1:1" offset=3D"0.000000" unit=3D"sec"
signals=3D"WPC:T1:1"></Anchor>
<Anchor id=3D"WPC:1:2" offset=3D"1.379000" unit=3D"sec"
signals=3D"WPC:T1:1"></Anchor>
<Anchor id=3D"WPC:1:3" offset=3D"3.536000" unit=3D"sec"
signals=3D"WPC:T1:1"></Anchor>
<Anchor id=3D"WPC:1:4" offset=3D"4.440000" unit=3D"sec"
signals=3D"WPC:T1:1"></Anchor>
<Anchor id=3D"WPC:1:5" offset=3D"4.440000" unit=3D"sec"
signals=3D"WPC:T1:1"></Anchor>
<Anchor id=3D"WPC:1:6" offset=3D"6.381000" unit=3D"sec"
signals=3D"WPC:T1:1"></Anchor>
<Anchor id=3D"WPC:1:7" offset=3D"6.381000" unit=3D"sec"
signals=3D"WPC:T1:1"></Anchor>
<Anchor id=3D"WPC:1:8" offset=3D"7.033000" unit=3D"sec"
signals=3D"WPC:T1:1"></Anchor>
<Anchor id=3D"WPC:1:9" offset=3D"7.936000" unit=3D"sec"
signals=3D"WPC:T1:1"></Anchor>
<Anchor id=3D"WPC:1:A" offset=3D"9.589000" unit=3D"sec"
signals=3D"WPC:T1:1"></Anchor>
<Annotation id=3D"WPC:1:E1" type=3D"utterance" start=3D"WPC:1:1" end=
=3D"WPC:1:2">
<Feature name=3D"sentence">o vieni / dai //</Feature>
</Annotation>
<Annotation id=3D"WPC:1:E2" type=3D"turn-EST" start=3D"WPC:1:1" end=
=3D"WPC:1:2">
</Annotation>
<Annotation id=3D"WPC:1:E3" type=3D"utterance" start=3D"WPC:1:3" end=
=3D"WPC:1:4">
<Feature name=3D"sentence">no //</Feature>
</Annotation>
<Annotation id=3D"WPC:1:E6" type=3D"turn-EST" start=3D"WPC:1:3" end=
=3D"WPC:1:8">
</Annotation>
<Annotation id=3D"WPC:1:E4" type=3D"utterance" start=3D"WPC:1:5" end=
=3D"WPC:1:6">
<Feature name=3D"sentence">ascolta / qui sopra ?</Feature>
</Annotation>
<Annotation id=3D"WPC:1:E5" type=3D"utterance" start=3D"WPC:1:7" end=
=3D"WPC:1:8">
<Feature name=3D"sentence">s=EC //</Feature>
</Annotation>
<Annotation id=3D"WPC:1:E7" type=3D"utterance" start=3D"WPC:1:9" end=
=3D"WPC:1:A">
<Feature name=3D"sentence">sopra &lt;i' piedino&gt; //</Feature>
</Annotation>
<Annotation id=3D"WPC:1:E8" type=3D"turn-EST" start=3D"WPC:1:9" end=
=3D"WPC:1:A">
</Annotation>
</AG>
<AG id=3D"WPC:2" timeline=3D"WPC:T1">
<Metadata>
<MetadataElement name=3D"Speaker">CLA</MetadataElement>
</Metadata>
<Anchor id=3D"WPC:2:1" offset=3D"1.609000" unit=3D"sec"
signals=3D"WPC:T1:1"></Anchor>
<Anchor id=3D"WPC:2:2" offset=3D"3.789000" unit=3D"sec"
signals=3D"WPC:T1:1"></Anchor>
<Anchor id=3D"WPC:2:3" offset=3D"7.033000" unit=3D"sec"
signals=3D"WPC:T1:1"></Anchor>
<Anchor id=3D"WPC:2:4" offset=3D"7.463000" unit=3D"sec"
signals=3D"WPC:T1:1"></Anchor>
<Anchor id=3D"WPC:2:5" offset=3D"7.463000" unit=3D"sec"
signals=3D"WPC:T1:1"></Anchor>
<Anchor id=3D"WPC:2:6" offset=3D"7.936000" unit=3D"sec"
signals=3D"WPC:T1:1"></Anchor>
<Anchor id=3D"WPC:2:7" offset=3D"8.701000" unit=3D"sec"
signals=3D"WPC:T1:1"></Anchor>
<Anchor id=3D"WPC:1:A" offset=3D"9.589000" unit=3D"sec"
signals=3D"WPC:T1:1"></Anchor>
<Anchor id=3D"WPC:2:8" offset=3D"9.851000" unit=3D"sec"
signals=3D"WPC:T1:1"></Anchor>
<Anchor id=3D"WPC:2:9" offset=3D"9.851000" unit=3D"sec"
signals=3D"WPC:T1:1"></Anchor>
<Anchor id=3D"WPC:2:A" offset=3D"11.140000" unit=3D"sec"
signals=3D"WPC:T1:1"></Anchor>
<Annotation id=3D"WPC:2:E1" type=3D"utterance" start=3D"WPC:2:1" end=
=3D"WPC:2:2">
<Feature name=3D"sentence">a patire //</Feature>
</Annotation>
<Annotation id=3D"WPC:2:E2" type=3D"turn-CLA" start=3D"WPC:2:1" end=
=3D"WPC:2:2">
</Annotation>
<Annotation id=3D"WPC:2:E3" type=3D"utterance" start=3D"WPC:2:3" end=
=3D"WPC:2:4">
<Feature name=3D"sentence">qui ?</Feature>
</Annotation>
<Annotation id=3D"WPC:2:E5" type=3D"turn-CLA" start=3D"WPC:2:3" end=
=3D"WPC:2:6">
</Annotation>
<Annotation id=3D"WPC:2:E4" type=3D"utterance" start=3D"WPC:2:5" end=
=3D"WPC:2:6">
<Feature name=3D"sentence">s=EC //</Feature>
</Annotation>
<Annotation id=3D"WPC:2:E8" type=3D"turn-CLA" start=3D"WPC:2:7" end=
=3D"WPC:1:A">
</Annotation>
<Annotation id=3D"WPC:2:E6" type=3D"utterance" start=3D"WPC:2:7" end=
=3D"WPC:2:8">
<Feature name=3D"sentence">&lt;s=EC s=EC / vai&gt; //</Feature>
</Annotation>
<Annotation id=3D"WPC:2:E7" type=3D"utterance" start=3D"WPC:2:9" end=
=3D"WPC:2:A">
<Feature name=3D"sentence">aspetta / me lo levo il &lt;calzino&gt; ?<=
/Feature>
</Annotation>
</AG>
</AGSet>

Re: [agtk-devel] [gilles@harfang.homelinux.org: AG Structure]

[Haejoong L. <hae...@un...>]

Hi Gilles,

>>For this question, please check:
>>
>>   http://agtk.sourceforge.net/doc/aglib/2.0/newformat.html
>>
>>    
>>
>
>I've had a quick look on that page. This seems really nice.
>I think there might be some mistakes in the last code example ('test.cc'):
>(1) in the first 2 lines, the #include directive is followed by nothing.
>(2) assuming Load and Store are methods, shouldn't they be called on some object?
>  
>

(1) was an HTML formatting problem.  Thanks for noticing me the error.
As for (2), note that that Load and Store are also defined in AGAPI.  
The test program is using AGAPI.

>That is indeed one of our main concerns:  How to produce an easy to read 
>transcript (i.e. compute the orthographic offsets) from the data stored in 
>the graph. But for this you must be able to sort the annotations.
>This was the purpose of my questions on the structure of an AIF file: Is 
>there a conventional way ("conventional" in the sense that it is not enforced
>by the DTD) to represent chronologically ordered annotations?
>>From my first trials (using XQuery), it seems that designing the sorting procedure 
>might not be obvious in the general case (i.e. when not all the anchors used have
>an offset).
>

...snip...

>
>  
>
>I understand that the AIF format does not prevent this sort of representation, 
>but then my question is, as above: Is there a conventional way to structure an 
>AIF file so that aglib is able to answer queries on the relative order of the 
>annotations that compose a graph?  For example, how would it be possible, for 
>a drawing program using aglib, to draw the example graphs given in Bird's and 
>Liberman's article "A Formal Framework for Linguistic Annotations"?
>
>Or is it that each project must provide its own representational convention (like
>in your "right_sibling" pointers example) to be able to recover some needed 
>structure (for example: which annotation comes before which)?  I think that the 
>reason AG is an attractive concept is because it really can represent a graph; 
>but then 
>(1) the in-memory graph structure dealt with by aglib should be self-sufficient 
>    to answer a query about the relative order of two annotations (i.e. starting 
>    from the first annotation, can I reach the second by following the edges of 
>    the graph)
>(2) there should be a way to represent a graph in AIF such that the appropriate
>    in-memory structure can be recovered.
>
>If you get what I mean (I'm afraid it might not be as clear as I would),
>does this make any sense to you?
>

Yeah, I know why AG is attractive, but often the artifacts like 
"right_sibling" are inevitable.  Sometimes I wonder if it's a limitation 
of AG.

Have you given a thought to the anchored AG?  I think it could be what 
you are looking for.  Although there are still cases where you can't 
compute the order of two annotations, it largely increases the 
computability of orders of annotations.

Folks, can anybody give him a definite answer, or should he devise his 
own convention?

Thanks,
Haejoong

[Fwd: Re: [agtk-devel] [gilles@harfang.homelinux.org: AG Structure]]

[Haejoong L. <hae...@un...>]

Re: [agtk-devel] AG graphical tool

[Steven B. <sb...@cs...>]

On Tue, 2003-05-13 at 16:51, Guido Di Maio wrote: 
> Dear all,
> I'm currently developing a text parser that produce a quite complex 
> annotation graph.
> In order to visually debug such a graph it would be really usefull a 
> tool which is able to display the graph structure.
> Does this tool exist somewhere ?
For our published documents we've often used graphviz 

http://www.research.att.com/sw/tools/graphviz/download.html

Here's an example input file.  It mightn't be too difficult to write
an AG save function which generates this format, then use the "dot"
command
to create a postscript image.

digraph timit {
rankdir=LR;
size="7,3";
node [shape=record,width=.2,height=.2,label="",fontsize=18,
fontname="Helvetica"];
edge [fontsize=36, fontname="Helvetica"];

node0[label = "<f0> 0|<f1> 0"];
node1[label = "<f0> 1|<f1> 2360"];
node2[label = "<f0> 2|<f1> 3270"];
node3[label = "<f0> 3|<f1> 5200"];
node4[label = "<f0> 4|<f1> 6160"];
node5[label = "<f0> 5|<f1> 8720"];
node6[label = "<f0> 6|<f1> 9680"];
node7[label = "<f0> 7|<f1> 10173"];
node8[label = "<f0> 8|<f1> 11077"];

"node0":f0 -> "node1":f0 [weight=2,label="P/h#"];
"node1":f0 -> "node2":f0 [weight=2,label="P/sh"];
"node2":f0 -> "node3":f0 [weight=2,label="P/iy"];
"node3":f0 -> "node4":f0 [weight=2,label="P/hv"];
"node4":f0 -> "node5":f0 [weight=2,label="P/ae"];
"node5":f0 -> "node6":f0 [weight=2,label="P/dcl"];
"node6":f0 -> "node7":f0 [weight=2,label="P/y"];
"node7":f0 -> "node8":f0 [weight=2,label="P/axr"];

"node1":f1 -> "node3":f1 [label="W/she"];
"node3":f1 -> "node6":f1 [label="W/had"];
"node6":f1 -> "node8":f1 [label="W/your"];

}

[agtk-devel] AG graphical tool

[Guido Di M. <gui...@TI...>]

Dear all,
I'm currently developing a text parser that produce a quite complex 
annotation graph.
In order to visually debug such a graph it would be really usefull a 
tool which is able to display the graph structure.
Does this tool exist somewhere ?

the TableTrans tcl/tk application do not seems to work for AG file with 
more than one annotation layer.
Thanks,

Guido Di Maio

Re: [agtk-devel] Missing Implementation of GetRef, was: AGAPI 2.0b1: GetAnchorSet returns unordered set

[Haejoong L. <hae...@un...>]

Matthias,

> There seems to be a little problem now, as you added GetRef to the 
> latest src/ag_wrapper/AGAPI.i, but the implementation in AGAPI.cc is 
> missing. Therefor, trying to use the scripting wrappers (I tried both 
> Tcl and Python) results in:
>
> % ./agtest.py /usr2/tho/annotation/scripts/test.xml
> Traceback (most recent call last):
>   File "./agtest.py", line 6, in ?
>     import ag
> ImportError: /usr/local/lib/ag/python/ag.so: undefined symbol: 
> _Z6GetRefSs


Sorry, I forgot to remove it.  I've updated the CVS with fixes.  Please 
update src/ag_wrapper directory of your copy.

Thanks,
Haejoong

[agtk-devel] Missing Implementation of GetRef, was: AGAPI 2.0b1: GetAnchorSet returns unordered set

[Matthias T. <th...@ei...>]

Hello Haejoong,

Haejoong Lee wrote:
> GetAnchorSet now returns a list.  Fixes are in the CVS. (I swear this 
> time :-)

There seems to be a little problem now, as you added GetRef to the 
latest src/ag_wrapper/AGAPI.i, but the implementation in AGAPI.cc is 
missing. Therefor, trying to use the scripting wrappers (I tried both 
Tcl and Python) results in:

% ./agtest.py /usr2/tho/annotation/scripts/test.xml
Traceback (most recent call last):
   File "./agtest.py", line 6, in ?
     import ag
ImportError: /usr/local/lib/ag/python/ag.so: undefined symbol: _Z6GetRefSs

Regards.
Matthias

Re: [agtk-devel] AGAPI 2.0b1: GetAnchorSet returns unordered set

[Steven B. <sb...@cs...>]

On Fri, 2003-05-09 at 00:51, Haejoong Lee wrote:
> Matthias,
> 
> Sorry for the confusion.  I forgot the semantics of GetAnchorSetByOffset 
> function in the previous post.  Yes you are right -- there is no reason 
> to prevent GetAnchorSet to return a time-ordered anchor list.  
> GetAnchorSet now returns a list.  Fixes are in the CVS. (I swear this 
> time :-)

Where do any untimed anchors end up in this list?

-Steven Bird

Re: [agtk-devel] AGAPI 2.0b1: GetAnchorSet returns unordered set

[Haejoong L. <hae...@un...>]

Steven,

>>Sorry for the confusion.  I forgot the semantics of GetAnchorSetByOffset 
>>function in the previous post.  Yes you are right -- there is no reason 
>>to prevent GetAnchorSet to return a time-ordered anchor list.  
>>GetAnchorSet now returns a list.  Fixes are in the CVS. (I swear this 
>>time :-)
>>    
>>
>
>Where do any untimed anchors end up in this list?
>  
>

Here's how anchors are ordered:

-------------------
bool operator < (const Anchor& a, const Anchor& b) {
  if (a.anchored && b.anchored && a.offset != b.offset)
    return a.offset < b.offset;
  else if (a.anchored && b.anchored && a.offset == b.offset)
    return a.id < b.id;
  else if (a.anchored && !b.anchored)
    return true;
  else if (!a.anchored && b.anchored)
    return false;
  else
    return a.id < b.id;
}
----------------------

Haejoong

Re: [agtk-devel] AGAPI 2.0b1: GetAnchorSet returns unordered set

[Matthias T. <th...@ei...>]

Hi Haejoong,

Haejoong Lee wrote:
> Sorry for the confusion.  I forgot the semantics of GetAnchorSetByOffset 
> function in the previous post.  Yes you are right -- there is no reason 
> to prevent GetAnchorSet to return a time-ordered anchor list.  
> GetAnchorSet now returns a list.  Fixes are in the CVS. (I swear this 
> time :-)

:) no problem, that's what mailing lists are for ;)

Thanks for the quick fix
Matthias

Re: [agtk-devel] AGAPI 2.0b1: GetAnchorSet returns unordered set

[Haejoong L. <hae...@un...>]

Matthias,

Sorry for the confusion.  I forgot the semantics of GetAnchorSetByOffset 
function in the previous post.  Yes you are right -- there is no reason 
to prevent GetAnchorSet to return a time-ordered anchor list.  
GetAnchorSet now returns a list.  Fixes are in the CVS. (I swear this 
time :-)

Thanks,
Haejoong


Matthias Thomae wrote:

> Hello Haejoong,
>
> I am a little confused :)
>
> Haejoong Lee wrote:
>
>> So you are looking for a function which returns a time-ordered anchor 
>> list?  Then, you can use GetAnchorSetByOffset.
>
>
> Well, but only if I set the epsilon parameter to infinity? ;)
>
> set<AnchorId> GetAnchorSetByOffset(AGId agId,Offset offset, double 
> epsilon=0.0)
>
> I thought this function was to get the anchors at a certain offset and 
> with epsilon distance around this offset, but not all anchors?
>
>
>
> However, in the implementation of GetAnchorSet in AGAPI.cc:
>
> set<AnchorId>
> GetAnchorSet(AGId agId)
> {
>   try {
>     AnchorSeq* aidset = Identifiers::getAGRef(agId)->getAnchorSet();
>     set<AnchorId> aids;
>
>     for (AnchorSeq::iterator pos = aidset->begin(); pos != 
> aidset->end(); ++pos)
>       aids.insert((*pos)->getId());
>     return aids;
>
>   } catch (AGException e) {
>     logError("GetAnchorSet",e);
>   }
> }
>
> the anchors are collected from getAnchorSet() in AG.h:
>
>   /// Get the set of anchors, sorted by offsets.
>   AnchorSeq* getAnchorSet() { return &I.anchorSet; }
>
> So this anchor *sequence* is already sorted by offsets and by ids iff 
> offsets are the same, as seen in Anchor.h
>
> /**
>  * Anchor compare function.
>  * A function to compare anchors by first comparing their offsets,
>  * then their ids if the offsets are the same.
>  **/
> class AnchorCompFunc {
>  public:
>   bool operator() (const Anchor* a1, const Anchor* a2) const {
>     return *a1 < *a2;
>   }
> };
>
> /**
>  * Anchor Seqquence.
>  * a set of anchors sorted by AnchorCompFunc, i.e. offsets
>  **/
> typedef set<Anchor*,AnchorCompFunc> AnchorSeq;
>
>
> So everything is already there, only the API function in AGAPI.cc 
> should return list<AnchorId> instead of set<AnchorId>
>
>
>> By the way, I just found two problems with ...SetByOffset functions.  
>> (There are two ...SetByOffset functions: GetAnchorSetByOffset and 
>> GetAnnotationSetByOffset.) It would have been better if the name was 
>> ...ListByOffset.  The real problem is that in C++ implementation they 
>
>
> For GetAnnotationSet this is already there:
>
> set<AnnotationId> GetAnnotationSetByOffset(AGId agId,Offset offset, 
> const AnnotationType& type="");
> list<AnnotationId> GetAnnotationSeqByOffset(AGId agId, Offset 
> begin=0.0, Offset end=0.0, const AnnotationType& type="");
>
> So if you introduce a complementary ..Seq.. function for Anchors, I 
> would also be happy. Still I think that GetAnchorSet should return a 
> list (and maybe be renamed to GetAnchorSeq).
>
>> return set<...> instead of list<...>.  This means what you get from 
>> these functions is actually a set of ids ordered by ids, not offsets!
>
>
> Yes, that's exactly my problem ;)
>
>> I've updated the CVS repository with the fixes; they return lists now.
>
>
> I just checked out the Toward-2_0 branch, and cannot find the changes. 
> In fact, I copied the above code from the sources just checked out.
>
>> This change doesn't affects Python and Tcl interfaces.  Thanks for 
>> making me realize those problems.
>
>
> You're welcome :)
>
>> Finally, the SWIG interface files are available from the CVS:
>>
>>    $ cvs -d:pserver:ano...@cv...:/cvsroot/agtk login
>>    [return at the login prompt]
>>    $ cvs  -d:pserver:ano...@cv...:/cvsroot/agtk co \
>>          -r Toward-2_0 AGLIB/src/ag_wrapper
>
>
> Thank you, I didn't realize that you made a branch and was already 
> wondering if you stopped updating the CVS ;)
>
> Regards.
> Matthias
>
>
> P.S. By the way, I have submitted two "Bug reports".
>
>
>
> -------------------------------------------------------
> Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
> The only event dedicated to issues related to Linux enterprise solutions
> www.enterpriselinuxforum.com
>
> _______________________________________________
> agtk-devel mailing list
> agt...@li...
> https://lists.sourceforge.net/lists/listinfo/agtk-devel
>
>

Re: [agtk-devel] AGAPI 2.0b1: GetAnchorSet returns unordered set

[Matthias T. <th...@ei...>]

Hello Haejoong,

I am a little confused :)

Haejoong Lee wrote:
> So you are looking for a function which returns a time-ordered anchor 
> list?  Then, you can use GetAnchorSetByOffset.

Well, but only if I set the epsilon parameter to infinity? ;)

set<AnchorId> GetAnchorSetByOffset(AGId agId,Offset offset, double 
epsilon=0.0)

I thought this function was to get the anchors at a certain offset and 
with epsilon distance around this offset, but not all anchors?



However, in the implementation of GetAnchorSet in AGAPI.cc:

set<AnchorId>
GetAnchorSet(AGId agId)
{
   try {
     AnchorSeq* aidset = Identifiers::getAGRef(agId)->getAnchorSet();
     set<AnchorId> aids;

     for (AnchorSeq::iterator pos = aidset->begin(); pos != 
aidset->end(); ++pos)
       aids.insert((*pos)->getId());
     return aids;

   } catch (AGException e) {
     logError("GetAnchorSet",e);
   }
}

the anchors are collected from getAnchorSet() in AG.h:

   /// Get the set of anchors, sorted by offsets.
   AnchorSeq* getAnchorSet() { return &I.anchorSet; }

So this anchor *sequence* is already sorted by offsets and by ids iff 
offsets are the same, as seen in Anchor.h

/**
  * Anchor compare function.
  * A function to compare anchors by first comparing their offsets,
  * then their ids if the offsets are the same.
  **/
class AnchorCompFunc {
  public:
   bool operator() (const Anchor* a1, const Anchor* a2) const {
     return *a1 < *a2;
   }
};

/**
  * Anchor Seqquence.
  * a set of anchors sorted by AnchorCompFunc, i.e. offsets
  **/
typedef set<Anchor*,AnchorCompFunc> AnchorSeq;


So everything is already there, only the API function in AGAPI.cc should 
return list<AnchorId> instead of set<AnchorId>


> By the way, I just found two problems with ...SetByOffset functions.  
> (There are two ...SetByOffset functions: GetAnchorSetByOffset and 
> GetAnnotationSetByOffset.) It would have been better if the name was 
> ...ListByOffset.  The real problem is that in C++ implementation they 

For GetAnnotationSet this is already there:

set<AnnotationId> GetAnnotationSetByOffset(AGId agId,Offset offset, 
const AnnotationType& type="");
list<AnnotationId> GetAnnotationSeqByOffset(AGId agId, Offset begin=0.0, 
Offset end=0.0, const AnnotationType& type="");

So if you introduce a complementary ..Seq.. function for Anchors, I 
would also be happy. Still I think that GetAnchorSet should return a 
list (and maybe be renamed to GetAnchorSeq).

> return set<...> instead of list<...>.  This means what you get from 
> these functions is actually a set of ids ordered by ids, not offsets!

Yes, that's exactly my problem ;)

> I've updated the CVS repository with the fixes; they return lists now.

I just checked out the Toward-2_0 branch, and cannot find the changes. 
In fact, I copied the above code from the sources just checked out.

> This change doesn't affects Python and Tcl interfaces.  Thanks for 
> making me realize those problems.

You're welcome :)

> Finally, the SWIG interface files are available from the CVS:
> 
>    $ cvs -d:pserver:ano...@cv...:/cvsroot/agtk login
>    [return at the login prompt]
>    $ cvs  -d:pserver:ano...@cv...:/cvsroot/agtk co \
>          -r Toward-2_0 AGLIB/src/ag_wrapper

Thank you, I didn't realize that you made a branch and was already 
wondering if you stopped updating the CVS ;)

Regards.
Matthias


P.S. By the way, I have submitted two "Bug reports".