[prev in list] [next in list] [prev in thread] [next in thread]
List: openmrs-dev
Subject: Re: Providing more accuracy in estimated dates
From: Rowan Seymour <rowanseymour () gmail ! com>
Date: 2012-11-30 7:43:42
Message-ID: CAEhK25qhQGreqGmg=zxOX0AxQK-4AG36s3sYUF+Ur3e1woZBCw () mail ! gmail ! com
[Download RAW message or body]
It's helpful to consider those two scenarios but don't you think that 1) is
considerably more common than 2) ? We can further break down 1 into several
possible scenarios with increasing accuracy:
1a) Patient can estimate year
1b) Patient knows year only
1c) Patient knows year and can estimate month
1d) Patient knows year and month only
1e) Patient knows year and month and can estimate date
Problems with current approach:
- The current underlying data model doesn't model the significantly
different level of accuracy between any of these (birthdate =
1-Jan-1970, birthdateEstimated = true could be the data stored for any
of these scenarios). UI changes can't address that.
- 1b and 1d are especially problematic with the current model because
the user has to pick an arbitrary month or date, usually Date = 1, Month
= Jan, which as you say causes data lumping. Even with UI changes you
still have to put a valid month and date into the data model. The best you
could do to improve this is use "mean" values like Date = 15, Month =
June to improve the accuracy of long term date range calculations.
-Rowan
PS. Could a ticket from 2007 finally make it into core!
On 30 November 2012 01:56, Friedman, Roger (CDC/CGH/DGHA) (CTR) <
rdf4@cdc.gov> wrote:
> Rowan --****
>
> Reading your underlying problem, I wonder whether it
> really makes a difference whether we know how accurate the estimate is so
> long as we know it's estimated. I think if somebody were brought into the
> emergency room without ID and unable to communicate, the doctor wouId
> simply estimate the age in years and take it from there. With peds, there
> might be more of an effort to be accurate, but also more clues.****
>
> However, if you want to address this, I think it breaks
> down into 2 use cases:****
>
> (1) Where the high-order date parts are
> known and only lower-order date parts are not known. ****
>
> In this case, the problem is not so much with the
> representation of the data but with the values chosen. With
> date-aggregated data, the use of constants for missing low-order fields
> causes unnatural lumps in the distribution; one practice in epi is to
> assign unknown date values randomly over the appropriate period. I raised
> this issue several years ago here, and the response was that the use of
> fixed values furthered the identification of estimated dates. This is the
> case referred to in TRUNK-17.****
>
> (2) Where the at least one high-order date
> part is unknown but a lower-order date part is known.****
>
> In this case, a person might know he was born on Christmas
> but the year is 1938 or 1939. I think you don't have much choice here but
> to choose one or the other and mark it as estimated. Or if she was born on
> Easter but the year is 1948 or 1949, you can choose one and either look up
> the day of Easter or choose a random date in the date range of Easter and
> mark it as estimated. Or you could split the difference and make him born
> in June 25, 1939 and her born Oct 4, 1948.****
>
> At any rate, it seems that any of this that needs
> addressing could be handled at the UI level without changing the data model.
> ****
>
> Saludos, Roger****
>
> ** **
>
> *From:* dev@openmrs.org [mailto:dev@openmrs.org] *On Behalf Of *Rowan
> Seymour
> *Sent:* Friday, November 09, 2012 1:31 AM
>
> *To:* dev@openmrs.org
> *Subject:* Re: Providing more accuracy in estimated dates****
>
> ** **
>
> I'd like to mess with it in a way that doesn't change the behaviour of
> Person.getBirthdate or Person.getEstimatedBirthdate, so I assume there
> wouldn't be any effect on the RESTWS module?****
>
> ** **
>
> -Rowan****
>
> On 9 November 2012 03:00, Friedman, Roger (CDC/CGH/DGHA) (CTR) <
> rdf4@cdc.gov> wrote:****
>
> If you’re going to mess with this, you also have to handle the RESTWS
> changes.****
>
> ****
>
> *From:* dev@openmrs.org [mailto:dev@openmrs.org] *On Behalf Of *Jeremy
> Keiper
> *Sent:* Tuesday, November 06, 2012 5:13 AM
> *To:* dev@openmrs.org
> *Subject:* Re: Providing more accuracy in estimated dates****
>
> ****
>
> A GSoC student of mine mostly-implemented a partial date method for
> creating more accurate / precise estimations, and it was initially
> implemented on birthdate. We never had a chance to try rolling it back in,
> but I think it's a great idea.****
>
> ****
>
> Take a look here:
> https://github.com/openmrs/openmrs-core/tree/approximate-datetime ...
> it's an old branch, 1.7-based, I think.****
>
>
>
> Jeremy Keiper
> OpenMRS Core Developer
> AMPATH / IU-Kenya Support****
>
> On Tue, Nov 6, 2012 at 9:09 AM, Michael Seaton <mseaton@pih.org> wrote:***
> *
>
> Hi Rowan,
>
> I know this has come up a bunch in the past. Have you seen this ticket:
> https://tickets.openmrs.org/browse/TRUNK-17? The comments shed some
> light on the history - that there was an initial patch attached in 2009, a
> 2010 GSoC project around it that is in a pre-mavenized branch somewhere,
> and no real activity in over a year.
>
> Unfortunately, it shows as "scheduled" for 1.10 and is currently assigned,
> but is clearly not being actively worked on...
>
> MIke****
>
>
>
> ****
>
> On 11/06/2012 06:35 AM, Rowan Seymour wrote:****
>
> Wondering if there's any interest in improving our handling of estimated
> dates, namely the birthdate. Currently we represent that with a date object
> and a boolean to say whether it's accurate or not, i.e.****
>
> ****
>
> Date birthdate;****
>
> Boolean birthdateEstimated = false;****
>
> ****
>
> But that doesn't give us any way of differentiating between a date where
> the month and year are known and a date where only the year is known. For
> example if person #1 knows they were born in January 1993, but doesn't know
> the date, we can store that as:****
>
> ****
>
> date: 1-Jan-1993, estimated: true****
>
> ****
>
> If another person #2 knows only that they were born in 1993, we store that
> exactly the same:****
>
> ****
>
> date: 1-Jan-1993, estimated: true****
>
> ****
>
> One of the differences between these two people is that we can say with
> certainty that person #1 is 19 years old, whereas person #2 could be 18 or
> 19 years old. ****
>
> ****
>
> -Rowan
>
> --
> OpenMRS Developers: http://go.openmrs.org/dev
> Post: dev@openmrs.org
> Unsubscribe: dev+unsubscribe@openmrs.org
> Manage your OpenMRS subscriptions at https://id.openmrs.org/
>
> ****
>
> ****
>
> --
> OpenMRS Developers: http://go.openmrs.org/dev
> Post: dev@openmrs.org
> Unsubscribe: dev+unsubscribe@openmrs.org
> Manage your OpenMRS subscriptions at https://id.openmrs.org/
>
> ****
>
> ****
>
> --
> OpenMRS Developers: http://go.openmrs.org/dev
> Post: dev@openmrs.org
> Unsubscribe: dev+unsubscribe@openmrs.org
> Manage your OpenMRS subscriptions at https://id.openmrs.org/
>
> ****
>
> --
> OpenMRS Developers: http://go.openmrs.org/dev
> Post: dev@openmrs.org
> Unsubscribe: dev+unsubscribe@openmrs.org
> Manage your OpenMRS subscriptions at https://id.openmrs.org/
>
> ****
>
>
>
> ****
>
> ** **
>
> --
> *Rowan Seymour*
> tel: +250 783835665****
>
> --
> OpenMRS Developers: http://go.openmrs.org/dev
> Post: dev@openmrs.org
> Unsubscribe: dev+unsubscribe@openmrs.org
> Manage your OpenMRS subscriptions at https://id.openmrs.org/
>
> ****
>
> --
> OpenMRS Developers: http://go.openmrs.org/dev
> Post: dev@openmrs.org
> Unsubscribe: dev+unsubscribe@openmrs.org
> Manage your OpenMRS subscriptions at https://id.openmrs.org/
>
>
>
--
*Rowan Seymour*
tel: +250 783835665
--
OpenMRS Developers: http://go.openmrs.org/dev
Post: dev@openmrs.org
Unsubscribe: dev+unsubscribe@openmrs.org
Manage your OpenMRS subscriptions at https://id.openmrs.org/
[Attachment #3 (text/html)]
<div>It's helpful to consider those two scenarios but don't you think that 1) \
is considerably more common than 2) ? We can further break down 1 into several \
possible scenarios with increasing accuracy:</div><div><br>
</div><div>1a) Patient can estimate year</div><div>1b) Patient knows year \
only</div><div>1c) Patient knows year and can estimate month</div><div>1d) Patient \
knows year and month only</div><div>1e) Patient knows year and month and can estimate \
date</div>
<div><br></div><div>Problems with current approach:</div><div><ul><li>The current \
underlying data model doesn't model the significantly different level of accuracy \
between any of these (<font face="courier new, monospace">birthdate = 1-Jan-1970, \
birthdateEstimated = true</font> could be the data stored for any of these \
scenarios). UI changes can't address that.</li>
<li>1b and 1d are especially problematic with the current model because the user has \
to pick an arbitrary month or date, usually <font face="courier new, monospace">Date \
= 1, Month = Jan</font>, which as you say causes data lumping. Even with UI changes \
you still have to put a valid month and date into the data model. The best you could \
do to improve this is use "mean" values like <font face="courier new, \
monospace">Date = 15, Month = June</font> to improve the accuracy of long term date \
range calculations.</li>
</ul></div><div>-Rowan</div><div><br></div>PS. Could a ticket from 2007 finally make \
it into core!<br><br><div class="gmail_quote">On 30 November 2012 01:56, Friedman, \
Roger (CDC/CGH/DGHA) (CTR) <span dir="ltr"><<a href="mailto:rdf4@cdc.gov" \
target="_blank">rdf4@cdc.gov</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex">
<div lang="EN-US" link="blue" vlink="purple">
<div>
<p class="MsoNormal"><span \
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Rowan \
--<u></u><u></u></span></p> <p class="MsoNormal"><span \
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> \
Reading your underlying problem, I wonder whether it really makes a difference \
whether we know how accurate the estimate is so long as we know it's estimated. \
I think if somebody were brought into the emergency room without ID and unable to \
communicate, the doctor wouId simply estimate the age in years and take it from \
there. With peds, there might be more of an effort to be accurate, but also more \
clues.<u></u><u></u></span></p> <p class="MsoNormal"><span \
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> \
However, if you want to address this, I think it breaks down into 2 use \
cases:<u></u><u></u></span></p>
<p class="MsoNormal"><span \
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> \
(1) Where the high-order date parts are known and only lower-order date parts are not \
known. <u></u><u></u></span></p>
<p class="MsoNormal"><span \
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> \
In this case, the problem is not so much with the representation of the data but with \
the values chosen. With date-aggregated data, the use of constants for missing \
low-order fields causes unnatural lumps in the distribution; one practice in epi is \
to assign unknown date values randomly over the appropriate period. I raised this \
issue several years ago here, and the response was that the use of fixed values \
furthered the identification of estimated dates. This is the case referred to in \
TRUNK-17.<u></u><u></u></span></p> <p class="MsoNormal"><span \
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> \
(2) Where the at least one high-order date part is unknown but a lower-order date \
part is known.<u></u><u></u></span></p>
<p class="MsoNormal"><span \
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> \
In this case, a person might know he was born on Christmas but the year is 1938 or \
1939. I think you don't have much choice here but to choose one or the other \
and mark it as estimated. Or if she was born on Easter but the year is 1948 or 1949, \
you can choose one and either look up the day of Easter or choose a random date in \
the date range of Easter and mark it as estimated. Or you could split the \
difference and make him born in June 25, 1939 and her born Oct 4, \
1948.<u></u><u></u></span></p> <p class="MsoNormal"><span \
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> \
At any rate, it seems that any of this that needs addressing could be handled at the \
UI level without changing the data model.<u></u><u></u></span></p>
<p class="MsoNormal"><span \
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Saludos, \
Roger<u></u><u></u></span></p> <p class="MsoNormal"><span \
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> \
<u></u></span></p> <p class="MsoNormal"><b><span \
style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span \
style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> <a \
href="mailto:dev@openmrs.org" target="_blank">dev@openmrs.org</a> [mailto:<a \
href="mailto:dev@openmrs.org" target="_blank">dev@openmrs.org</a>] <b>On Behalf Of \
</b>Rowan Seymour<br> <b>Sent:</b> Friday, November 09, 2012 1:31 \
AM</span></p><div><div class="h5"><br> <b>To:</b> <a href="mailto:dev@openmrs.org" \
target="_blank">dev@openmrs.org</a><br> <b>Subject:</b> Re: Providing more accuracy \
in estimated dates<u></u><u></u></div></div><p></p><div><div class="h5"> <p \
class="MsoNormal"><u></u> <u></u></p> <p class="MsoNormal">I'd like to mess with \
it in a way that doesn't change the behaviour of Person.getBirthdate or \
Person.getEstimatedBirthdate, so I assume there wouldn't be any effect on the \
RESTWS module?<u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt">-Rowan<u></u><u></u></p>
<div>
<p class="MsoNormal">On 9 November 2012 03:00, Friedman, Roger (CDC/CGH/DGHA) (CTR) \
<<a href="mailto:rdf4@cdc.gov" target="_blank">rdf4@cdc.gov</a>> \
wrote:<u></u><u></u></p> <div>
<div>
<p class="MsoNormal"><span \
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">If \
you’re going to mess with this, you also have to handle the RESTWS \
changes.</span><u></u><u></u></p>
<p class="MsoNormal"><span \
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> \
</span><u></u><u></u></p> <p class="MsoNormal"><b><span \
style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span \
style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> <a \
href="mailto:dev@openmrs.org" target="_blank">dev@openmrs.org</a> [mailto:<a \
href="mailto:dev@openmrs.org" target="_blank">dev@openmrs.org</a>] <b>On Behalf Of \
</b>Jeremy Keiper<br> <b>Sent:</b> Tuesday, November 06, 2012 5:13 AM<br>
<b>To:</b> <a href="mailto:dev@openmrs.org" target="_blank">dev@openmrs.org</a><br>
<b>Subject:</b> Re: Providing more accuracy in estimated \
dates</span><u></u><u></u></p> <div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">A GSoC student of mine mostly-implemented a partial date method \
for creating more accurate / precise estimations, and it was initially implemented on \
birthdate. We never had a chance to try rolling it back in, but I think it's a \
great idea.<u></u><u></u></p> <div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">Take a look here: <a \
href="https://github.com/openmrs/openmrs-core/tree/approximate-datetime" \
target="_blank">https://github.com/openmrs/openmrs-core/tree/approximate-datetime</a> \
... it's an old branch, 1.7-based, I think.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br clear="all">
<br>
Jeremy Keiper<br>
OpenMRS Core Developer<br>
AMPATH / IU-Kenya Support<u></u><u></u></p>
<div>
<p class="MsoNormal">On Tue, Nov 6, 2012 at 9:09 AM, Michael Seaton <<a \
href="mailto:mseaton@pih.org" target="_blank">mseaton@pih.org</a>> \
wrote:<u></u><u></u></p> <div>
<p class="MsoNormal">Hi Rowan,<br>
<br>
I know this has come up a bunch in the past. Have you seen this ticket: <a \
href="https://tickets.openmrs.org/browse/TRUNK-17" target="_blank"> \
https://tickets.openmrs.org/browse/TRUNK-17</a>? The comments shed some light on the \
history - that there was an initial patch attached in 2009, a 2010 GSoC project \
around it that is in a pre-mavenized branch somewhere, and no real activity in over a \
year.<br>
<br>
Unfortunately, it shows as "scheduled" for 1.10 and is currently assigned, \
but is clearly not being actively worked on...<br> <br>
MIke<u></u><u></u></p>
<div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
<br>
<u></u><u></u></p>
<div>
<p class="MsoNormal">On 11/06/2012 06:35 AM, Rowan Seymour wrote:<u></u><u></u></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal">Wondering if there's any interest in improving our handling \
of estimated dates, namely the birthdate. Currently we represent that with a date \
object and a boolean to say whether it's accurate or not, i.e.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">Date birthdate;<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">Boolean birthdateEstimated = false;<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">But that doesn't give us any way of differentiating between \
a date where the month and year are known and a date where only the year is known. \
For example if person #1 knows they were born in January 1993, but doesn't know \
the date, we can store that as:<u></u><u></u></p> </div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">date: 1-Jan-1993, estimated: true<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">If another person #2 knows only that they were born in 1993, we \
store that exactly the same:<u></u><u></u></p> </div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">date: 1-Jan-1993, estimated: true<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">One of the differences between these two people is that we can \
say with certainty that person #1 is 19 years old, whereas person #2 could be 18 or \
19 years old. <u></u><u></u></p> </div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<p class="MsoNormal">-Rowan<br>
<br>
-- <br>
OpenMRS Developers: <a href="http://go.openmrs.org/dev" \
target="_blank">http://go.openmrs.org/dev</a><br>
Post: <a href="mailto:dev@openmrs.org" target="_blank">dev@openmrs.org</a><br>
Unsubscribe: <a href="mailto:dev+unsubscribe@openmrs.org" \
target="_blank">dev+unsubscribe@openmrs.org</a><br> Manage your OpenMRS subscriptions \
at <a href="https://id.openmrs.org/" target="_blank"> https://id.openmrs.org/</a><br>
<br>
<u></u><u></u></p>
</blockquote>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
</div>
</div>
<div>
<div>
<p class="MsoNormal">--
<br>
OpenMRS Developers: <a href="http://go.openmrs.org/dev" \
target="_blank">http://go.openmrs.org/dev</a><br>
Post: <a href="mailto:dev@openmrs.org" target="_blank">dev@openmrs.org</a><br>
Unsubscribe: <a href="mailto:dev%2Bunsubscribe@openmrs.org" \
target="_blank">dev+unsubscribe@openmrs.org</a><br> Manage your OpenMRS subscriptions \
at <a href="https://id.openmrs.org/" target="_blank"> https://id.openmrs.org/</a><br>
<br>
<u></u><u></u></p>
</div>
</div>
</div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<p class="MsoNormal">--
<br>
OpenMRS Developers: <a href="http://go.openmrs.org/dev" \
target="_blank">http://go.openmrs.org/dev</a><br>
Post: <a href="mailto:dev@openmrs.org" target="_blank">dev@openmrs.org</a><br>
Unsubscribe: <a href="mailto:dev+unsubscribe@openmrs.org" \
target="_blank">dev+unsubscribe@openmrs.org</a><br> Manage your OpenMRS subscriptions \
at <a href="https://id.openmrs.org/" target="_blank"> https://id.openmrs.org/</a><br>
<br>
<u></u><u></u></p>
</div>
</div>
</div>
</div>
<div>
<div>
<p class="MsoNormal">-- <br>
OpenMRS Developers: <a href="http://go.openmrs.org/dev" \
target="_blank">http://go.openmrs.org/dev</a><br>
Post: <a href="mailto:dev@openmrs.org" target="_blank">dev@openmrs.org</a><br>
Unsubscribe: <a href="mailto:dev%2Bunsubscribe@openmrs.org" \
target="_blank">dev+unsubscribe@openmrs.org</a><br> Manage your OpenMRS subscriptions \
at <a href="https://id.openmrs.org/" target="_blank"> https://id.openmrs.org/</a><br>
<br>
<u></u><u></u></p>
</div>
</div>
</div>
<p class="MsoNormal"><br>
<br clear="all">
<u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt">-- <br>
<b>Rowan Seymour</b><br>
tel: <a href="tel:%2B250%20783835665" target="_blank">+250 \
783835665</a><u></u><u></u></p> </div>
<p class="MsoNormal">-- <br>
OpenMRS Developers: <a href="http://go.openmrs.org/dev" \
target="_blank">http://go.openmrs.org/dev</a><br>
Post: <a href="mailto:dev@openmrs.org" target="_blank">dev@openmrs.org</a><br>
Unsubscribe: <a href="mailto:dev+unsubscribe@openmrs.org" \
target="_blank">dev+unsubscribe@openmrs.org</a><br> Manage your OpenMRS subscriptions \
at <a href="https://id.openmrs.org/" target="_blank">https://id.openmrs.org/</a><br> \
<br> <u></u><u></u></p>
</div></div></div>
</div><div class="HOEnZb"><div class="h5">
<p></p>
-- <br>
OpenMRS Developers: <a href="http://go.openmrs.org/dev" \
target="_blank">http://go.openmrs.org/dev</a><br>
Post: <a href="mailto:dev@openmrs.org" target="_blank">dev@openmrs.org</a><br>
Unsubscribe: <a href="mailto:dev%2Bunsubscribe@openmrs.org" \
target="_blank">dev+unsubscribe@openmrs.org</a><br> Manage your OpenMRS subscriptions \
at <a href="https://id.openmrs.org/" target="_blank">https://id.openmrs.org/</a><br> \
<br> <br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><b>Rowan \
Seymour</b><br>tel: +250 783835665<br> <br>
<p></p>
-- <br />
OpenMRS Developers: <a \
href="http://go.openmrs.org/dev">http://go.openmrs.org/dev</a><br />
Post: dev@openmrs.org<br />
Unsubscribe: dev+unsubscribe@openmrs.org<br />
Manage your OpenMRS subscriptions at <a \
href="https://id.openmrs.org/">https://id.openmrs.org/</a><br /> <br />
<br />
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic