[SCL] Suggestion for SCL extension module

[Murray Altheim]

Tanel Tammet wrote:
[...]
> However, I have problems understanding how the URI mechanism
> would help us for this proposed module in SCL spec, except as
> a trivial, non-normative suggestion for implementors of
> extensions.

I'm not advocating that URIs be used directly in SCL, so I think
we're having a bit of a disconnect.

> For example, say that  the file
> 
> ==============
> ostrich(dave).
> forall X. extended_3(default-implies,bird(X),flies(X)).
> =============
> 
> is written as
> 
> ==============
> ostrich(dave).
> forall X. 
> extended_3(http://something.org/mylang/default-implies,bird(X),flies(X)).
> =============
> 
> which is surely a sensible thing, but is IMHO outside the scope of  SCL.

Actually, I wouldn't recommend putting URIs inline like that. It's messy,
and seems like we're now mixing up levels.

> For SCL both "default-implies" and 
> "http://something.org/mylang/default-implies"
> are constants with no internal structure whatsover. We could think about 
> taking
> a convention saying that instead of
> 
> ==============
> ostrich(dave).
> forall X. 
> extended_3(http://something.org/mylang/default-implies,bird(X),flies(X)).
> =============
> one should rather write
> 
> ==============
> ostrich(dave).
> forall X. 
> extended_3(URI(http://something.org/mylang/default-implies),bird(X),flies(X)). 
> 
> =============
> where "URI" is a "reserved" word in SCL, but I do not see how
> that would be helpful or necessary in the SCL scope. Sure people
> could write their constructions in the latter form, and we could _suggest_
> that this is good practice,  but there is nothing in SCL semantics which
> would make any difference.
> 
> What _could_ make a small difference:
> 
> a) say we use the special string module which defines something like
>  not(equal(string(a) ,string(b)) unless "a" and "b" are syntactically
>  equal.  Now, "a" and "b" are still ordinary constants for all other
>  SCL purposes except the special string operators.
> 
> b) then we could, in principle, do the same for URI-s, but
>   rather we could just treat them as strings.
> 
> But I see not intuition behind having a special URI datatype in SCL.
> Strings should  be enough for the SCL level.
> 
> It is true, though, that some OUTER layer could determine that
> a particular string is an URI, and then use this information.

I'd say that is a better path. If you look at the XML Namespace
mechanism, it's a mapping between a namespace prefix (usually a small
number of characters, 1-10, and a specific URI), e.g.,

   <foo xmlns:blah="http://www.blah.com/1.3/">
     <blah:bippy blah:boop="Snoop Doggy Dogg"/>
   </foo>

where "blah" is mapped to "http://www.blah.com/1.3/". Semantically,
wherever you see "blah" you could consider that as the URI, though
it's actually invalid to use the URI. I'd suggest something like
that for SCL if we wanted to incorporate a namespace mechanism for
naming components. It'd be similar to your annot(), but would have
the *specific* semantics of mapping a URI to a short string, and
nothing else. That mapping table would be used to locate the URI
identifier associated with the short string. We'd have to have a
way of only using those short strings in ways that were unambiguously
references to the map.

> However, such OUTER information can be conveyed nicely
> with the SCL annot function. You could say, for example,

Except that you are really overloading annot() because a URI is not
an annotation. It can either be considered as an identifier directly,
or as a map between a string and the URI identifier.

> We could have something XML-ish in the XML syntax
> of SCL, but then it should be clearly noted as an extra
> layer, specific for XML syntax, not shared with SCL
> abstract syntax or semantics or other SCL syntaxes.
> Which is a bit worrisome, but the good points could
> overweigh the negative ones (unless we push this
> additional layer too far). I have no predetermined
> views on this, and would rather consider it case-by-case.

I'm not suggesting that URIs be at the SCL level. I don't really
thing that's appropriate.

> It will make sense, though, to give URI-s for
> all SCL language operators.  This is a good idea but
> unrelated to the previous discussion.

Yes, and that's really what I'm advocating. What I'd like to see is
a standardized way for people to declare the URI for a custom component,
in a machine-readable way. We'd use that same mechanism to declare the
standardized strings used for functions et al within SCL, perhaps as
part of an optional module. Either that, or *all* of this is done in
the prose, and people doing custom modules are given instructions on
how to properly document their customizations. It's probably better to
have a machine-readable way so that humans don't have to be in the loop
of interpreting specifications just to take in new content.

Murray

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

    "The parties themselves, working with the Arab nations, have to find a
    way to co-operate to fight terror, without putting American forces in
    an area where they will become targets."
                              -- White House Press Secretary Ari Fleischer.
                  http://news.bbc.co.uk/1/hi/world/middle_east/2989154.stm