On 13/12/2013 12:08, J DAVIS wrote:
> Great work, Richard!
A pleasure. Think of it as my Christmas present to the community. (Last 
year's present - a Linked Data rendition of Shakespeare [1] - seems to 
be tucked away in a drawer along with the reindeer jumpers. Admittedly 
it wasn't very well wrapped. :-) )
> Sarah,
> In projects I've worked on in the past, I came to the conclusion that dates needed to have a field each for year, month & day, especially when the dates could range from contemporary to prehistoric (and earliest and latest so approximate dates could be used rather than leaving out uncertain information). It worked - and the data has been exchanged or re-used.
We continue to use the original MDA conventions for dates: d.m.y, m.y or 
y depending on what is known, with range for date spans. It's trivial to 
convert this format to ISO date format as required. You'll see that I 
have expressed year-only dates as the gYear data type in my RDF, whereas 
d.m.y ones are expressed as date.  Thus the data type correctly reflects 
the degree of precision that the date expresses.

So that seems to me like a reasonable choice for a data publisher to 
make - of course, we also need to think about what data consumers would 
like.  But then it's a chicken and egg problem - until there is data out 
there, there is nothing for consumers to consume, let alone criticise.

> When setting up the database for the Parks & Gardens UK biographical information, we included fields for alternative names to allow for married names, inherited titles, nicknames (a bit of a thing with historical horticultural folk) etc. It was particularly important when recording families where the same first name was used liberally so, for example, not only fathers and sons shared it but also cousins, occasionally brothers - and they often lived in the same town, sometimes the same house, and had the same type of occupation. We had different rules for living people.
I'm strongly of the opinion that we should record people using numeric 
identifiers, and back these up with as many assertions about the person 
as we can realistically provide.  Deciding whether two people are 
actually the same individual will involve mapping Venn diagrams of 
uncertainty against each other.  In this project I used XSLT to check 
whether the year of birth and death was the same, when trying to decide 
if the dbpedia entry referred to the same person as the Tate one.  This 
is valid, even though one set of dates is year-only and the other 
day-specific.  When using FreeBMD [2] (which isn't yet a Linked Data 
resource, but I keep hoping) you have imprecision both temporally (these 
are quarterly summaries, done after the event) and geographically 
(location is that of the Registration office, not where the person 
lived).  I look forward to the development of tools to match sets of 
assertions of this sort, and return a confidence rating as to whether 
one or two people are being described.

> I know I don't want my exact date of birth or place I live to be displayed in catalogues online - although I would, of course, be happy for those to be displayed after I've died. I assume other people would have the same preference. Since my first and last names are common, I feel the need at times for a personal URI & mechanism by which more detailed information can be added to databases after my death and not all immediately after.
Yes, dead people are much easier!  If we're looking to record "history", 
that's a reasonable simplifying assumption to make, maybe.

Richard

[1] e.g. http://richardlight.org.uk/Plays/shakespeare/id/rdf/649677
[2] http://www.freebmd.org.uk/

>
> Janet
>
> Janet E Davis
>
>
> ****************************************************************
>         website:  http://museumscomputergroup.org.uk/
>         Twitter:  http://www.twitter.com/ukmcg
>        Facebook:  http://www.facebook.com/museumscomputergroup
>   [un]subscribe:  http://museumscomputergroup.org.uk/email-list/
> ****************************************************************
>

-- 
*Richard Light*

****************************************************************
       website:  http://museumscomputergroup.org.uk/
       Twitter:  http://www.twitter.com/ukmcg
      Facebook:  http://www.facebook.com/museumscomputergroup
 [un]subscribe:  http://museumscomputergroup.org.uk/email-list/
****************************************************************