[SCL] SCL basic consensus badly needed

[Tanel Tammet]

Hi,

pat hayes wrote:

>> Speaking about the substance, your email takes a very
>> optimistic view, I'd say, assuming that we can have
>> really nice translations from SCL to SFOL and
>> that the equality problems can be avoided
>> very easily. At the same time, I have still seen
>> no concrete SCL->SFOL transformation rules which would
>> indicate that the optimism is warranted.
>
>
> I will try to produce a sketch soon (This weekend?? Hmmm.)

...

>> Now, suppose that F1.SCL does not contain any variables
>> in predicate and function places. Would you say that F1.SCL
>> does not need any transformations at all and the formula
>>
>> F1.SCL & F2. SFOL => Q.SFOL
>>
>> can be considered to be IMMEDIATELY in a uniform
>> language SFOL?
>
>
> I see where you are going, and agree there is an issue here.

....

> However I think we are a long way from that scenario arising in that 
> level of detail, to be frank. Most of the deployed SW content is going 
> to be written in sub-FOL languages like RDF and OWL and maybe a few 
> Horn-rules languages, and we can provide standard embeddings of these 
> into SCL and if necessary into the SFOL subset (using embeddings where 
> we say so) which will suffice to handle a lot of the existing traffic 
> for the immediate future.

....

> If your issue ever gets to be a serious problem I think the SW will by 
> then have evolved techniques for indicating markup style and for 
> negotiating mutually acceptable encodings for transferring content. 


It *is already* a serious problem in my current project, containing a system
eating a number of languages and combining the information.

I am translating everything to kind-of-SCL and the question of mixing 
various languages
together is very real.  I do not need official standards for this, of 
course, but
I do need clear algorithms for X-language->SCL translation, without
various strange exceptions. For example, your own RDF(S) semantics
in Lbase has been most helpful (Lbase is incredibly better to use than the
"official" semantics alone).

The same kind of scenario is likely to become very common for
other implementors moving into the area.

>
> Yes, caching is always an issue if we have nay kind of re-coding going 
> on, obviously. BUt again, I don't think this is unsurmountable, even 
> in the worst case; and I suspect that the problem will be solved 
> before we get to it, in practice, by existing and emerging SW markup 
> conventions.

SW markup conventions cannot solve this without coherent semantics presented
in the Lbase style, be the target language based on SCL, CL or something 
else.

I guess most of the people engaged with SCL, especially you yourself,
see our SCL project in this light: to be a usable base language
for translating other languages into.

If that is the case, then usefulness for translating into
is really what we are after, and the language itself,
outside the translation aspects, is of little importance.

Hence we should take the translation aspects most
seriously, IMHO. They are the very reason for SCL.
Maybe people disagree, but I am rather inclined to
think that this is a common understanding or
motivation for SCL.

> One needs instnaces of the substitution schema for all of the 
> vocabulary. If the vocabulary of your theory uses holds/app then you 
> need those instances.
>
>>
>> When you do this,  I am pretty confident that you will soon have to
>> tackle the Horrocks confusion and bringing out different versions of
>> equality may start looking like a nice cure :)
>
>
> OK, I take that as a challenge to give more details. I will try to do 
> that soon. It is time that the whole SCL->SFOL holds/app embedding was 
> written up in FULL detail anyway.

......

>> To summarise the equality issue,  I'd be happy if we could avoid 
>> bringing in
>> two equalities (nothing cool about two different equalities) but I 
>> have no inclinations
>> to believe this can be avoided unless:
>>
>> - Somebody writes an SCL->SFOL embedding algorithm and
>> - Axiomatises equality
>>
>> So that the Horrocks problems do not arise and we have access to the 
>> ordinary SFOL
>> equality.
>
>
> Yes, we need to do that. OK, I will try.


This challenge was the reason for the current mail: just wanted to keep
nagging that we need the details. Would be cool to have the details
before the Sanibel event.

Regards,
           Tanel Tammet