gnumed-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnumed-devel] Demographic address labelling "Place"


From: Jim Busser
Subject: Re: [Gnumed-devel] Demographic address labelling "Place"
Date: Tue, 20 Sep 2011 13:25:44 -0700

On 2011-09-19, at 1:42 AM, Karsten Hilbert wrote:

>  I'd like to see at least some sort of consensus among
> various Natives.

The front desk staff, after saying 'why don't you just call it a City and be 
done with it', said that -- of all the other terms to date (including Place) -- 
they prefer Community. So too does a doctor colleague pursuing bioinformatics

However, I would be happy with either Community or any one among {Locale, 
Location, Locality} as better than Place.

Discussion preserved below.

-- Jim

On 2011-09-20, at 10:22 AM <my colleague> wrote:

> Settlement is the generic term
> 
> http://en.wikipedia.org/wiki/Human_settlement
> 
> but I don't think it resonates well - at least not with me.
> 
> Community is probably closer
> 
> http://en.wikipedia.org/wiki/Community
> 
> "I'm in the Shawnigan Lake community" "I'm in the Victoria community".  It's 
> not quite right either, but better
> 
> What does HL7 or openEHR use?


OpenEHR does not even call this 'thing' anything… it models multiple, 
country-specific sets of choices among (e.g.) Town, City so the attribute can 
be selected as it would apply, and this entity is fitted between, for example 
in the case of AU

        unitNo
        houseNo
        street
        Start Choice [1] 
<city> string </city> [1] 
<town> string </town> [1] 
End Choice 
        <state> AusStates </state> [1]
        <postcode> string <<pattern = [1-9][0-9]{3}>> </postcode> [1]

Which nicely provides a validation check on postal code. However if GNUmed 
prefers to stop short of this complexity (it being a low priority) then the 
question boils down to  how we want to think about this thing… as

(a) a **geo-locator** ? There exists none more universal than latitude & 
longitude, in which case we should want

        Lat / long

however that would fail to meet our current needs, so we maybe just need to 
decide are we talking …

(b) a **geo-locator name proxy**? Then we should use as label something with 
"Loc", either

        Locale
        Locality
        Location

(c) But if we would be talking a **geo-social** grouping locator classifier, 
then we should want one among

        Settlement
        Community

-- Jim





reply via email to

[Prev in Thread] Current Thread [Next in Thread]