[SCL] Re: The second draft for XML syntax for CL

Murray Altheim m.altheim at open.ac.uk
Thu May 29 15:01:00 CDT 2003


geoff at cs.miami.edu wrote:
> Murray Altheim wrote:
 >>[...]
>>Put it this way: XML was designed by some of the industry's experts,
>>people with decades of experience in SGML. What does one of the
>>requirements on XML say? "Terseness in XML markup is of minimal
>>importance." I've now been doing markup work for over a decade,
>>and honestly, the last thing to consider is verbosity. If people believe
>>an XML concrete syntax for SCL is going to be commonly hand-authored
>>rather than the product of a transformation, I think they need to
>>have their heads examined. HTML is one thing, but logic? Think of
>>the potential for syntax or human interpretation errors. ugh.
>
> OK. If we agree that this stuff is never going to be seen by people, then
> verbosity is no issue. Then, going back to a previous item in one of the
> emails, I suggest that using long words for tags (<quantifier> rather
> than <quant> or <q>). It'll make parser code easier to write and understand,
> and there's no loss to the user (who'll never see it).

Yes, the only reason I altered it was that there at the time was
some consideration for file size, so <quant> is long enough to be
unambiguous but shorter than the full name. As I mentioned, it's
better to argue about requirements that specific syntax details,
if the requirements haven't been agreed upon -- and I don't see
that they yet have (e.g., Pat and John recently discussing some
fairly core features like arithmetic support).

But when I get around to rewriting my XCL proposal, I'll probably
change <quant> to <quantifier>. These types of things are easy to
alter in a specification.

>>>>>  TPTP will support is 
>>>>>        ? [1:X,2:Y] : p(X,Y)
>>>>>  meaning there are exactly one X and two Ys such that p(X,Y).
>>>>>  
>>>>>  Comment by Tanel: no clear need to introduce this into minimal core
>>>>>  (we want to keep the core minimal!). Could be introduced in extensions.
>>>>>  Easy to give an extra parameter to quantifier tag, like this:
>>>>>  <quantifier name="exists" variable="x" count="2">
>>>>>  indicating that we say that there are exactly TWO instances.
>>>>>  However, bringing this into core creates unnecessary complications.
>>>>>  Let us see whether it will be in the SCL core - if yes, we can put
>>>>>  it into the XML concrete syntax.
>>>>
>>>>This could be introduced as a PSI rather than as new syntax. As in my
>>>>last comment.
>>>
>>>Help, what's PSI? Anyway, I support Tanel with a minimalist approach in
>>>the core. So, as I suggested in my response to the first draft, I would
>>>say the typing is not core - you open any text on mathematical logic and
>>>read the definition of FOL ... not a word about types. I suggest you can
>>>take types out of the core.
>>
>>What I'm referring to as "types" are inherently in the core, just a
>>very specific set, essentially anything that can be typed. If you
>>look at the current SCL draft, in the content of <formula> you see
>>types. There are two quantifier types, <forall> and <exists>; there
>>are five connective types, <and>, <or>, <implies>, <iff>, and <not>.
> 
> I think we are talking about different things. I am referring to types
> for the logic variables, as in Tanel's example:
>     exists x:r forall y . p(x,f(1,a)) & ...
> Here the logic variable x is constrained to be of type "r" (real?). Maybe
> I'm really missing something, but aren't those different from the types you
> (Murray) are referring to? If they are different, it's those logic variable
> types I suggest are non-core. Please put me right if I'm all wrong.

Yes, we have been talking about different things, but my point has
been all along that *any* kind of type is a candidate for the same
kind of treatment. In your example, if "r" was a type represented
by a PSI, say by:

    http://www.cyc.com/cycdoc/vocab/transportation-vocab.html#Truck

then you'd want "r" to be a container that could either contain a
simple string token (like, literally "r"), or a full-blown URI/PSI.

I'm hoping the same XCL syntax that is used in representing core SCL
sentences can be used (without additional syntax, except what I've
proposed as "Level 2") for XML versions of CG, OpenCyc, etc.  Now,
if some additional syntax in the end is required, it would hopefully
be only minor extensions, not an entirely new syntax. I consider XCL
as a basis for building XML-based languages, just as Pat, John, and
others consider CL/SCL as the abstract basis. My job as a markup
language designer is to try to keep them tightly in sync. I *think*
Pat understands what I'm trying to do now is in harmony with his
goals, i.e., if XCL doesn't match SCL's semantics, it's a mistake
on my part, not a deliberate decision to be different.

Murray

...........................................................................
Murray Altheim                         http://kmi.open.ac.uk/people/murray/
Knowledge Media Institute
The Open University, Milton Keynes, Bucks, MK7 6AA, UK                    .

   "We can now hypothesise with some confidence that those apparently
    happy, calm Buddhist souls one regularly comes across in places
    such as Dharamsala, India, really are happy," said Professor Owen
    Flanagan, of Duke University in North Carolina. -- BBC News
    http://news.bbc.co.uk/1/hi/health/3047291.stm




More information about the Scl mailing list