[seek-dev] What to do about "nil"

[Chad Berkley]

I don't fully remember the details, but I think we just decided we 
needed a better solution than changing the type lattice because we would 
have had to override every single type at which point none of the 
existing actors were going to want to work with our new typing system 
(because of the typed ports).  But we never did look into it further to 
try to find a better answer.

chad

Matt Jones wrote:
> This is closely related to the issue Chad explored earlier with the 
> Ptolemy type system where types like 'double' did not allow for missing 
> values.  So we had discussed creating extended types for all of the 
> primary ptolemy types that permitted missing values.  I think we 
> concluded that that would be clunky and ultimatley result in a large 
> number fo additional type classes that would have to be added to the 
> TypeLattice.  SO I htink we decided not to do it, but I think we also 
> don't have a clean solution to the problem.  Chad -- do you remember the 
> details?
> 
> Matt
> 
> Bertram Ludaescher wrote:
> 
>> What about the more fundamental question? How do you represent 'nil'
>> in the Ptolemy and/or Java type system? I would hope that one could in
>> fact have such a distinguished value... and that the XML Schema ->
>> Ptolemy (or Java) type translation in fact create the correct
>> representation.. Handling of that value in the workflow would than be
>> quite clean, as supposed to an ad-hoc solution.
>> (But then again... the world itself seems quite ad-hoc ;-)
>>
>> Bertram
>>
>>
>>>>>>> "MJ" == Matt Jones <jones at nceas.ucsb.edu> writes:
>>
>>
>> MJ> MJ> Hi Rod,
>> MJ> You're right that the data needs to be preserved even when the 
>> lat/lon MJ> values are nil -- some people may want to see the rest of 
>> the Darwin MJ> Core record for various workflows.  However, for the 
>> purposes of the MJ> niche model example, I think we want to filter out 
>> all records that lack MJ> lat/lon data.  So.... maybe the best 
>> solution is to fire some sort of MJ> null or missing value code on the 
>> lat/lon ports, and then provide a MJ> filter downstream in the 
>> workflow that only keeps records that have MJ> legit lat/lon values -- 
>> this is what GARP ultimately needs and what MJ> should be saved in the 
>> file.
>> MJ> MJ> Matt
>> MJ> MJ> Rod Spears wrote:
>>
>>>> Here is the schema for Latitude per the DarwinCore spec:
>>>> <xsd:element name="DecimalLatitude" 
>>>> substitutionGroup="digir:searchableReturnableData" nillable="true">
>>>> <xsd:annotation>
>>>> <xsd:documentation>The latitude of the location from which the 
>>>> cataloged item was collected, expressed in decimal 
>>>> degrees.</xsd:documentation>
>>>> </xsd:annotation>
>>>> <xsd:simpleType>
>>>> <xsd:restriction base="xsd:decimal">
>>>> <xsd:minInclusive value="-90.0"/>
>>>> <xsd:maxInclusive value="90.0"/>
>>>> </xsd:restriction>
>>>> </xsd:simpleType>
>>>> </xsd:element>
>>>>
>>>> Note that the value can be "nil" and it also has a restriction. When 
>>>> the value reaches the DarwinCoreDataSource as a string it is either 
>>>> a valid number within the range or an empty string (length zero).
>>>>
>>>> Currently, I convert the empty string to "0.0" which is the wrong 
>>>> thing to do. The question is what should I do? As Dan suggested I 
>>>> could pick an arbitray large number and pass that back, but that 
>>>> assumes the consumer will know what to do with that value. I could 
>>>> skip any and all rows that have empty Lat or Long values, but that 
>>>> may be bad for consumers that want to see that data but don't care 
>>>> if it is nil (empty) or not.
>>>>
>>>> Any thoughts?
>>>>
>>>> Rod
>>>>
>>>> _______________________________________________
>>>> seek-dev mailing list
>>>> seek-dev at ecoinformatics.org
>>>> http://www.ecoinformatics.org/mailman/listinfo/seek-dev
>>
>>
>> MJ> MJ> -- MJ> 
>> -------------------------------------------------------------------
>> MJ> Matt Jones                                     jones at nceas.ucsb.edu
>> MJ> http://www.nceas.ucsb.edu/    Fax: 425-920-2439    Ph: 907-789-0496
>> MJ> National Center for Ecological Analysis and Synthesis (NCEAS)
>> MJ> University of California Santa Barbara
>> MJ> Interested in ecological informatics? http://www.ecoinformatics.org
>> MJ> -------------------------------------------------------------------
>> MJ> _______________________________________________
>> MJ> seek-dev mailing list
>> MJ> seek-dev at ecoinformatics.org
>> MJ> http://www.ecoinformatics.org/mailman/listinfo/seek-dev
> 
>