Re: Action 299 - removing sorts

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

OK.

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

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.

Perhaps.  In my experience, local constants are used more often, but I
would be happy to change that, if the group decides.

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

I think there is such a term: concrete domains or something similar.
The in the document is more general; it allows non-concrete domains.


	--michael  


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

Received on Monday, 23 July 2007 19:57:21 UTC