Re: Action 299 - removing sorts

Hi Michael,

> thanks for your comments. I agree with most of them, but have some questions.
> See inline.

Glad they were useful.

>> ** Treatment of rif:iri
>>
>> I'm not convinced we should be treating rif:iri as a datatype.
>>
>> Setting aside rif:iri for a moment, then the set Const has subsets 
>> Const\sub{xsd:string} etc and elements which are members of none of 
>> those subsets. In the example:
>>
>>     purchase(?Buyer ?Seller book(?Author "LeRif"^^xsd:string)
>>                      USD("49"^^xsd:long))
>>
>> then the Consts identified by 'purchase', 'book' and 'USD' are all of 
>> latter category. These are simply Consts (with associated signatures 
>> induced by context, e.g. Const(purchase) has signature p4{} as well as i{}).
>>
>> As we know from previous discussions, I would like to use IRIs as the 
>> lexical label for all of those Consts, you would like to permit both 
>> simple strings and IRIs.
>>
>> My preferred solution to this is to divide Const into three subsets:
>>
>> ConstL  - semantically unconstrained, labelled by simple strings
>>
>> ConstW  - semantically unconstrained, labelled by IRIs (w for "web")
> 
> I do not understand what is the difference between what is now in the
> document and what you are suggesting. In the document the iri's have a
> separate lexical space and their interpretation is unconstrained.

I don't think there is a semantic difference, it is largely a syntactic 
issue though it does avoid having to write down a definition of a 
rif:iri datatype - see below.

> What are you exactly proposing here is not clear to me. How will the URIs
> look syntactically in the language?

As I suggested in a later part of the message:

>> For the fully striped XML syntax this would imply:
>>
>>      <Const><name>USD</name></Const>
>>      <Const><iri>http://example.com/ISO4217/usd</iri></Const>
>>      <Const><lex>42</lex><type>http://www.w3.org/2001/XMLSchema#int
>>                    </type></Const>
>>
>> For a prettified XML syntax this might imply something like:
>>
>>      <Const rif:name="USD" />
>>      <Const rif:iri="http://example.com/ISO4217/usd" />
>>      <Const xsi:type="xsd:int">42</Const>
>>
>> For the human readable syntax this might be:
>>
>>      USD
>>      <http://example.com/ISO4217/usd>
>>      "42"^^xsd:int or 42

Each group of three is supposed to illustrate a ConstL, a ConstW and a 
ConstD example.

Why use a syntactic mechanism for Consts denoted by IRIs rather than a 
datatype?

Partly it is just symmetry. If there were a reason to use a type to 
denote an unconstrained Const denoted by an IRI, then the same would be 
true of of an unconstrained Const denoted by a string and there should 
be a rif:local datatype instead of using rif:name.

Treating the two symmetrically seems to me preferable, partly because 
that would make it slightly easier to have a future dialect for exchange 
of RDF rules which *only* uses the iri form.

Partly it is because I'm uncomfortable with the formulation of the 
rif:iri datatype. We are regarding a datatype as a 4-tuple of lexical 
space, value space, lexical-to-value mapping and an identifying IRI. For 
rif:iri the lexical-to-value mapping is undefined. To me the 
distinguishing point of a typed Const is that it denotes a specific 
semantic object by means of this mapping.

Dave
-- 
Hewlett-Packard Limited
Registered Office: Cain Road, Bracknell, Berks RG12 1HN
Registered No: 690597 England

Received on Monday, 23 July 2007 11:00:15 UTC