Generator question

View: New views
3 Messages — Rating Filter:   Alert me  

Generator question

by Emily M. Bender :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Hi,

Recently, I've been experimenting with representing cognitive
status on indices in the Matrix (adapting the representations
in Borthen & Haugereid).  As a first pass, I've added a feature
COG-ST to the type index, with the value cog-st.  cog-st in
turn has one feature: [SPECI bool].  

This seems to be a problem for the generator: So long as
cog-st is a sort (no features), the cog-st value is respected
in generation. As soon as we add the feature SPECI, however,
the generator will ignore the type of the COG-ST value.

I thought that perhaps adding COG-ST to the list of *value-feats*
would do it, but it doesn't.  Is there some other way to
tell the generator to pay attention to that type, or is the
only option moving SPECI outside of COG-ST?

Thanks,
Emily

Re: Generator question

by Stephan Oepen :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

hi emily,

> This seems to be a problem for the generator: So long as cog-st is a
> sort (no features), the cog-st value is respected in generation. As
> soon as we add the feature SPECI, however, the generator will ignore
> the type of the COG-ST value.

i think your problem is strictly speaking not about the generator.  it
is important to acknowledge the difference between the grammar-internal
universe of typed feature structures and the grammar-independent world
of MRSs.  MRSs are not typed in a very interesting sense, and they have
very little accomodation for embedding of structures (i.e. recursion).

a typed feature structure

  ref-index & [ COG-ST foo ]

may correspond to an MRS variable, say,

  x42 { COG-ST: foo }

for convenience, MRS variables can have internal properties, but their
values are constrained to be atomic.  hence,

  ref-index & [ COG-ST foo & [ SPECI + ] ]

converts into

  x42 { COG-ST.SPECI + }

the process of constructing an MRS from its FS description, helpfully,
flattens out embedded structures and creates property names from paths
of feature names.  hence, even though `COG-ST.SPECI' looks a lot like
the TDL path notation, in the MRS universe it is a plain symbol, viz.
the name of that property.  there is no room for the sortal constraint
`foo' from the midst of the underlying path in that representation.

                i hope this helps clarify the issue?  all best  -  oe

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+++ Universitetet i Oslo (IFI); Boks 1080 Blindern; 0316 Oslo; (+47) 2284 0125
+++     CSLI Stanford; Ventura Hall; Stanford, CA 94305; (+1 650) 723 0515
+++       --- oe@...; oe@...; oepen@... ---
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Re: Generator question

by Emily M. Bender :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Yes, thanks.  We will reorganize our feature structures then.

Emily

On Wed, Mar 28, 2007 at 09:11:16PM -0800, Stephan Oepen wrote:

> hi emily,
>
> > This seems to be a problem for the generator: So long as cog-st is a
> > sort (no features), the cog-st value is respected in generation. As
> > soon as we add the feature SPECI, however, the generator will ignore
> > the type of the COG-ST value.
>
> i think your problem is strictly speaking not about the generator.  it
> is important to acknowledge the difference between the grammar-internal
> universe of typed feature structures and the grammar-independent world
> of MRSs.  MRSs are not typed in a very interesting sense, and they have
> very little accomodation for embedding of structures (i.e. recursion).
>
> a typed feature structure
>
>   ref-index & [ COG-ST foo ]
>
> may correspond to an MRS variable, say,
>
>   x42 { COG-ST: foo }
>
> for convenience, MRS variables can have internal properties, but their
> values are constrained to be atomic.  hence,
>
>   ref-index & [ COG-ST foo & [ SPECI + ] ]
>
> converts into
>
>   x42 { COG-ST.SPECI + }
>
> the process of constructing an MRS from its FS description, helpfully,
> flattens out embedded structures and creates property names from paths
> of feature names.  hence, even though `COG-ST.SPECI' looks a lot like
> the TDL path notation, in the MRS universe it is a plain symbol, viz.
> the name of that property.  there is no room for the sortal constraint
> `foo' from the midst of the underlying path in that representation.
>
>                 i hope this helps clarify the issue?  all best  -  oe
>
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> +++ Universitetet i Oslo (IFI); Boks 1080 Blindern; 0316 Oslo; (+47) 2284 0125
> +++     CSLI Stanford; Ventura Hall; Stanford, CA 94305; (+1 650) 723 0515
> +++       --- oe@...; oe@...; oepen@... ---
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++