[SCL] Re: Report on Common Logic
pat hayes
phayes at ihmc.us
Mon Nov 3 14:00:16 CST 2003
>pat hayes wrote:
>>John Sowa wrote:
>>>Murray Altheim wrote:
>>
>>>>After that's done, an XML syntax still isn't completely
>>>>straightforward. Like any language, you need to decide exactly
>>>>what you're trying to do with it. Just *one* of the questions
>>>>I brought up early on was "web-enabled" or not? Use of URIs or
>>>>not? Any extensibility, so it can be the basis of other languages?
>>>
>>>Those answers were decided long ago: web enabled, yes;
>>>URLs, yes; extensibility, yes; and basis for most common
>>>declarative languages, yes.
>>
>>Wait: when was that decided? To create a web-enabled syntax is
>>indeed one goal, but not the immediate one (ie aiming at Dec 17);
>>the aim there should be a basic SCL-XML exporting syntax allowing
>>SCL to be ported through an XML pipe, with the minimum of bells and
>>whistles. URLs are permitted but not obligatory (as in SCL
>>generally) and I do not feel that the XML syntax should be
>>particularly extendable or web-enabled (whatever that means, it
>>requires a lot more discussion): SCL is itself extendable, but
>>there is no need to provide for extensions in (this) XML syntax:
>>any extensions would be changes to the syntax and hence to the XML.
>>So my answers (in the short term) would be:
>>web enabled, no; URLs are used but not mandatory; extensibility,
>>no. I realize this makes it into a very boring exercise for an
>>XML/web expert, but that is what we need done by the 17th (actually
>>by about the 12th).
>
>I'm not concerned any more than you with this being "boring". I am
>concerned with its usability and whether or not it meets a set of
>requirements. Those two things are of course inextricably tied. I
>would still prefer a set of specific requirements for this work; I'm
>guessing this isn't going to happen, so perhaps I can just field
>questions and see if nobody screams when I answer them as best I can
>based on what I see on the list, rather than in a requirements document.
OK, since time is short let me suggest answers to your questions.
Anyone else disagree, chime in ASAP.
> Web Enabled:
> 1. Do we want XCL documents to be able to refer to other XCL
> documents over the web? This would be how modules could be used
> to construct larger statements/formulae/ontologies/etc.
If this can be managed easily, yes. I think there is only a need to
do this at the 'top level', ie for one ontology to consist of several
XCL documents. One way to do this would be to include a kind of
'importing' mechanism, meaning: include all the SCL axioms from that
document in here.
I think it would be good if XCL could be mixed with other content in
an XML document without that affecting the SCL content.
> 2. are XCL documents meant to be exchanged over the Web?
By being given a URI and retrieved as XML, sure.
> 3. are there meant to be internal link targets within an XCL document?
Not it the first instance, I think.
> 4. compatible with XLink or use its own linking structure?
Your decision. It would be good if it were *possible* to use DTDs with XCL.
>
> URIs or not:
> 1. If URIs are permitted in SCL, do they actually *mean* URIs, or
> are they just string identifiers?
Delicate question. As far as the SCL syntax is concerned, it would be
kosher to distinguish a URTi from an isomorphic character string as
slong as there was some way to distinguish them syntactically, but it
would also be kosher to treat them as indistinguishable.
>Is there any sense of them
> being dereferenced?
Apart from the links in the 'imports' meachanism, no.
>Is there any requirement as to what is at
> the other end of the reference?
I would be happy to say that if it is SCL then we use it, and if it
isn't then we ignore it.
> 1. are URIs in XCL merely meant to be contained as strings, or
> actually treated (in syntax) as URIs?
The abstract syntax is agnostic on this. I think we should take the
simplest possible path consistent with being able to reconstitute the
SCL itself from the XCL markup, which I think would be the answer
uris=strings, at this stage. We can return to designing a more
web-savvy XML version later.
>Is there to be any
> differentiation between their various uses (as strings or as
> links)?
No. Their use as links is irrelevant to SCL.
>In the case of links, do you want a mechanism to include
> link semantics (e.g., role attributes), so that one *kind* of link
> is differentiated from another? Is this list of link semantics
> fixed or extensible? E.g., In HTML, there are many dozens of kinds
> of links and link semantics, some fixed, some stated by the user.
These are exactly the issues I want to avoid at present and return to
later. They are not part of the central SCL proposal, more to do with
designing a Web logic based on SCL.
> 2. Are there any restrictions on the use of URIs within XCL?
No, because the issue does not arise, ie if some part of SCL syntax
is a link then this is irrelevant to its role in SCL syntax.
>A query
> language beyond fragment IDs ("#foo")? Use of XPath suggested or
> permitted? If only intra-document links are used, do you want to
> use XML IDs (which are guaranteed unique), but have naming
> constraints (XML Names only, no weird characters or spaces)? If
> not, how do you want to design the link structure? (There are a
> *lot* more questions then.)
> 3. If URIs are not used, how are references made between various
> parts of the grammar?
I don't understand the question. What kind of references?
>Are there one or two different mechanisms?
> If two, how do they interact? (I'd recommend one: use URIs, but
> if you don't want external linking to other documents, simply
> prohibit it, either in the spec prose or in the DTD/schema, and
> use the XML IDs.)
>
> Extensible:
> 1. Are documents conforming to the XCL spec required to include
> only XCL content, or can it be mixed with other markup?
Mxing is better as long as we can cleanly separate the SCL from the
rest. We have a proposal for mixing arbitrary other markup into SCL
(as 'wrappers') but if this can be done more neatly in XML then by
all means make a proposal. I would like to be able to mix XCL into
XHTML 'invisibly' to both, but I doubt if we can get that done in the
next week or so.
>I.e.,
> the XML Topic Maps spec forbids any mixing within an XTM document.
> 2. Do we want the element and attribute names to be fixed?
In the first instance lets do that. We can always make a more
sophisticated proposal later.
> A reason
> why we might is that XCL may be used for different purposes. For
> authoring and reading the markup (which will often or even
> usually be done by humans, sad to say), we'll want the element names
> to be human-readable (e.g., "<formula>", "equiv"), whereas for
> really large documents, people may want "<fm>" "eq", etc. to save
> space. This kind of thing reduces interoperability, but XSLT can
> easily be used for transforms. It'll also depend on the markup-
> to-content ratio.
> 3. Is there one XML Namespace prefix permitted, or anything goes?
> I.e., is the default (either "" or "xcl:") fixed?
Well, SCL itself is an abstract syntax with many (possibly
open-ended) concrete instances, so ideally we would want any
namespace to be used, but the namespace defines the SCL syntactic
categories for a particular SCL language. Something like cfopc:scland
versus kif:scland versus cg:scland (?) Or is it possible to declare
that cfopc and kif and so on are SCL-kosher and then just use the
namespace with that assumption?
> 4. Are there any DTD- or schema-based mechanisms provided for
> extending XCL, or is this left to others? (If not, the ways that
> people might alter the DTD may create incompatibilities, whereas
> if everyone uses a provided mechanism, this will make DTDs/schemas
> interoperable and easier to use).
I would prefer a single mechanism to be at least provided, but at
this point my XML skills run out.
> 5. If it's know that XCL will be extended beforehand, do we want to
> provide the hooks so that those DTDs/schemas can be built upon
> the core XCL DTD/schema, or would those projects have to start
> from scratch?
>
>Some of these things are implemented in the DTD/schema, others are
>constrained in the prose of the spec.
>
>There are perhaps other issues, I'm just pointing out that this is not
>straightforward.
I understand it is not, which is why I don't think there will be time
to get it adequately done by the 17th.
Pat
>
>Murray
>
>......................................................................
>Murray Altheim http://kmi.open.ac.uk/people/murray/
>Knowledge Media Institute
>The Open University, Milton Keynes, Bucks, MK7 6AA, UK .
>
> White House defiant despite deadliest strike on forces since end of war
> http://www.guardian.co.uk/Iraq/Story/0,2763,1076578,00.html
> US defiant after Baghdad attack
> http://news.bbc.co.uk/1/hi/world/middle_east/3186074.stm
> US defiant on X-Ray prisoners
> http://old.smh.com.au/news/0202/10/world/world7.html
> US defiant on war crimes court
> http://www.cnn.com/2002/WORLD/europe/07/01/bosnia.peacekeeping/?related
> US stands defiant despite isolation in climate debate
> http://www.guardian.co.uk/bush/story/0,7369,526607,00.html
> US defiant and unrepentant over largest chemical warfare campaign in history
> http://www.guardian.co.uk/weekend/story/0,3605,923715,00.html
> Americans defiant over growing divisions with Europe
> http://www.telegraph.co.uk/news/main.jhtml?xml=/news/2002/02/06/wter106.xml
> US defiant over missile defense
>
>http://www.globalsecurity.org/space/library/news/2001/space-010717-wwwh1j17.htm
> Bush defiant over 'Bin Laden tape'
> http://news.bbc.co.uk/1/hi/world/middle_east/3204612.stm
> Bush defiant ahead of visit to Britain
> http://fpeng.peopledaily.com.cn/200107/18/eng20010718_75285.html
> 'Bring them on,' defiant Bush warns Iraqi militants
> http://seattletimes.nwsource.com/html/nationworld/135155984_iraq03.html
> Greenhouse gas emissions soar in defiant US
> http://observer.guardian.co.uk/international/story/0,6903,515198,00.html
> Europe seethes as defiant US goes its own way
> http://www.guardian.co.uk/bush/story/0,7369,747743,00.html
> Defiant US threatens UNs peacekeeping role
> http://www.abc.net.au/7.30/s596992.htm
> US isolated but defiant on Cuba sanctions
> http://www.sunsonline.org/trade/process/followup/1996/04160196.htm
--
---------------------------------------------------------------------
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
More information about the SCL
mailing list