Re: Action 299 - removing sorts

Dave, please see inline.

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

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

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


	--michael  


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

Received on Monday, 23 July 2007 15:01:26 UTC