[SCL] Comments on Pat's SCL document
pat hayes
phayes at ihmc.us
Mon Dec 8 12:48:40 CST 2003
>Pat,
>
>I'm working on a CGIF definition with two parts:
>
> 1. EBNF definition of the CGIF syntax.
>
> 2. CGIF <-> SCL correspondences to define
> the semantics.
>
>A version of Part I is attached (but I plan to make
>further revisions and extensions) later this week,
>so don't consider this one definitive.
Great, thanks. Im working on the basic document.
> The main
>addition will be a representation of seqvars.
>I am adopting the simplest and quickest way of
>adding seqvars to CGIF: copy the KIF syntax.
Seriously, you really can use argument lists, if you prefer. See (2) in
http://philebus.tamu.edu/pipermail/scl/2003-December/000553.html
>Some comments on your SCL document:
>
> 1. The definition of "ontology" as any set of SCL
> sentences bothers me. More precisely, I don't
> care if an ontology is defined as a set of
> sentences, but I very much object to saying
> that any set of sentences is an ontology --
> because one might want to say that a particular
> set of sentences is a theory, hypothesis,
> specification, declaration, or a set of
> assertions, assumptions, constraints, rules,
> judgments, ....
Well, Im just using 'ontology' as a generic word, which seems to be
emerging practice. Seems to me that an ontology can also be a set of
assertions, theory, etc..
> 2. I suggest that we adopt a more neutral term for a
> set of sentences. If nobody can think of a better
> one-word synonym, I recommend "set of sentences"
> with the acronym SoS (or "collection of sentences"
> -- CoS).
Yech. If that's the best we can do, I'm sticking to 'ontology'.
>
> 3. As you have observed, there are strong partisans
> for both typeless and typed languages. You prefer
> typeless, and I prefer typed. But we have compromised
> on a typeless core with restricted quantifiers as an
> option
I'm using 'kernel' for the really tiny inner core and 'Core' for a
KIffish-level skin wrapped onto it. The 'core' has restricted
quantification and argument-role syntax as options, and allows
comment wrappers. I havn't tackled a strongly typed syntax yet.
>and with strongly typed languages supported as
> subsets. To emphasize that point, I suggest that we
> show both options in our examples -- if we don't,
> there are going to be people who will complain.
>
> 4. For every example in the document, I suggest that we
> show (1) an English statement, (2) a statement using
> restricted quantifiers, and (3) a typeless statement.
> The first example would therefore be written:
>
> English: "Every boy kissed some girl."
>
> Typed: (Ax:Boy)(Ey:Girl)kissed(x,y)
>
> Typeless: (Ax)(Boy(x) -> (Ey)(Girl(y) & Kissed(x,y)))
Both will be legal in the SCL core. Also the 'role-set' option, like
(Ax:Boy)(Ey:Girl)kissed{ kisser:x, kissee:y}
>
> 5. For the CG example, the version you gave is correct,
> but it is possible to have shorter statements, both for
> the typed and the typeless versions:
>
> Typed: (Kissed [Boy @every] [Girl])
>
> Typeless: [If: (Boy [*x]) [Then: (Girl [*y]) (Kissed ?x ?y)]]
>
> The if-then construction in CGs is actually defined as
> a nest of two negations ~[ ... ~[ ... ]], therefore, you
> can use existential quantifiers in both the antecedent
> and consequent -- exactly as in English, "If there is
> a boy x, then there is a girl y and x kissed y."
OK, I will leave that for you to describe when giving the CG skin
translation. Ive given you (forall, not, and) in the kernel, as you
requested, so you have to be able to map everything to that one way
or another.
>
> 6. I doubt that we should include URIs in the SCL core.
Yes, Ive come to the same conclusion.
> Instead, I suggest that we have a recommended ontology
> with a dyadic relation URI, which would state that the
> SCL term in the first argument denotes the same entity
> specified by the URI label in the second argument.
I do not like that approach. We should allow URIs to be used as SCL
names directly: this is now universal on the Sweb. We not not have to
mandate the use of URIrefs, but there is no need to segregate URIrefs
in a special way.
>
> 7. As I said many times before, I believe we should adopt
> the Z "toolkit" as a recommended ontology for sets,
> sequences, bags, and integers.
Why do we need an ontology for these? Finite sets and sequences are
part of the SCL syntax, so do not need to be in an ontology (and are
trivial to provide there if required: sequences are whatever is
denoted by a sequence expression, sets by set expressions). If there
is anything that is completely universal throughout human discourse,
it is the numerals: why do we need to provide an ontology for them?
We are not in the foundations-of-mathematics business here.
>Since that toolkit has
> already been specified as part of an ISO standard, we
> can just refer to that standard by its official name:
>
> ISO/IEC IS 13568 Information technology - Z formal
> specification notation - Syntax, type system and semantics
>
> I have a PDF copy of the Final Draft of that standard.
> Send me a note, and I'll send a copy, if you wish.
Please do. However, be warned: anything that we write will be
open-source and freely available to anyone without charge. So if ISO
retains copyright on anything, then we are not using it.
Pat
>
>I have lots of minor comments, but these are enough for
>the time being.
>
>On Monday and Tuesday, I'm going to a two-day DARPA review
>of the FrameNet project (in Berkeley). I'll send more
>info and comments on Wednesday.
>
>John
>
>
>Conceptual Graph Interchange Format (CGIF)
>
>Arc.
> An arc is a concept or a bound label.
>
>Arc ::= Concept | BoundLabel
>
>Bound Label.
> A bound label is a question mark "?" followed by an identifier.
>
>BoundLabel ::= "?" Identifier
>
>Conceptual Graph.
> A conceptual graph is a list of zero or more concepts, conceptual
>relations, or comments.
>
>CG ::= (Concept | Relation | Comment)*
> A conceptual graph with no concepts or relations is said to be
>empty. An empty CG is always true.
>
>Concept.
> A concept begins with a left bracket "[" and continues with an
>optional type label, an optional quantifier or referent, optional
>coreference links, and an optional comment. It ends with a right
>bracket "]".
>
>Concept ::= "[" TypeLabel? (Quantifier | Referent)? CorefLinks? Comment? "]"
> The simplest concept, in which all the optional features are
>omitted, is "[]". It is equivalent to the concept "[Entity @some]",
>which says that there exists some entity.
>
>Coreference Links.
> Coreference links are either a single defining coreference label or
>a sequence of zero or more bound labels.
>
>CorefLinks ::= DefLabel | BoundLabel*
>
>Defining Label.
> A defining label is an asterisk "*" followed by an identifier.
>
>DefLabel ::= "*" Identifier
>
>Literal.
> A literal is a number or a quoted string.
>
>Literal ::= Number | QuotedString
>
>Negation.
> A negation begins with a tilde "~" and a left bracket "[" followed
>by a conceptual graph and a right bracket "]".
>
>Negation ::= "~[" CG "]"
> Since a conceptual graph may be empty, the simplest negation is
>~[], which is always false.
>
>Quantifier.
> A quantifier is either "@every" or "@some".
>
>Quantifier ::= "@every" | "@some"
> If the quantifier is omitted, the default is @some.
>
>Referent.
> A referent consists of a colon ":" followed by an optional literal,
>name, or conceptual graph.
>
>Referent ::= ":" (Literal | Name | CG)?
>
>Relation.
> A conceptual relation begins with a left parenthesis "(" followed
>by a type label, zero or more arcs, and an optional comment. It ends
>with a right parenthesis ")".
>
>Relation ::= "(" TypeLabel Arc* Comment? ")"
>
>Type Label.
> A type label is an identifier.
>
>TypeLabel ::= Identifier
> The following identifiers shall not be used as type labels: "if",
>"then", "either", "or", "sc", "else", "lambda".
>
>
>_______________________________________________
>SCL mailing list
>SCL at philebus.tamu.edu
>http://philebus.tamu.edu/mailman/listinfo/scl
--
---------------------------------------------------------------------
IHMC (850)434 8903 or (650)494 3973 home
40 South Alcaniz St. (850)202 4416 office
Pensacola (850)202 4440 fax
FL 32501 (850)291 0667 cell
phayes at ihmc.us http://www.ihmc.us/users/phayes
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://philebus.tamu.edu/pipermail/scl/attachments/20031208/e0059b8c/attachment.htm
More information about the SCL
mailing list