small comment

Good afternoon

(I have earlier commented about datatypes.)

  I have tried to apply the information in the 17-04-2015 release to 
data published by the DfE in the UK.
The context is the so-called "League Tables" ,  I don't think that this 
application is special in any way, in fact quite typical of a lot of 
data in the social sciences

1) Absence table: There is a variable LA (Local Authority a numerical 
code (152 of them) and 2 string codes LA and NAT,
  for example
#LA // first row
#801
#..
#LA
#NAT
It is ok to accept here that LA is a foreign key, and the type string, 
but really a LA (Local Authority) is one of 152 codes, and the variable 
is either one of these codes, or the  LA, or NATional. In a row this 
variable and another are an ID for the row values

whereas in
2) Spine table
#URN    GENDER // first row
#108910 Mixed
#109337 Girls
#109370 Boys
Here I am seeing "Mixed", "Girls", "Boys" as defining the type of GENDER 
and not as a key in another table. But easy to live with, even if not 
"quite right" in my opinion,

3) KS4 table
#URN    KS2APS  PTEBACC_PTQ // first row
#130391 NP      62%
#135575 29.2    30%
#136822
#137583 NP      NE
#109410 SUPP    SUPP
#109393 SUPP    NE
#109394 SUPP    SUPP
#109342 NP      SUPP
Not accepting that a variable may be basically of type integer/decimal 
with exceptions NULL and codes like NP,SUPP, NE would lead to giving 
them the type string in order to avoid validation errors. This means no 
real progress in defining the variables and this would also leave open 
the question on how to define in a standard way the "type" of the 
variables. Also the scale of the decimal number may be important, can it 
only appear in a pattern? or a format?

I understand that it may be that I am missing something, but if not, 
then I wonder why it would not be possible to have something like 
"@type" pointing to a XSD schema element? It is always easy not to use a 
facility, much more difficult to add it afterwards.

Thanks for helping, and really congratulations to all the work you are doing

Best wishes
r,





~
~

-- 

This message and the information contained within it is intended for the recipient alone and any unintentional recipient should not act upon the information apart from notifying the sender that the message has been inadvertently diverted. The unintended recipient should delete the message and inform the sender of the error.
Please consider the environment before printing this email.

Received on Wednesday, 29 April 2015 13:06:55 UTC