Biblical Hebrew Forum

[James Christian <jc.bhebrew AT googlemail.com>]

Hi Eric,

the problems with a generative grammar can be evaluated in terms of two
criteria:

1) under generation
2) over generation

That is to say does it reject acceptable sentences or does it accept
nonsense sentences. The idea of building a grammar building strategy is to
discover a rule set which does neither of the two. When starting with an
overly generic rule we are likely to over generate but not under generate.
When starting with an overly specific rule we are likely to under generate
but not over generate.

The first problem is to define a rule set which is satisfactory in terms of
not under or over generating. If you get into the situation where you have
so many rules that they obscure the underlying general rules but does not
under or over generate then congratulations. You've just made the most
successful generative grammar ever implemented.

With a strict bottom up approach then yes you are likely to end up with a
large rule set that obscures the underlying general rules but jump and leap
for joy if your rule set doesn't over or under generate. If having the most
compact representation is your goal then once you are in this ground
breaking position you are in a good position to start experimenting with
collapsing sets of more specific rules into less more generic ones. But when
this ends up with causing problems of over or under generation to arise you
may start to question whether the 'underlying general rules' are what we
assumed them to be before we started.

This is the beauty of using technology to experiment with a generative
grammar. It puts our theories to the test by turning the theoretical and
abstract into something practical and concrete. And so the goal is not so
much that of defining a Hebrew generative grammar as that of learning
something about what the data says about Hebrew in the process of attempting
to do so.

James Christian

On 19 June 2010 20:54, Eric Inman <eric-inman AT comcast.net> wrote:

