JiscMail Logo
Email discussion lists for the UK Education and Research communities

Help for WORDGRAMMAR Archives


WORDGRAMMAR Archives

WORDGRAMMAR Archives


WORDGRAMMAR@JISCMAIL.AC.UK


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

WORDGRAMMAR Home

WORDGRAMMAR Home

WORDGRAMMAR  September 2008

WORDGRAMMAR September 2008

Options

Subscribe or Unsubscribe

Subscribe or Unsubscribe

Log In

Log In

Get Password

Get Password

Subject:

Re: Default inheritance and relations

From:

jasper holmes <[log in to unmask]>

Reply-To:

Word Grammar <[log in to unmask]>

Date:

Thu, 4 Sep 2008 13:25:40 +0100

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (128 lines)

I don't mean by cutting in at the beginning like this to discount the
very useful discussion that has already taken place. It's just I
couldn't find anywhere else to sensibly come in.

This is a tricky one, isn't it and I remember we struggled with it
when we were in the same situation before. I think, though, that we
largely solved it, or caused it to disappear.

I think we looked at possible ways of putting two relationships into
conflict without one (transitive)isa-ing the other, rather as Lyne has
been suggesting, so that 13 would block 14 because of 'after'
overriding 'before'. We tried to state this in terms of some common
ancestor, as Dick is doing below. I think my favourite solution along
these lines was to say that there are some relationships that you can
only have one of: you can have as many dependents as you like so [X
extractee Y] doesn't override [X object Y], but you can only have one
'ordering' (let's call it that for now, until the next paragraph
anyway), so [X after Y] does override [X before Y].

Can't remember exactly why this didn't work out, but I don't think it
did. Fortunately, however, there is another solution, and this follows
Lynes other suggestion: [X after Y] and [X before Y] are not the right
way to represent the ordering relationships. I'd say something more
like this:
[91: word dependent X]
[92: word time Pw]
[93: X time PX]
[94: Pw < PX] ('less than')
[95: subject isa dependent]
[96: word subject Y]
[97: Y time PY]
[98: Pw > PY] ('greater than')

Then, for what it's worth, 97 overrides 93, since Y isa X.

I've been trying to think of other examples, in case they aren't
amenable to this kind of solution, but I can't. Perhaps there are
some; it's a bit of a hostage to fortune I guess to rely on none
turning up.

I think I've presented two almost solutions. I evaluate them (very
briefly) in the next message. Then there follows a message with a red
herring.

Jasper


On 8/28/08, Richard Hudson <[log in to unmask]> wrote:
>
>  Dear All,
>  After a long silence on this list, here's a question for you all. It's
> about how to make default inheritance work properly. We (at least, Mark Line
> and I) have an algorithm which promises to work reasonably smoothly in a
> computer system that Mark is building (and that should work more generally
> as well, of course), but only for one of the two kinds of situation that
> default inheritance has to deal with. My question is whether anyone has any
> bright ideas for handling the other kind. Here goes with the problem.
>
>  DI has to take as input a proposition [1: A R V], where A is the argument,
> R is the relation and V is the value, and apply it to some instance of A,
> called A'. "Applying it" means deciding whether or not to inherit [2:A' R'
> V'], a copy of [1], in the light of  the store of propositions P already
> stored for A'; and the crucial question is whether P contains a proposition
> which overrides [2].
>
>  For example, assume this database:
>  [3: Bird locomotion flying]
>  [4: Penguin locomotion swimming]
>  [5: Penguin is-a bird]
>
>  Store of propositions about Penguin', some particular penguin:
>  [6: Penguin' isa Penguin]
>  [4': Penguin' locomotion' swimming']  {inherited from [4]}, where
> [locomotion' is-a locomotion]
>
>  Question: can Penguin' also inherit [3']?
>  [3': Penguin' locomotion' flying']
>
>  The question assumes a potentially inheritable stored proposition IP and
> some potential overriding proposition OP - e.g. in the above IP = [3] and OP
> = [4'].
>
>  Type 1 inheritance:
>  Where IP and OP have the same relation but different values. This is easy,
> because we can define 'the same relation' as being where:
>
> IP = [A1 R1 V1]
>  OP = [A2 R2 V2]
>  and [R2 is-a R1].
>  There's not even any need to check the relation between V1 and V2, because
> it doesn't matter whether or not they're related; either way, the
> inheritance system ignores IP.
>
>  Type 2 inheritance:
>  Where IP and OP have the same value but different relations. This is the
> hard one, and I'm embarrassed to say that although I've been aware of the
> problem for years, I've also managed to avoid thinking about it. It's
> painfully easy to illustrate from word order rules:
>  [7: word dependent X]
>  [8: word before X]
>  [9: word subject Y]
>  [10: subject is-a dependent]
>  [11: word after Y]
>
>  Precisely what is it that prevents some word W from inheriting the
> following?
>  [12: W subject Z]
>  [13: W after Z]
>  [14: W before Z]
>  I've had various thoughts, but none that I really like, so I'd be
> interested to hear other ideas.
>
>  Best wishes, Dick
>
>
>
> --
>
>
> Richard Hudson, FBA. Emeritus Professor, University College London
>
> My web page: www.phon.ucl.ac.uk/home/dick/home.htm
> Why I support the academic boycott of Israel:
> www.phon.ucl.ac.uk/home/dick/home.htm#boycott
> My latest book: Language Networks. The New Word Grammar
>
>

Top of Message | Previous Page | Permalink

JiscMail Tools


RSS Feeds and Sharing


Advanced Options


Archives

April 2024
June 2021
October 2020
April 2020
March 2020
September 2019
June 2019
May 2019
April 2019
December 2018
September 2018
August 2018
July 2018
June 2018
April 2018
June 2017
April 2017
March 2017
February 2017
January 2017
December 2016
September 2016
August 2016
July 2016
June 2016
February 2016
November 2015
July 2015
April 2015
March 2015
February 2015
September 2014
August 2014
July 2014
June 2014
May 2014
March 2014
February 2014
October 2013
July 2013
June 2013
April 2013
March 2013
February 2013
January 2013
February 2012
February 2011
January 2011
June 2010
April 2010
March 2010
December 2009
August 2009
June 2009
April 2009
March 2009
February 2009
November 2008
September 2008
August 2008
July 2008
June 2008
May 2008
April 2008
March 2008
December 2007
October 2007
September 2007
August 2007
July 2007
June 2007
March 2007
February 2007
January 2007
2006
2005
2004
2003
2002
2001
2000
1999


JiscMail is a Jisc service.

View our service policies at https://www.jiscmail.ac.uk/policyandsecurity/ and Jisc's privacy policy at https://www.jisc.ac.uk/website/privacy-notice

For help and support help@jisc.ac.uk

Secured by F-Secure Anti-Virus CataList Email List Search Powered by the LISTSERV Email List Manager