[SCL] Suggestion for SCL extension module

[pat hayes]

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

I think we should *allow* them there, though. It is fine to use URIs 
(URirefs, whatever) as your logical names if you like to work that 
way.

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

Er... we would call this syntax. But go on.....

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

Why not? Anything can be an SCL 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.

I see that as part of the XML machinery for the XML syntax. I agree 
its extremely handy to be able to do this.  Issue, though: suppose my 
CL syntax doesn't use URIs for its identifiers. Should an XCL -markup 
of my SCL use XML namespaces? Like, for example, should it be 
XML-mandatory that all my identifiers are linked to my document's 
URI, as is done in the RDF/OWL world?

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

I think the ideal would be for us to provide a clear set of 
instructions for how to put up a concrete SCL syntax in a 
machine-readable form somewhere, and refer to it using a URI, and to 
actually do this for our own examples.  Your XML savvy would be a 
welcome input on how best to do this.  But we should not require or 
mandate the use of his mechanism for all SCL concrete syntaxes, since 
there could be other SCL uses that just don't fit into XML.

BTW, do you have any views about DSDL ? I just discovered this, and
surely it ought to be relevant somehow to what we are trying to do 
(?) and it is an ISO standard and all.

http://xml.coverpages.org/dsdl.html

Especially part 3, the schematron:

http://www.ascc.net/xml/resource/schematron/#overview

which apparently isnt yet quite a standard, but it is very cute.

Pat


-- 
---------------------------------------------------------------------
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://philebus.tamu.edu/pipermail/scl/attachments/20031105/5f13e5e3/attachment-0001.htm