In message <[log in to unmask]>, Nicholas Crofts 
<[log in to unmask]> writes

>Historical periods obviously need to be localised. "Bronze age" doesn't 
>mean much its own. This can be done using a qualifier in the period 
>name (e.g. "Bronze age, Britain") - the traditional controlled 
>vocabulary approach - but it might be useful to provide a link to a 
>separate place concept as well (which is what the CIDOC CRM requires). 
>The only real difficulty is finding an appropriate way to represent 
>this in SKOS.

Interestingly, "Bronze age" and "Bronze age, Britain" are both instances 
of the CRM class E4.Period, since this includes the possibility of 
bounding by space (= geographical area) as well as time.  It would 
certainly be useful to state explicitly that concepts are geological 
periods, archaeological periods, etc.

Which brings me to Richard's points, all of which are entirely 
reasonable. The internal data structure does indeed have separate 
start/end fields, but it's not easy to shoe-horn all these relations 
into a SKOS representation. SKOS is attractive because of its (relative) 
simplicity, but it does entail some tradeoffs. Perhaps the answer would 
be to provide two different formats for the response - SKOS if all 
that's needed is a simple name-to-time-span translation, and a more 
complex CRM compatible RDF format for all the messy stuff. The effort 
involved is not huge, it would depend on the demand - any takers??

I don't see how it can be done in SKOS, but is there anything to stop 
you creating a single RDF resource which is a mix of SKOS definitions of 
concepts (etc.), and CRM-type RDF assertions about the same concepts? If 
not that, then two separate RDF resources which contain lots of 
cross-references (by URL) between them.  Comes to the same thing, once 
you have resolved the URL references.

The collaborative aspect is also important. Technically, submitting 
candidates and corrections isn't very difficult to implement. More 
importantly, and depending on the volume and flakiness of the 
candidates, it would probably require a maintenance organisation of some 
sort... CIDOC perhaps.

Maybe.  The international perspective would obviously be good.  However, 
the first question we should always ask is "does the museum (or MLA) 
community need to invent this?".  Dbpedia, for example, already defines 
a number of geological periods (although without stating that they are 
such). What can we bring to the party that is distinctive and unique?

All things being equal, for the Linked Data approach to work well, "Not 
Invented Here" is generally a good thing.

Richard - I'll get in touch directly concerning the URL rewrites.

Fine.

Richard
________________________________
From: Richard Light <[log in to unmask]>
To: [log in to unmask]
Sent: Monday, 5 October, 2009 13:43:27
Subject: Re: BC dates [Scanned]

In message 
<[log in to unmask]
.uk>, "Ottevanger, Jeremy" <[log in to unmask]> writes
> Nice one Nick, that's a brilliant idea. Obviously it's pretty much 
impossible to get complete consensus on start/end date (or even 
existence) of all periods, especially those that vary from place to 
place, but something like this is still really useful.

That's my one reservation about this approach.  Nick's thesaurus entry 
hard-wires a specific date range into the definition of e.g. "Jurassic".

An ideal approach (IMHO) would abstract out the _concept_ of "Jurassic", 
and then allow assertions to be made about that concept.  This approach 
would accommodate multiple opinions about date ranges, as well as 
geographically-specific variants.

> I wonder if it could be held in a collaborative environment of some 
sort.

Something like the Geonames [1] model, perhaps?

> -----Original Message-----
> From: Museums Computer Group [mailto:[log in to unmask]] On Behalf Of 
Nicholas Crofts
> Sent: 04 October 2009 01:10
> To: [log in to unmask]
> Subject: Re: [MCG] BC dates [Scanned]
>
> The CIDOC conference in Santiago has just finished. One of things we 
were talking about was a thesaurus of period names that gives start/end 
time intervals. A lot periods require BCE dates. Geological periods 
obviously won't fit into the four-digit year ISO standard, so this isn't 
ISO compatible.
>
> I've been working on an experimental RESTful webservice version that 
provides data about period names in SKOS format (example below for the 
term "Jurassic"). This is intended to be machine-readable, so it may 
look a bit complicated if you're not familiar with SKOS. The service 
accepts either 'label' or 'id' as a parameter. The label can contain 
wildcards '%'. The top term is "Eternity".
>
>
> The SKOS "prefLabel" tag contains the period name, the "definition" 
tag contains the numerical time interval while the "scopeNote" contains 
a more human friendly version of the interval. Most of the period names, 
scopeNotes, etc. are in both French and English.
>
> I'd be delighted to have any feedback on this.

Some suggestions:

1. It would be useful to include a link to the Dbpedia concept 
"Jurassic". Resolving this link gives you the name of the period and a 
definition in many languages, a list of fossil groups found in this 
period, etc.

2. While your dates are numeric, they aren't particularly 
machine-processible.  Wouldn't it be better to have separate start- and 
end-dates, and a duration?  In fact, you could use Christian-Emil Ore's 
date-range algebra [2] to denote the range of possible start-dates and 
end-dates, using CRM notation

3. As well as the SKOS thesaurus-like relations between periods, 
wouldn't it be useful to have CRM-like relations ("contains", "falls 
within") to assert their temporal relationships?  (CRM doesn't seem to 
offer "precedes" and "follows", which would be handy for chaining 
contiguous periods together.)

4. It would be nice if your resource was a bit closer to the Linked Data 
model, with simpler URLs being used for each concept (e.g.

http://www.open-world.ch/thesaurus/chrono/3185454
instead of
http://www.open-world.ch/restapi/V2/thesaurus/chrono.php?id=3185454)

This makes them easier for others to quote.  You would need a bit of 
server-side URL rewriting to support this approach.

Richard

[1] http://en.wikipedia.org/wiki/GeoNames
[2] http://cidoc2009.cl/images/documentos/abstracts.pdf, p16-17

-- Richard Light

****************************************************************
For mcg information visit the mcg website at
http://www.museumscomputergroup.org.uk
To manage your subscription to this email list visit
http://www.museumscomputergroup.org.uk/email.shtml
****************************************************************




>
>****************************************************************
>For mcg information visit the mcg website at
>http://www.museumscomputergroup.org.uk
>To manage your subscription to this email list visit
>http://www.museumscomputergroup.org.uk/email.shtml
>****************************************************************
>No virus found in this incoming message.
>Checked by AVG - www.avg.com
>Version: 8.5.409 / Virus Database: 270.14.3/2414 - Release Date: 
>10/04/09 18:42:00

-- 
Richard Light

****************************************************************
For mcg information visit the mcg website at
http://www.museumscomputergroup.org.uk
To manage your subscription to this email list visit
http://www.museumscomputergroup.org.uk/email.shtml
****************************************************************