PowerLoom's BNF usage
|
View:
New views
8 Messages
—
Rating Filter:
Alert me
|
 |
PowerLoom's BNF usage
by Rich Morin
::
Rate this Message:
I've been digging into Chapter 11 of the manual, in order to
write a second-level parser (ie, recognize logsent, etc.). The BNF isn't exactly standard (or even correct in some places), so I have been getting confused about some rather basic things. Can someone confirm or deny (and then clarify) these statements? asterisk "*" An asterisk means "zero or more of this item". braces "{...}" Braces mean "zero or more of these items". brackets "[...]" Brackets mean "zero or one of these items". parentheses "(...)" Parentheses stand for themselves, rather than acting as grouping operators. plus sign "+" A plus sign means "one or more of this item". -r -- http://www.cfcl.com/rdm Rich Morin http://www.cfcl.com/rdm/resume rdm@... http://www.cfcl.com/rdm/weblog +1 650-873-7841 Technical editing and writing, programming, and web development _______________________________________________ powerloom-forum mailing list powerloom-forum@... http://mailman.isi.edu/mailman/listinfo/powerloom-forum |
|
|
Re: PowerLoom's BNF usage
by Hans Chalupsky
::
Rate this Message:
Rich,
the PowerLoom grammar was developed by a motivated visitor to our group, but we never scrutinized it much nor used it for anything, so it probably is incomplete, inconsistent and not quite up-to-date. Given that more people are getting serious about using it, we should fix that, firm it up and bring it in-line with the upcoming Common-Logic standard. That would also address the character set questions you voiced previously. With respect to the questions below, the only thing incorrect was your interpretation of braces, which we use as a grouping construct. Since they also mean something in Texinfo and require proper quoting, it looks like some of them didn't survive into the formatted version of the manual, we need to fix that. Hans >>>>> Rich Morin <rdm@...> writes: > I've been digging into Chapter 11 of the manual, in order to > write a second-level parser (ie, recognize logsent, etc.). > The BNF isn't exactly standard (or even correct in some places), > so I have been getting confused about some rather basic things. > Can someone confirm or deny (and then clarify) these statements? > asterisk "*" > An asterisk means "zero or more of this item". > braces "{...}" > Braces mean "zero or more of these items". > brackets "[...]" > Brackets mean "zero or one of these items". > parentheses "(...)" > Parentheses stand for themselves, > rather than acting as grouping operators. > plus sign "+" > A plus sign means "one or more of this item". > -r > -- > http://www.cfcl.com/rdm Rich Morin > http://www.cfcl.com/rdm/resume rdm@... > http://www.cfcl.com/rdm/weblog +1 650-873-7841 > Technical editing and writing, programming, and web development > _______________________________________________ > powerloom-forum mailing list > powerloom-forum@... > http://mailman.isi.edu/mailman/listinfo/powerloom-forum _______________________________________________ powerloom-forum mailing list powerloom-forum@... http://mailman.isi.edu/mailman/listinfo/powerloom-forum |
|
|
Re: PowerLoom's BNF usage
by Cameron Ross
::
Rate this Message:
Just thought I'd point out that Common Logic is now an ISO standard and can be downloaded free of charge from here: http://standards.iso.org/ittf/PubliclyAvailableStandards/c039175_ISO_IEC_24707_2007(E).zip. Are there any plans, or is there any interest in evolving PL-KIF to the Common Logic CLIF dialect? Does this even make sense?
Cameron Ross. On Fri, Jul 4, 2008 at 12:00 PM, Hans Chalupsky <hans@...> wrote: Rich, -- Cameron Ross, M.Sc. Director of Technology Symboticware Incorporated www.symboticware.com _______________________________________________ powerloom-forum mailing list powerloom-forum@... http://mailman.isi.edu/mailman/listinfo/powerloom-forum |
|
|
Re: PowerLoom's BNF usage
by Hans Chalupsky
::
Rate this Message:
Cameron,
thanks for the pointer. It definitely make sense to relate PL-KIF to CLIF and align them as much as possible. PowerLoom was intended to support multiple logic dialects (thus the "in-dialect" construct). If we can't reasonably make PL-KIF a superset of CLIF, we should at least be able to support them as alternative input language variants. Given that Common Logic is an actual ISO standard now, we have some motivation to attempt this fairly soon. Hans >>>>> Cameron Ross <cross@...> writes: > Just thought I'd point out that Common Logic is now an ISO standard and can > be downloaded free of charge from here: > http://standards.iso.org/ittf/PubliclyAvailableStandards/c039175_ISO_IEC_24707_2007(E).zip. > Are there any plans, or is there any interest in evolving PL-KIF to the > Common Logic CLIF dialect? Does this even make sense? > Cameron Ross. > On Fri, Jul 4, 2008 at 12:00 PM, Hans Chalupsky <hans@...> wrote: >> Rich, >> >> the PowerLoom grammar was developed by a motivated visitor to our >> group, but we never scrutinized it much nor used it for anything, so >> it probably is incomplete, inconsistent and not quite up-to-date. >> Given that more people are getting serious about using it, we should >> fix that, firm it up and bring it in-line with the upcoming >> Common-Logic standard. That would also address the character set >> questions you voiced previously. >> >> With respect to the questions below, the only thing incorrect was your >> interpretation of braces, which we use as a grouping construct. Since >> they also mean something in Texinfo and require proper quoting, it >> looks like some of them didn't survive into the formatted version of >> the manual, we need to fix that. >> >> Hans >> >> >>>>> Rich Morin <rdm@...> writes: >> >> > I've been digging into Chapter 11 of the manual, in order to >> > write a second-level parser (ie, recognize logsent, etc.). >> >> > The BNF isn't exactly standard (or even correct in some places), >> > so I have been getting confused about some rather basic things. >> > Can someone confirm or deny (and then clarify) these statements? >> >> > asterisk "*" >> >> > An asterisk means "zero or more of this item". >> >> > braces "{...}" >> >> > Braces mean "zero or more of these items". >> >> > brackets "[...]" >> >> > Brackets mean "zero or one of these items". >> >> > parentheses "(...)" >> >> > Parentheses stand for themselves, >> > rather than acting as grouping operators. >> >> > plus sign "+" >> >> > A plus sign means "one or more of this item". >> >> > -r >> > -- >> > http://www.cfcl.com/rdm Rich Morin >> > http://www.cfcl.com/rdm/resume rdm@... >> > http://www.cfcl.com/rdm/weblog +1 650-873-7841 >> >> > Technical editing and writing, programming, and web development >> > _______________________________________________ >> > powerloom-forum mailing list >> > powerloom-forum@... >> > http://mailman.isi.edu/mailman/listinfo/powerloom-forum >> _______________________________________________ >> powerloom-forum mailing list >> powerloom-forum@... >> http://mailman.isi.edu/mailman/listinfo/powerloom-forum >> > -- > Cameron Ross, M.Sc. > Director of Technology > Symboticware Incorporated > www.symboticware.com > Just thought I'd point out that Common Logic is now an ISO standard and can be downloaded free of charge from here: <a href="http://standards.iso.org/ittf/PubliclyAvailableStandards/c039175_ISO_IEC_24707_2007(E).zip">http://standards.iso.org/ittf/PubliclyAvailableStandards/c039175_ISO_IEC_24707_2007(E).zip</a>. Are there any plans, or is there any interest in evolving PL-KIF to the Common Logic CLIF dialect? Does this even make sense? <br> > <br>Cameron Ross.<br><br><br><br><div class="gmail_quote">On Fri, Jul 4, 2008 at 12:00 PM, Hans Chalupsky <<a href="mailto:hans@...">hans@...</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> > Rich,<br> > <br> > the PowerLoom grammar was developed by a motivated visitor to our<br> > group, but we never scrutinized it much nor used it for anything, so<br> > it probably is incomplete, inconsistent and not quite up-to-date.<br> > Given that more people are getting serious about using it, we should<br> > fix that, firm it up and bring it in-line with the upcoming<br> > Common-Logic standard. That would also address the character set<br> > questions you voiced previously.<br> > <br> > With respect to the questions below, the only thing incorrect was your<br> > interpretation of braces, which we use as a grouping construct. Since<br> > they also mean something in Texinfo and require proper quoting, it<br> > looks like some of them didn't survive into the formatted version of<br> > the manual, we need to fix that.<br> > <br> > Hans<br> > <br> > >>>>> Rich Morin <<a href="mailto:rdm@...">rdm@...</a>> writes:<br> > <br> > > I've been digging into Chapter 11 of the manual, in order to<br> > > write a second-level parser (ie, recognize logsent, etc.).<br> > <br> > > The BNF isn't exactly standard (or even correct in some places),<br> > > so I have been getting confused about some rather basic things.<br> > > Can someone confirm or deny (and then clarify) these statements?<br> > <br> > > asterisk "*"<br> > <br> > > An asterisk means "zero or more of this item".<br> > <br> > > braces "{...}"<br> > <br> > > Braces mean "zero or more of these items".<br> > <br> > > brackets "[...]"<br> > <br> > > Brackets mean "zero or one of these items".<br> > <br> > > parentheses "(...)"<br> > <br> > > Parentheses stand for themselves,<br> > > rather than acting as grouping operators.<br> > <br> > > plus sign "+"<br> > <br> > > A plus sign means "one or more of this item".<br> > <br> > > -r<br> > > --<br> > > <a href="http://www.cfcl.com/rdm" target="_blank">http://www.cfcl.com/rdm</a> Rich Morin<br> > > <a href="http://www.cfcl.com/rdm/resume" target="_blank">http://www.cfcl.com/rdm/resume</a> <a href="mailto:rdm@...">rdm@...</a><br> > > <a href="http://www.cfcl.com/rdm/weblog" target="_blank">http://www.cfcl.com/rdm/weblog</a> +1 650-873-7841<br> > <br> > > Technical editing and writing, programming, and web development<br> > > _______________________________________________<br> > > powerloom-forum mailing list<br> > > <a href="mailto:powerloom-forum@...">powerloom-forum@...</a><br> > > <a href="http://mailman.isi.edu/mailman/listinfo/powerloom-forum" target="_blank">http://mailman.isi.edu/mailman/listinfo/powerloom-forum</a><br> > _______________________________________________<br> > powerloom-forum mailing list<br> > <a href="mailto:powerloom-forum@...">powerloom-forum@...</a><br> > <a href="http://mailman.isi.edu/mailman/listinfo/powerloom-forum" target="_blank">http://mailman.isi.edu/mailman/listinfo/powerloom-forum</a><br> > </blockquote></div><br><br clear="all"><br>-- <br>Cameron Ross, M.Sc.<br>Director of Technology<br>Symboticware Incorporated<br><a href="http://www.symboticware.com">www.symboticware.com</a> powerloom-forum mailing list powerloom-forum@... http://mailman.isi.edu/mailman/listinfo/powerloom-forum |
|
|
Re: PowerLoom's BNF usage
by Rich Morin
::
Rate this Message:
At 21:59 -0700 7/7/08, Hans Chalupsky wrote:
> Cameron, > > thanks for the pointer. It definitely make sense to relate PL-KIF to > CLIF and align them as much as possible. PowerLoom was intended to > support multiple logic dialects (thus the "in-dialect" construct). If > we can't reasonably make PL-KIF a superset of CLIF, we should at least > be able to support them as alternative input language variants. > Given that Common Logic is an actual ISO standard now, we have some > motivation to attempt this fairly soon. At 22:15 -0700 7/7/08, Hans Chalupsky wrote: > ... As I said in a previous message, given that Common > Logic is a bonafide standard now, we'll work on making the > relationship between Common Logic and PL-KIF more precise. +1 Full disclosure: I sat in on the Common Logic email list, asked some questions, sent in copy edits, and helped write the Wikipedia entry. So, I'm pretty familiar with the project, but nowhere near being an expert on the standard's finer technical points. For that, you'll want to rope in some of the standard's authors (eg, Delaguch, Hays, Menzel, Sowa). A note to the mailing list (cl@...) would probably be a Good Idea, as someone might offer to help. One of the really interesting things about Common Logic is that it defines semantic capabilities, but not syntax. Sort of "duck typing, applied to language definition". If a syntax can be mechanically translated to/from another Common Logic representation, it qualifies as a Common Logic dialect. The Wikipedia entry, more formally, says: Common Logic (CL) is a framework for a family of logic languages, based on first-order logic, intended to facilitate the exchange and transmission of knowledge in computer-based systems. The CL definition permits and encourages the development of a variety of different syntactic forms, called "dialects." A dialect may use any desired syntax, but it must be possible to demonstrate precisely how the concrete syntax of a dialect conforms to the abstract CL semantics, which are based on a model theoretic interpretation. Each dialect may be then treated as a formal language. Once syntactic conformance is established, a dialect gets the CL semantics for free, as they are specified relative to the abstract syntax only, and hence are inherited by any conformant dialect. In addition, all CL dialects are equivalent (i.e., can be mechanically translated to each other), although some may be more expressive than others. In general, a less expressive subset of CL may be translated to a more expressive version of CL, but the reverse translation is only defined on a subset of the larger language. http://en.wikipedia.org/wiki/Common_logic As a result, there are several Common Logic dialects, including: Conceptual Graph Interchange Format (CGIF) Common Logic Controlled English (CLCE) http://www.jfsowa.com/clce/specs.htm Common Logic Interchange Format (CLIF) eXtended Common Logic Markup Language (XCL) As Hans notes, there are several approaches to PL supporting CL. All of them require "making the relationship between Common Logic and PL-KIF more precise". However, the devil is in the details. * "make PL-KIF a superset of CLIF" - Given CL's goals and approach, I would be amazed if PL critically needs anything that CL doesn't handle. However, the relationship needs to be made precise enough to enable mechanical translation. * Supporting CL as an alternative input language variant isn't really enough. In order to be a full player (not to mention having a way to test things out), PL will need translation both to and from a CL dialect (presumably, CLIF). With these things in place, however, PL stands to gain greatly from becoming a participant in the standard. PL's users would be able to import and export assorted KBs, then compare and contrast the capabilities of different systems in making queries, etc. If the translation were performed to (John Sowa's) Conceptual Graphs (CGIF) and Controlled English (CLCE) dialects, PL would gain new ways for users to view and edit statements, queries, etc. Both seasoned and naive users would benefit from having these dialects available. Finally, just as PL's Open Source licensing and flexible language implementation (ie, STELLA) protect its users, having the option of mechanical translation with other CL dialects should be quite reassuring to any KR&R user. (Like SQL, CL is not a magic wand for interchange, but it's a critically needed starting point.) In summary, I am very enthusiastic about this prospect and will be happy to help in any areas where my skills are appropriate. -r -- http://www.cfcl.com/rdm Rich Morin http://www.cfcl.com/rdm/resume rdm@... http://www.cfcl.com/rdm/weblog +1 650-873-7841 Technical editing and writing, programming, and web development _______________________________________________ powerloom-forum mailing list powerloom-forum@... http://mailman.isi.edu/mailman/listinfo/powerloom-forum |
|
|
|
|
|
Re: PowerLoom's BNF usage
by Robert Goldman
::
Rate this Message:
Rich Morin wrote:
> At 21:59 -0700 7/7/08, Hans Chalupsky wrote: >> Cameron, >> >> thanks for the pointer. It definitely make sense to relate PL-KIF to >> CLIF and align them as much as possible. PowerLoom was intended to >> support multiple logic dialects (thus the "in-dialect" construct). If >> we can't reasonably make PL-KIF a superset of CLIF, we should at least >> be able to support them as alternative input language variants. >> Given that Common Logic is an actual ISO standard now, we have some >> motivation to attempt this fairly soon. > > At 22:15 -0700 7/7/08, Hans Chalupsky wrote: >> ... As I said in a previous message, given that Common >> Logic is a bonafide standard now, we'll work on making the >> relationship between Common Logic and PL-KIF more precise. > > +1 > > > Full disclosure: I sat in on the Common Logic email list, asked some > questions, sent in copy edits, and helped write the Wikipedia entry. > So, I'm pretty familiar with the project, but nowhere near being an > expert on the standard's finer technical points. For that, you'll > want to rope in some of the standard's authors (eg, Delaguch, Hays, > Menzel, Sowa). A note to the mailing list (cl@...) > would probably be a Good Idea, as someone might offer to help. > > > One of the really interesting things about Common Logic is that it > defines semantic capabilities, but not syntax. Sort of "duck typing, > applied to language definition". If a syntax can be mechanically > translated to/from another Common Logic representation, it qualifies > as a Common Logic dialect. The Wikipedia entry, more formally, says: > > Common Logic (CL) is a framework for a family of logic languages, > based on first-order logic, intended to facilitate the exchange > and transmission of knowledge in computer-based systems. The CL > definition permits and encourages the development of a variety of > different syntactic forms, called "dialects." A dialect may use > any desired syntax, but it must be possible to demonstrate precisely > how the concrete syntax of a dialect conforms to the abstract CL > semantics, which are based on a model theoretic interpretation. > Each dialect may be then treated as a formal language. > > Once syntactic conformance is established, a dialect gets the CL > semantics for free, as they are specified relative to the abstract > syntax only, and hence are inherited by any conformant dialect. > In addition, all CL dialects are equivalent (i.e., can be > mechanically translated to each other), although some may be more > expressive than others. In general, a less expressive subset of > CL may be translated to a more expressive version of CL, but the > reverse translation is only defined on a subset of the larger > language. > > http://en.wikipedia.org/wiki/Common_logic > > > As a result, there are several Common Logic dialects, including: > > Conceptual Graph Interchange Format (CGIF) > > Common Logic Controlled English (CLCE) > http://www.jfsowa.com/clce/specs.htm > > Common Logic Interchange Format (CLIF) > > eXtended Common Logic Markup Language (XCL) > > > As Hans notes, there are several approaches to PL supporting CL. > All of them require "making the relationship between Common Logic > and PL-KIF more precise". However, the devil is in the details. > > * "make PL-KIF a superset of CLIF" - Given CL's goals and > approach, I would be amazed if PL critically needs anything > that CL doesn't handle. However, the relationship needs to > be made precise enough to enable mechanical translation. > > * Supporting CL as an alternative input language variant isn't > really enough. In order to be a full player (not to mention > having a way to test things out), PL will need translation > both to and from a CL dialect (presumably, CLIF). > > > With these things in place, however, PL stands to gain greatly > from becoming a participant in the standard. PL's users would be > able to import and export assorted KBs, then compare and contrast > the capabilities of different systems in making queries, etc. > > If the translation were performed to (John Sowa's) Conceptual > Graphs (CGIF) and Controlled English (CLCE) dialects, PL would > gain new ways for users to view and edit statements, queries, > etc. Both seasoned and naive users would benefit from having > these dialects available. Does the following correctly summarize what would happen if CLIF-compliance is achieved: 1. One would have to provide translations back and forth for one's dialect; 2. Because of 1, if one is compliant, one is automagically able to translate one's code into the other dialects? I think part of this question is "what does it mean to provide a translation?" does it mean one has to provide publicly usable code, or just an algorithm specification? Also, what if one has a language with, say, some second-order features (which I am just assuming are not included in Common Logic)? Does one define a subset of one's language which permits translation back and forth? Thanks, r _______________________________________________ powerloom-forum mailing list powerloom-forum@... http://mailman.isi.edu/mailman/listinfo/powerloom-forum |
|
|
Re: PowerLoom's BNF usage
by Rich Morin
::
Rate this Message:
At 12:16 -0500 7/9/08, Robert Goldman wrote:
> Does the following correctly summarize what would happen if > CLIF-compliance is achieved: > > 1. One would have to provide translations back and forth > for one's dialect; I'm not sure of the politics. For example, it might be enough to prove equivalence or have a demonstrable translator without making it generally available. Of course, I wouldn't recommend such an approach... > 2. Because of 1, if one is compliant, one is automagically able to > translate one's code into the other dialects? My understanding is that the dialects are all supposed to be equivalent and mechanically translatable to each other. So, I would expect the translations to be stackable, etc. I would also expect a translation from A->B->C->B->A to conserve meaning, if not exact syntax... > I think part of this question is "what does it mean to provide a > translation?" does it mean one has to provide publicly usable > code, or just an algorithm specification? Again, I don't know. Good question for the CL list (:-). > Also, what if one has a language with, say, some second-order > (which I am just assuming are not included in Common Logic)? > Does one define a subset of one's language which permits > translation back and forth? Either that or define an extension to Common Logic, knowing that some of it may not be usable by most recipients. For example, CL encodes statements but not queries or lambda expressions. There is nothing stopping two systems from extending CL, however, to encode this sort of information. -r -- http://www.cfcl.com/rdm Rich Morin http://www.cfcl.com/rdm/resume rdm@... http://www.cfcl.com/rdm/weblog +1 650-873-7841 Technical editing and writing, programming, and web development _______________________________________________ powerloom-forum mailing list powerloom-forum@... http://mailman.isi.edu/mailman/listinfo/powerloom-forum |
| Free Forum Powered by Nabble | Forum Help |