[SCL] new draft
Frank Farance
frank at farance.com
Wed Dec 31 19:24:54 CST 2003
At 10:34 2003-12-31 -0800, pat hayes wrote:
> >SCL people-
> >
> >I'm new to this list. I thought I was subscribed to the KIF list
> >and I found out last week at the INCITS/L8 meeting that the list had
> >(again) changed and I was no longer part of the discussion of the CL
> >activities.
>
> The SCL list is open to anyone, but please be clear that its purpose
> is limited, with a sharper focus than the CL effort, and that this
> list is intended for technical discussions which are now reaching a
> fairly late stage. You can see the origins of SCL in the early part
> of the SCL email archives. Issues of ISO compliance in particular are
> not appropriate for this forum.
Harry and Mike G. told us that the discussion of CL had moved to the SCL list. I was part of the CL list, but I wasn't aware that the discussion had moved. Since the purpose of the discussion, as described by Harry and others, is to develop a "CL specification" that is intended for submission to INCITS/L8 and then a further submission to ISO/IEC JTC1 SC32 WG2, my involvement is to try to understand the nature of this specification before it hits INCITS/L8. Of course, it is always possible that we (L8 and SCL) don't have any communication at all, but then it doesn't facilitate the harmonization of stakeholders' needs, such as those of L8 and this particular group of people (SCL).
If this work is to become an ISO/IEC standard, then there is much preparation to be done -- which means a fair amount of explanation and rationale so that the US members (and later on, other National Bodies - NBs) can make an informed decision about the document. If they don't understand the document, they won't approve it. And the document is likely to have some changes as it makes progress from "consensus among a small group of people" (SCL) to "consensus among ~20 nations" (JTC1/SC32/WG2, JTC1/SC32, and JTC1). In addition to NBs, there are other organizations that will have input on this, such as JTC1/SC22 (Z was developed in SC22/WG19).
> >One point I hope that SCL people can address is: how does this SCL
> >(or CL?) differ from Z?
>
> Please raise this issue on the CL list, not the SCL list.
OK, I'll ask the queston there.
> >Isn't SCL just a subset/profile of Z?
>
> No.
>
> > Based on the draft document, it appears to me that SCL can be
> >specified by pointing to a portion of the Z standard and adding a
> >few "customizations". Perhaps I'm wrong, so could someone explain
> >the relationship? Maybe there is a prior E-mail where this has
> >already been discussed, so could someone point me to that E-mail
> >discussion?
> >
> >Regarding the new draft, I'm having problems with the form of the
> >specification of SCL. For the formal specification of standards for
> >languages like SCL, the specification should
>
> From where comes this criterion for what a specification 'should' do?
> Absent any documentary guidance from a higher authority, it seems to
> me that the specification should be written by the people writing it.
The "should" comes from experience in what will get approved in standards. So there isn't a "higher authority" making this requirement via a document, per se, but the authorities that approve this (INCITS/L8, INCITS/EB, ISO/IEC JTC1 SC32 WG2, ISO/IEC JTC1 SC32, ISO/IEC JTC1) have a strong desire for harmonization, non-duplication of efforts, and the use of common formal descriptive techniques. So if you want to have your document progressed to higher levels, you need to know what some of their concerns are.
Having 20+ years experience in ICT standards, I'm sharing my personal opinions on what works and what doesn. I have a pretty good track record on anticipating issues that impede consensus-building.
> > detail the syntax of the language (the draft claims the metasyntax
> >is EBNF, but it is not
>
> It is now.
I'm looking at the draft:
http://www.ihmc.us/users/phayes/SCL_december_2.HTML
which is dated 2003-12-19. Here's an excerpt of the grammar:
<ontologyDefinition> ::= scl:ontology <ontologyname> = <ontology>
<ontology> ::= (( <topsentence>+ )) | ((<topsentence>* )::( <topsentence>+ ))
<topsentence>::= scl:import(<ontologyname>) | <sentence>
<sentence> ::= <quantifiedsentence> | <booleansentence> | <atom> | true | ( <sentence> )
<quantifiedsentence> ::= forall? ( ( <variable> | <variable> :: <name> )* <sentence> | exists (( <variable> | <variable> :: <name> )*) <sentence>
<booleansentence> ::= <conjunction> | <disjunction> | <implication> | <bicond> | <negation>
<conjunction ::= ( (<sentence> &)* <sentence> ) | ( <sentence>* )
<disjunction ::= (<sentence> or )+ <sentence>
<implication ::= <sentence> implies <sentence>
<bicond> ::= <sentence> iff <sentence>
<negation> ::= not <sentence>
<atom> ::= <term>( <term>* <seqvar>? ) | <term> = <term> | <term> { <rolepair>* }
<rolepair> ::= <name>=<term>
<term> ::= <term>( <term>* <seqvar>? ) | <name> | <specialname>
<variable> ::= <name>
That is not in EBNF (ISO/IEC 14977:1996). Here's the above syntax transformed into EBNF:
ontologydefinition = (* this is the start symbol *)
"scl:ontology", ontologyname, "=", ontology ;
ontology =
( "((", {topsentence}-, "))" ) |
( "((", {topsentence}*, ")", "::", "(", {topsentence}-, "))" ;
topsentence =
"scl:import", "(", ontologyname, ")" |
sentence ;
sentence =
quantifiedsentence |
booleansentence |
atom |
true |
"(", sentence, ")" ;
quantifiedsentence =
["forall"], "(", { variable | variable, "::", name }, ")", sentence |
"exists", "(", { variable | variable, "::", name }, ")", sentence ;
booleansentence =
conjunction |
disjunction |
implication |
bicond |
negation ;
conjunction =
"(", { sentence, "&" }-, sentence, ")" ;
disjuntion =
{ sentence, "or" }-, sentence ;
implication =
{ sentence, "implies" }, sentence ;
bicond =
{ sentence, "iff" }, sentence ;
negation =
"not", sentence ;
atom =
term, "(", {term}, [seqvar], ")" |
term, "=", term |
term, "{", {rolepair}, "}" ;
rolepair =
name, "=", term ;
term =
term, "(", {term}, [seqvar], ")" |
name |
specialname ;
variable = name ;
NOTE: A rough translation from your work to EBNF is ...
1. Literals (terminals) are surrounded in quotes.
2. Syntactic items are combined with a comma, e.g.,
variable, "=", expression ;
might be a production (syntax rule) for an assignment statement.
3. Sytnax rules are terminated with a semicolon.
4. Non-terminals are written without angle brackets.
5. Zero or more items is represented by braces, i.e.,
{"A"},"B"
represents "B", "AB", "AAB", etc..
6. Optional items (zero or one) are represented by square brackets, i.e.,
["A"],"B"
represents "B" or "AB".
7. One or more items is represented by an idiomatic use of null syntactic exceptions. The idiom
{foo}-
i.e., surrounded by braces followed by a hyphen, represents *one* or more instances of 'foo'. FYI, in ENBF syntactic exception allows one to define letters as
letter = "A" | "B" | "C" | "D" | "E" | "F" |
"G" | "H" | "I" | "J" | "K" | "L" | "M"
"N" | "O" | "P" | "Q" | "R" | "S" | "T"
"U" | "V" | "W" | "X" | "Y" | "Z" ;
vowel = "A" | "E" | "I" | "O" | "U" ;
consonsant = letter - vowel ;
8. FYI, comments can be added by '(* ... *)', e.g.,
name, "=', value ; (* syntax for a name-value pair *)
If you want more information on ISO/IEC 14977, go to Google and look up:
iso ebnf 14977
You'll find a bunch of references. FYI, in addition to Z, in my involvement in SC22 and SC32, I have also made a formal request for ISO/IEC to make this standard free-of-charge and publicly available. JTC1 has approved the request about a month ago in Singapore and it is now awaiting approval at the top levels of ISO and IEC.
I didn't convert all of the grammar to ENBF yet. I did notice some potential bugs and some areas for improvement. Regarding potential bugs, I notice:
- There are several ambiguous parses. For example, if S1 and S2 are sentences, then the sequence "not S1 implies S2" produces an ambigous parse: is it "(not S1) implies S2" or "not (S1 implies S2)". This is not only ambiguity -- there are several others.
- There are several duplicate syntax fragments that could be reduced -- this would simplify the normative wording that would need to be written to support the syntax rules.
- The non-terminals "name" and "specialname" are not defined in the syntax.
- There is no discussion of whitespace or the practicalities of character processing. For example, while the conceptual model of processing charcters might be ISO/IEC 10646 (not Unicode), there are the practical issues of: (1) proper inclusion, exclusion, and preservation whitespace, (2) the relationship of whitespace to the syntax, (3) the need to "escape" characters that have lexical or syntactic significance, (4) the handling of newline characters. For typical programming language standards, these are *specified* (but not necessarily implemented) in two or more passes of translation: one pass on lexical analysis (e.g., getting the whitespace, newlines, and escaped characters fixed up right) and one pass on syntactic analysis -- there may be other passes (more on this in a separate E-mail regarding the interpretaton of headers).
Speaking of programming languages and their standards, I don't understand why you are resistant to taking some of the tips and reusing them? I understand that you have a concern about the execution vs. declarative aspects of the statements -- OK, a reasonable discussion to have. However, it appears to me that you are dismissive of all of the work in programming language standards -- stuff that can really save us time. For example, programming language standards take a different approach towards developing the the EBNF for their grammar: the result is fewer ambiguities and more consistent machine parsing of the "language". Also, programming language standards have much experience in approaching these kind of specification problems, such as certain problem-solving technique that greatly simplify the understanding and improve the consistency of interpretation (e.g., approaching language specification via a series of translation phases).
Lots of the stuff applies, even if you aren't generating executable code. Hopefully, you may gain further appreciation of much of the serious work that has been done in this area in the past 2-3 decades.
If you would like me to spend time improving the grammar and preparing a strawman for the lexical analysis, I will.
> >) and each of the "productions" would have a semantic description,
> >i.e., the meaning of instances of the production (combined: syntax
> >and semantics).
>
> The semantic is gathered into one table, which is the preferred way
> to described a model theory. It is particularly important in this
> case since the syntax does not suffice in isolation to provide the
> semantics precisely.
>
> >I don't see a one-to-one mapping of "productions" to semantic
> >descriptions, so my sense is that the semantic description is
> >incomplete in the current draft. I'm sure that a precise
> >description is intended, but I am not seeing it within the current
> >draft.
>
> The SCL document is not a draft ISO standard document. But I welcome
> suggestions for better presentation.
See my suggestions above.
> >Also, could the terms be defined in the standard? There are a good
> >number of terms that appear to have a specific meaning (e.g.,
> >vocabulary, extension, etc.), but they don't mean what they say in
> >the OED (the OED's definitions are not precise enough for this
> >subject area) and the technical meanings can easily be misunderstood.
>
> We plan to write and include a glossary but will leave that until the
> document is more complete and more stable.
>
> Pat
I read in one of your other E-mails today:
... The only issue is how to define the scope of a name when naming a...er...thingie, for subsequent importing. So I suggest we adopt 'text' for a sequence or set of sentences, and 'module' for a piece of text with a name and (optionally) a header, and I will learn to avoid saying 'ontology' in an SCL context.
Your statement above seems reasonable. So why not add the definitions:
text: sequence or set of sentences
module: text associated with a name and, optionally, a header
While these definitions might be refined over time, it is extremely helpful to have key terms defined *now* -- it helps avoid our tendancy to see terms and read our own interpretations, which might be imprecise, incorrect, or inconsistent. A good one-liner definition goes a long way. :-)
Happy New Year
-FF
______________________________________________________________________
Frank Farance, Farance Inc. T: +1 212 486 4700 F: +1 212 759 1605
mailto:frank at farance.com http://farance.com
Standards/Products/Services for Information/Communication Technologies
More information about the SCL
mailing list