>  Hi James,
>
> By out of hand I mean that the number of generative grammar rules becomes
> so large that they obscure what the underlying general rules and structures
> of the language really are. Thus there would probably be some other model
> that would do a better job of describing the language. My guess is that that
> model would probably include a generative grammar as a component, but other
> things would need to be involved along with it. If that's the case, then
> your project might still be useful by proceeding with your bottom-up
> approach until if and when it gets bogged down. At that point it might be
> clear what to add to the model in order to get it further along without
> getting bogged down.
>
> On the other hand, there might already be information about where things
> would get bogged down, and we could start looking at that much more quickly.
>
> If these problems exist, I don't think they would be due to using a
> top-down approach rather than a bottom-up one. I think the problems would
> occur either way. Nevertheless, I think a bottom-up approach would be my
> preference.
>
> Eric Inman
>
>  ------------------------------
> *From:* James Christian [mailto:jc.bhebrew AT googlemail.com]
> *Sent:* Saturday, June 19, 2010 12:12 PM
> *To:* Eric Inman
> *Cc:* dwashbur AT nyx.net; b-hebrew
>
> *Subject:* Re: [b-hebrew] Generation grammar and b-hebrew
>
> Hi Eric,
>
> traditionally in computational linguistics literature a distinction is made
> between deep and shallow methods. In general, deep methods are considered to
> be rule based while shallow methods are typical driven by statistical
> information. Obviously, shallow methods of generation can be used as well as
> deep methods and, no surprises, shallow methods are performing better than
> deep methods as in just about every other area of computational linguistics.
> But please don't fall into the classic trap of assuming that shallow methods
> have no rule system. They have a rule system, a very complex one. It just
> isn't made explicit.
>
> As you note 'the number of rules could get out of hand'. However, I would
> venture that the very reason shallow methods are working better than deep
> methods is precisely because they have many more implicit rules that give a
> wider coverage of real linguistic high frequency phenomenon. And so I would
> like to address the following part of your statement 'out of hand'.
>
> Now I'm not sure exactly what you mean by out of hand. If you are assuming
> that a large amount of rules is a bad thing then I don't necessarily agree.
> In fact, precisely the opposite. The very reason that most modern attempts
> to define a generative grammar aren't as wide coverage as they set out to be
> is because they are designed to be compact and, as a result, over generate.
>
> That is not to say I disagree with you entirely. If many rules are defined
> with no control of how they affect each other then unpredictable results
> will naturally arise. My personal experience suggests to me that starting
> from the specific and working up to the generic is a wiser approach to
> defining a generative grammar. Most attempts to build a generative grammar
> start with a generic sentence rule like:
>
> S --> NP VP
>
> It comes as no surprise that such attempts generally fail. They are
> starting with a linguistic assumption about the data that they have not
> extracted from the data but rather imposed upon it. This is what I would
> call a top down approach starting with a linguistic assumption about what
> the top is. It would seem to make more sense to me to adopt a bottom up
> approach with no linguistic assumptions other than letting the data speak
> for itself. That is to say to start by defining rules for the smallest
> frequently observable phenomenon and working your way up to sentence
> structure, paragraph structure etc. and thus letting the data speak for
> itself what the definition of S is. It may be S --> NP VP, it may be
> something entirely different or it may even be a whole collection of
> statements. The point is to let the data speak for itself.
>
> And so, Eric, what I would like you to consider is that it is not
> generative grammar in itself that is the problem. It the method of defining
> one that may be at fault. Please also bear in mind that statistical methods
> of generative grammar are also rule based. They only differ in that their
> rules system is superior and machine learned from the data.
>
> James Christian
>
> On 19 June 2010 14:55, Eric Inman <eric-inman AT comcast.net> wrote:
>
>> Here's why I think word order can be a problem. It's true that if you have
>> multiple word orders then you can define multiple rules. If you have a
>> unit
>> of speech where the next-level components can occur in different orders,
>> then providing the multiple rules to represent the different orders is not
>> a
>> problem.
>>
>> Where I think there might be a problem is when you have two or more units
>> of
>> speech whose components are intermingled with each other and can be
>> intermingled in many different ways. It's true that you can still define
>> multiple rules to handle this situation, but the problem is that the
>> number
>> of rules required to represent all of the permutations can get out of
>> hand.
>> At this point it appears that a generative grammar ceases to be a useful
>> model for describing the language, and I think there are probably other
>> models that would be more useful. I think this situation arises in Greek
>> but
>> I don't know if it would arise in Hebrew.
>>
>> I think whether or not this issue is premature would depend on whether or
>> not this is already known to be a problem in Hebrew. If it is, then
>> bringing
>> it up now might allow people to avoid repeating steps that have already
>> been
>> taken and instead move more directly to seeking a better approach to
>> handling what would be a known problem.
>>
>> What do you think?
>>
>> Eric Inman
>>
>> -----Original Message-----
>> From: b-hebrew-bounces AT lists.ibiblio.org
>> [mailto:b-hebrew-bounces AT lists.ibiblio.org] On Behalf Of dwashbur AT nyx.net
>> Sent: Friday, June 18, 2010 11:22 AM
>> To: b-hebrew
>> Subject: Re: [b-hebrew] Generation grammar and b-hebrew
>>
>>  Agreed.  In this vein I should also mention that I maintain a strict
>> separation between syntax and semantics/pragmatics/discourse/etc.  With
>> the
>> earlier Chomsky, I see syntax as a distinct component of the internal
>> grammar, and approach it as such.
>>
>> On 18 Jun 2010 at 14:46, James Christian wrote:
>>
>> > Hi,
>> >
>> > word order isn't a problem. If you have multiple word orders you can
>> > define multiple rules. You just define whatever rules the data
>> > supports whatever the language. However, at a higher level of grammar,
>> > the discourse level, word orders are not as arbitrary as they may
>> > seem. Word order, in many languages, expresses what in English is
>> > expressed by accenting an emphasised word or phrase. There may be
>> > contextual reasons for producing this kind of emphasis. Defining a
>> > contextual rule set that captures these nuances of a language would be
>> > challenging. You raise a good point. However, this is all a little too
>> > premature. If we've already got to the point where we are worrying
>> > about rules at this level then you already have a pretty darn good
>> > grammar. I foresee many lower level problems is properly defining
>> > rules for smaller chunks of language before we could even dream of
>> > being able to boast we are only left with these high level problems.
>> >
>> > James Christian
>> > _______________________________________________
>> > b-hebrew mailing list
>> > b-hebrew AT lists.ibiblio.org
>> > http://lists.ibiblio.org/mailman/listinfo/b-hebrew
>> >
>>
>>
>> Dave Washburn
>>
>> http://www.nyx.net/~dwashbur
>> _______________________________________________
>> b-hebrew mailing list
>> b-hebrew AT lists.ibiblio.org
>> http://lists.ibiblio.org/mailman/listinfo/b-hebrew
>>
>> _______________________________________________
>> b-hebrew mailing list
>> b-hebrew AT lists.ibiblio.org
>> http://lists.ibiblio.org/mailman/listinfo/b-hebrew
>>
>
>