Re: [BLD] Data types and IRIs

Christian de Sainte Marie wrote:
> 
> Dave Reynolds wrote:
>>
>> I'm not convinced we should be treating rif:iri as a datatype.
> 
> Is it right that typed constants have i{} as there only signature? If 
> yes, wouldn't it solve your problem if all IRIs had signature f0{()->i} 
> instead (and thus rif:iri would not be a data type)?

Not sure that would help.

I think the subsequent discussion and Michaels' changes to the draft 
have addressed this issue for me. It clarified that the document uses 
"datatype" in a very general way (not requiring a defined lexical to 
value space mapping) and that non-IRI constants, now called rif:local, 
are treated in the same way as constants identified by IRIs.

> Talking of datatypes, in 2.1.3 (BLD 7/20), "interpretation of primitive 
> datatypes", there is a sentence that I do not understand: Michale, you 
> wrote that "We assume that Dtype in D for each XML data type and that Dt 
> is disjoint from Ds for different XML primitive types s and t". How does 
> that conflict with xsd:long being a subtype of xsd:decimal?

That has changed in the current draft.

>> [[[
>> class TERM
>>     subclass CONST
>>         subclass ConstL
>>             property name: xsd:string [1]
>>         subclass ConstW
>>             property iri: xsd:anyURI
>>         subclass ConstD
>>             property lex: xsd:string
>>             property type: xsd:anyURI
>> ]]]
> 
> Why "name" for ConstL and "lex" for ConstD?

No strong reason. I only picked "lex" to clarify that that was intended 
to be the lexical-form. Overloading property names would OK to. It was 
the structure of the proposal I cared about rather than the precise 
choice of property name.

The modified proposal from Michael makes everything a typed Constant 
with rif:local corresponding to my ConstL, rif:iri corresponding to my 
ConstW.

> Also, shouldn't we extend VAR as well?
> [[[
> class TERM
>     subclass Var
>         property name: xsd:string
>         property type: xsd:anyURI
> ]]]

?? I thought we got rid of sorted variables. Wasn't that the whole 
outcome of the infamous sorts discussion?

> That is what I do in my strawman for the PR dialect (still being 
> drafted) (see also the declaration of the variable in the example in [1])
> 
> [1] http://lists.w3.org/Archives/Public/public-rif-wg/2007Jul/0114.html
> 
> Last, but not least: since primitive datatypes in BLD are defined by 
> reference to an external specification (xsd), can all datatypes be 
> handled the same way, whether they are primitive or not (and including 
> user-defined ones, e.g. in application data models)?

I don't think so. You can refer to an external specification in a spec 
that some human is reading as they implement the translator code.
To do anything useful with those datatypes you also need the 
corresponding builtin constructors, deconstructors and operations.

Presumably user-defined data models are run-time, not 
implementation-time, beasts and require some generic machinery to either 
import the corresponding builtins or map them to existing ones.

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

Received on Tuesday, 24 July 2007 14:02:23 UTC