Re: Action 299 - removing sorts

Hi Michael,

> Dave, please see inline.

Likewise.

>> 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
> 
> Later you said that your motivation is symmetry, while I think what you are
> proposing lacks symmetry. In my proposal everything has a data type.
> It is just that the "other" symbols have a default data type, which is not
> mentioned. 

Oh, I didn't understand that. Perhaps that changes things. In that case 
this default type should be at least mentioned and defined.

> But the syntax is uniform:
> "42"^^xsd:int
> "http://example.com/ISO4217/usd"^^rif:iri
> USD (has the default data type)
> etc.
> 
> For the XML syntax I would use
> <Const>USD</Const>
> <Const rif:type="rif:iri">http://example.com/ISO4217/usd</Const>
> <Const rif:type="xsd:int">42</Const>
> 
> It is a mistake to use attributes like xsi:type or rdf:type here because these
> are not the same things as what is being proposed from the logical point of
> view.

I only used xsi:type in my example because that was what Harold was 
advocating, it is not something I'm personally fond of.

Our definition of datatypes is the same as RDF's, at least over the 
concrete XSD types and XMLLiteral. So I don't yet see any difference 
from the logical point of view between rdf:datatype (not rdf:type) and 
what is currently proposed. However, calling it rif:type instead would 
be OK.

>> 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?
> 
> Because it corresponds to the logical syntax in the most direct way.
> 
>> 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.
> 
> I think that what we are proposing is the most symmetric treatment.

That doesn't follow for me. You picked local consts as the default type. 
It would make equal sense, indeed more sense for a web standard, to pick 
the IRI version as the default type.

>> 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.
> 
> A data type can have arbitrary domains. In some cases they are fixed, but
> the logical mechanism is much more flexible. You can specify data types
> where the domain of interpretation is the entire domain sans the xsd data
> types, for example.
> 
> Your definition of the data type needs to be generalized slightly. When I
> agreed with it, I agreed with the general idea that data types should be
> defined this way, but the details may need to be tweaked.

Fair enough.

Is there a better name for those things which do have a well-defined 
lexical-to-value mapping? Concrete datatypes?  I took the original draft 
text on datatype semantics, given the references to XSD, to be about 
such cases which is why including rif:iri felt wrong to me.

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

Received on Monday, 23 July 2007 15:40:41 UTC