[SCL] Re: Report on Common Logic

[pat hayes]

>Hi,
>
>pat hayes 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?
>>>>>
>>>
>>>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.
>
>I have a few comments.
>
>The basic issue is that it would be worrisome if XML
>syntax in the SCL spec would give SCL-in-XML
>_more expressive power_ than say, SCL in KIF or
>"traditional" or N3 syntax or whatever.
>
>In other words, anything having any _meaning_ in
>SCL-XML spec should be expressible in other SCL syntaxes
>(at least for the purposes of our spec!)

Agreed, but see below.

>
>Hence, the nice stuff Murray was thinking about for
>the XML syntax should be in our report also for
>the ABSTRACT syntax, or not at all.

Well, two points.
1. If this really is true, then in the short term I think we should 
say, not at all. BUT..
2. Im not sure that this really is the case. For example, there is 
nothing in the SCL logic to suggest that XCL might not have 
facilities for combining SCL content from several distinct documents. 
SCL does not concern itself with documents or refer to entire 
ontologies, and we could legitimately regard this for example as 
meta-logical in a strong sense.

>
>The way do to this is to reserve some function
>and predicate symbols in SCL full, plus have
>strings in SCL full.

We certainly need strings, but there is a delicate distinction 
between character strings and the 'abstract' thingies in the SCL AS.

>
>Then we would have a capability in syntax to
>somehow express in semantics that
>something like
>
>URL(STRING("http://www.w3c.org"))
>
>is an URL, whatever this means (I see no
>other way to give meaning for such things
>than to say that there is simply a subset of strings,
>which is called URL-s, without saying anything about
>how these URL-s etc are used).

Well, an abstract syntax could distinguish URIs from the character 
string that encodes them, although that would not be sanctioned by 
RFC 2396 and I know would be controversial.  Your function then is 
FROM strings TO URls, right? If you identify them then you don't need 
a function. (BTW, I don't think we need STRING either: we can just 
allow direct quoting in a concrete syntax.)

>
>>>   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.
>
>I agree. But this should be ANOTHER layer, not the
>SCL layer, which does this.

Agreed: I was assuming that XCL was involved with issues like this in 
the 'layer above'. After all, XML is in some strong sense *about* the 
business of encoding structure in documents and putting together 
textual entities into assemblies of one kind or another (is that 
fair, Murray?)

>
>For example (to go to extremes) we will not make SCL
>"http-enabled" and  start describing http issues
>in the SCL spec.
>
>Ie, it is http-enabled without any efforts from our
>side :-)

I agree, but still would like Murray to think about issues like this, 
which I know can get very delicate and will eventually (soon?) be 
important in a deployed standard.

>
>>>      3. are there meant to be internal link targets within an XCL document?
>>
>>
>>Not it the first instance, I think.
>
>We could have them nicely, by using annotations:
>put a special-syntax string in the annotation and
>refer to that.
>
>But, again, this is ANOTHER LAYER, not SCL spec.

Oh well, OK, but let us allow XML to find its natural layer.

Pat

>Regards,
>        Tanel Tammet


-- 
---------------------------------------------------------------------
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