Exhibition information

[Frankie Roberto]

Hi all,

My take-home number #8 from the mw2008 conference was to try and open
up more exhibition/gallery data (coz it ought to be simpler than
objects, and perhaps more interesting/useful).

So I'm putting my money where my mouth is by building an exhibitions
feed for the Science Museum, which will be available in the next
couple of days.

Before I do that, I just thought I'd pick people's brains here about
what information should be included (I'm resisting the word 'schema').

My current plan is:

id (integer, auto-assigned)
Name (text, max 150 chars, required)
Opened on (date, optional)
Closed on (date, optional)
Closed? (yes/no, optional)
Website (uri, optional)
Admission fee? (yes/no)*

* note: if there's an admission fee for the museum, but nothing extra
for the exhibition/gallery, I'm putting it in as 'no'

Are exhibitions are implied to be still open if 'Closed?' is null
unless 'closed on' is in the past or 'opened on' is in the future.
(The 'closed?' parameter allows us to capture historical exhibitions
where we don't know either the opening or closing dates).

Anything I'm missing? I'm deliberately leaving out more descriptive
information like a description, or subjects/tags, as that kind of data
is more subjective and can be added by users, etc. Location is
implied to be the 'Science Museum', and trying to specify exactly
where in the museum is too complicated.

Frankie

[Mike Ellis]

I'd still be tempted to provide "institutional descriptive" data like description, lead image. Also if you think outside the box (ie. possibility for a global "exhibition schema" - there, I used the word...) then how about institution name/id plus location (lat/long or maybe even WOEID - see http://developer.yahoo.com/geo/). Also...gallery name? price? (thinking about the potential interest of this in a historical sense...)...?

--
________________________

mob: + 00 44 7810 487 423
web: electronicmuseum.org.uk
email: mike....@gmail.com
skype: dmj_ellis

[Frankie Roberto]

Mike wrote:
> I'd still be tempted to provide "institutional descriptive" data like
> description, lead image.

I'm wary of institutional descriptions for a number of reasons:

a) You then have to decide if you allow markup in the description
fields, and if so, what type (HTML?/a subset of HTML?/XHTML?/
Textile?).
b) You then open the floodgates to all sorts of other non core
information, such as sponsors, lead curators, a marketing blurb, and
so on - all good information, but this can exist outside of the core
scheme of data to be aggregated.

> Also if you think outside the box (ie. possibility
> for a global "exhibition schema" - there, I used the word...) then how about
> institution name/id plus location (lat/long or maybe even WOEID - seehttp://developer.yahoo.com/geo/).

I agree that there should be a mechanism to link the exhibition/
gallery to an institution, but the institution information should be
defined elsewhere (possibly using a schema derived from hCard?). For
the time being, the institution will have to be non-programmatically
implied from the feed location.

> Also...gallery name?

What do you mean here? Isn't this just the 'name' field below?

> price?

Possibly, but quite complicated to model (think of the different
combinations of ticket types, concessions, currencies, peak/off-
peak). Quite a headache - so I'm ignoring for the time being!

> (thinking about the potential interest of this in a historical sense...)...?

Yeah, me too. I'm going to do some research in the [paper] files to
see how far back I can get the exhibition info.

Note that I'm using 'exhibition' as an inclusive term to encompass
permanent galleries, and even small, named displays. I did consider a
parent_id reference for when there are galleries within galleries
(which happens more than you'd think) - but that seems too
conceptually confusing and too much an edge case to be worth bothering
with.

Not sure how to cope with galleries that are renamed, but otherwise
stay the same, either. Going to ignore those too unless anyone has any
bright (and simple) solutions.

Frankie

[Frankie Roberto]

Okay, the feed is here: http://api.sciencemuseum.org.uk/exhibitions/
(Attribute names/locations may change).

I'm slowly inputting data.

Let me know if you have any requests for alternative outputs (CSV?
json?)

Would love to see other museums opening up this kind of data feed
too...

Frankie

[Mike Ellis]

Cool..

Can you add it to the mashedmuseum directory when you get a sec?

ta!

Mike

[Ridge, Mia]

Off the top of my head, can you have a core schema and optional
extensions for all the extra bits?

And it's getting relational, but if you stored information about a
gallery 'entity', you could have a link that presents the history of it
(name changes, closures, redevelopments) while still presenting the
basic info in the exhibition record. Museums change organisational
structure/branding/names etc more than they change the shape of a
physical space.

A base price (non-conc adult on a Saturday) would be useful.

[Frankie Roberto]

On May 29, 6:07 pm, "Ridge, Mia" <mri...@museumoflondon.org.uk> wrote:

> Off the top of my head, can you have a core schema and optional
> extensions for all the extra bits?

Well you COULD, but then it starts getting complicated, and you'd have
to have namespaces or something, and http://microformats.org/wiki/namespaces-considered-harmful,
etc etc.

On the other hand, the core schema is pretty small, and all the fields
are optional (perhaps bar 'name'), so extra bits could be easily added
(preferably after building a consensus first).

> And it's getting relational, but if you stored information about a
> gallery 'entity', you could have a link that presents the history of it
> (name changes, closures, redevelopments) while still presenting the
> basic info in the exhibition record. Museums change organisational
> structure/branding/names etc more than they change the shape of a
> physical space.

I agree it'd be useful to be able to cope with name changes, closures
and redevelopments, but it's tricky to design a format to capture that
data and all the various nuances in a simple way.

There's perhaps a benefit in encouraging clarity of thinking by saying
that if a gallery changes, it has to either be a new gallery (with a
new id, and a new opened_on), or be the same gallery but with changed
attributes (eg the name changes but the id and the original opened_on
date stays the same).

In the latter case, there's currently no way to store the old name.
There could be an 'previous_names' field as a comma-delinated list of
strings, or we could just abandon this data and leave it to the richer
non-machine-readable 'description' style data.


In other news, I now have 84 exhibitions & galleries in the Science
Museum feed (http://api.sciencemuseum.org.uk/exhibitions/), which
includes all exhibitions I could easily find information about, going
back around 10 years.

I've also added a json output: http://api.sciencemuseum.org.uk/exhibitions/?output=json
...which also accepts a callback paramater:
http://api.sciencemuseum.org.uk/exhibitions/?output=json&callback=myFunction

Frankie

[Ridge, Mia]

> On May 29, 6:07 pm, "Ridge, Mia" <mri...@museumoflondon.org.uk> wrote:
>
> > Off the top of my head, can you have a core schema and optional
> > extensions for all the extra bits?
>
> Well you COULD, but then it starts getting complicated, and
> you'd have to have namespaces or something, and
> http://microformats.org/wiki/namespaces-considered-harmful,
> etc etc.

I'm not sure I follow? I think it might be more simple than you think
but we're probably approaching it from different angles.

Anyway, the best way to work this out is with real examples, and real
user requirements. Oh, and real spare time, of which sadly personally I
have none! But I'll follow it with interest in the imaginary spare time
I do have.

cheers, Mia

[Ridge, Mia]

Actually, this page is pretty useful: Freebase Data Modelling Guide
http://www.freebase.com/view/guid/9202a8c04000641f80000000045637f3