[SCL] minutes of telecon 8 April 03
pat hayes
phayes at ai.uwf.edu
Sat Apr 12 20:13:29 CDT 2003
Sorry, this reply didnt get sent for some reason -Pat
------------
>Pat - sotrry I couldn't make the call - a couple of quick responses
Thanks for input.
>
>
>>
>>2. Core language. We agreed that the core should allow restricted
>>quantification as useful syntactic sugar, but should not attempt to
>>include types or more advanced concepts.
>>
>>One issue we did NOT discuss, by the way, is whether the core
>>should allow function symbols and full terms (I vote yes), and
>>whether or not it should restrict relations and functions to have a
>>fixed arity (I vote no*); and if so or not, whether or not a user
>>can assert that a given relation or function has a certain arity.
>>Certainly in the full syntax, arity could presumably be a property
>>of a relation , and perhaps we should provide a logically defined
>>syntax for asserting those properties. Comments?
>>
>>(* To clarify: not including an arity constraint into the syntax,
>>that is: it would be too much trouble to take it out again for the
>>generalized syntax, and I don't think it is really necessary even
>>for conventional FO syntax. In the conventional language, two uses
>>of the same symbol with different arities are essentially treated
>>semantically and in proofs as different symbols, and does no harm.)
>
>
>While I agree with you, in most web languages (incl a lot of the XML
>derivatives) arguments are essentially "tagged" (like the 'modern'
>convention of having optional arguments in LISP)
And also like the emerging RuleML language, as Ben Grosof was telling
us about yesterday at the DAML meeting. In fact this is so common
that Im wondering if SCL ought to have it as a syntactic feature
explicitly. I will post a message about this on another subject line.
>-- so a binary v. n-ary relation w/same name would be confusing to
>most web language types.
Hmm, not sure I follow that. Seems to me that the convention you
refer to is more like allowing this option, so why would it be
confusing?
> I think you make the right decision, but let's be careful to explain it.
>
>For those who didn't follow - in XML or RDF/XML or similar, I would
>say something like (I'm cheating on details)
>
><person :John>
> <name>John</name>
> <size>large</size>
></person>
>
><person :Mary>
> <name>Mary</name>
> <size>Medium</size>
> <inLovewith :John />
></person>
>
>and this would just be the same n-ary person relation in both cases,
>with different arguments. Few if any web languages prefer
> Person(name, size, inLoveWith, bestFriendOf, shoeSize, ...)
>although XML DTDs allow it and make use in some cases (like Peter's
>abstract syntax of OWL, which several XML folks have criticized for
>not using tagged arguments).
Right, exactly. I like this so much Im going to suggest putting it
into the basic SCL core in some form.
>
>
>>
>>-------
>>
>>3. Built-in logical names and externally defined namespaces
>>
>>The core should include equality.
>>The full syntax should include an 'is-a-Relation' predicate.
>>(and Arity predicates?)
>>Special name domains should provide a built-in logical predicate
>>true of entities in the domain, so that an atom formed by applying
>>that predicate symbol to any special name with the appropriate
>>syntax will be true.
>
>like the idea, will need to be careful ion the web.
Indeed, there are many subtleties there when it comes to document
types, etc. ., We have already met this in RDF/XML: is a plain
character string in RDF the same kind of thing as a thing of type
xsd:string? Some people think obviously yes, others think obviously
no, most people are confused. SCL is going to have to tread very
carefully to avoid accidentlaly taking a stance on questions like
this. I would like us to not have to have a built-in theory of
datatypes, but to try to follow RDF in allowing people to declare
their own and then use them..
>>
>>We need a way to specify the syntax of names in a special-name
>>domain. We did not reach agreement on how to do that. Here are
>>some options:
>>
>>1. Do not provide one, but instead restrict ourselves to a small
>>set of built-in special name categories, eg numerals and quoted
>>character strings, or maybe a set based on the XML schema built-in
>>datatype domains. This would be quick and dirty but might be worth
>>doing even as an exercise for ourselves :-)
>>
>>2. Simply require that whoever defines 'an SCL language' provide a
>>BNF for their particular syntax of special names, and write their
>>own parsers.
>
>If SCL intended for the web, this is a sure fire loss. Perhaps
>instead of BNF we could use XML (DTD or schema) and then we'd get
>something similar -- wouldn't be quite as general, but would make it
>easier to build.
Well, how about having it so that the XML concrete syntax allows
people to do it in an XMLish way? Would that be OK?
Pat
>
>>
>>In my view, neither of these is really adequate. The second option
>>basically makes it impossible to write a general SCL parser, since
>>particular SCL languages may have arbitrary syntactic complexities
>>which might need to be parsed, and the reversion to BNF allows too
>>low-level and detailed a possible relationship between special name
>>syntax and the rest of the language. I would be happier if we
>>could provide a more coherent mechanism which defines the syntactic
>>interface between special name domains and the rest of the language
>>more clearly. However I confess I have no clear idea of how to do
>>that in an appropriate way.
>>
>
>agreed
>
>
>--
>Professor James Hendler hendler at cs.umd.edu
>Director, Semantic Web and Agent Technologies 301-405-2696
>Maryland Information and Network Dynamics Lab. 301-405-6707 (Fax)
>Univ of Maryland, College Park, MD 20742 240-731-3822 (Cell)
>http://www.cs.umd.edu/users/hendler
>_______________________________________________
>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 ai.uwf.edu http://www.coginst.uwf.edu/~phayes
s.pam at ai.uwf.edu for spam
More information about the Scl
mailing list