That's such a good point regarding the location authority.  What museum
isn't either undergoing building renovations or planning them?!

I'm currently trying to figure out the best way to deal with this. I hate
having hundreds of gallery locations in the location authority that no
longer physically exist, but I also like to preserve the location histories
of the objects. I'd like to be able to record the fact the one gallery
space in our building has been completely redesigned twice in the past
twenty years but I haven't come up with a good system yet.





Nicola Astles
Museum Content and Technology Administrator
New-York Historical Society
170 Central Park West
New York, New York 10024
[log in to unmask]
212-873-3400 x338

On Wed, Aug 23, 2017 at 10:20 AM, Shepherd, Rupert <
[log in to unmask]> wrote:

> Oooh, yes! I have some thoughts on the Locations module anyway, which GS
> are aware of – I have a problem with it not being time-bound, i.e.:
>
> ·         A space is (more-or-less) constant (and as David says, would
> have coordinates)
>
> ·         A space’s properties (name, description, security level, etc.)
> will change from time to time as buildings are reconfigured, rooms are
> re-named, etc., etc.
>
> ·         For a thorough historical record, objects need to be attached
> to a particular occurrence of a space’s properties, rather than to a space
>
> – which of course would mean unpicking the entire data structure in that
> part of TMS. But if there are any takers ….
>
>
>
> Best wishes
>
>
>
> Rupert
>
>
>
> *Rupert Shepherd, PhD FSA*
>
> Collection Information Manager
>
> [log in to unmask]
>
> Tel: +44 (0)20 7747 5921
>
>
>
> *From:* The Museum System (TMS) Users [mailto:[log in to unmask]]
> *On Behalf Of *David Lowe
> *Sent:* 23 August 2017 15:14
>
> *To:* [log in to unmask]
> *Subject:* Re: Adding VIAF and other linked data references to
> Constituents
>
>
>
> I think that sounds great. And while we're at it, every table describing a
> physical location should have a field for geo coordinates. I've had to
> commandeer the Remarks field for over 200,000 constituent addresses
> <http://pic.nypl.org/map/?address.AddressTypeID=*&address.CountryID=*&bbox=*&Nationality=*&gender.TermID=*&process.TermID=*&role.TermID=*&format.TermID=*&biography.TermID=*&collection.TermID=*&DisplayName=*&Date=*&mode=2>
> .
>
>
>
> On Wed, Aug 23, 2017 at 9:39 AM Hilde Bøe <[log in to unmask]>
> wrote:
>
> Dear Rupert, dear colleagues,
>
>
>
> The Munch Museum’s  plans for collection presentation online include
> publishing our data as linked and open data, so we would definitely support
> a request for TMS enhancements in future versions along the lines
> described here.
>
>
>
> Thanks and best,
>
>
>
>
> *HILDE BØE *Digital samlingsforvalter | Digital Collection Manager
>
>
>
> *MUNCH**MUSEET | **THE* *MUNCH **MUSEUM*
>
> +47 97787931 <+47%20977%2087%20931>
>
>
>
> *From:* The Museum System (TMS) Users [mailto:[log in to unmask]]
> *On Behalf Of *Shepherd, Rupert
> *Sent:* Tuesday, August 22, 2017 12:59 PM
>
>
> *To:* [log in to unmask]
> *Subject:* Re: Adding VIAF and other linked data references to
> Constituents
>
>
>
> Dear colleagues
>
>
>
> Apologies for resurrecting this thread after a couple of months, but I’m
> interested in expanding the discussion beyond VIAF for Constituents to the
> storage of linked data URIs more generally.
>
>
>
> AltNums, as already being used by many for this purpose and recommended by
> Danielle, are available in the following modules:
>
> ·        Bibliography
>
> ·        Constituents
>
> ·        Objects
>
> ·        Sites
>
>
>
>
>
>
> However, we are currently looking at deriving comprehensive linked data
> from TMS (where we can), and will therefore be minting our own
> dereferenceable / cool URIs and associating them with more than these
> particular entities. I’d like these to be stored in TMS so that they’re
> accessible to any consuming systems. At the moment, I’m thinking of:
>
> ·        Events
>
> ·        Exhibitions
>
> ·        Media
>
> These don’t currently link to AltNums, and I’d welcome advice on where we
> might store our own URIs and, indeed, external ones (at least for Events
> and Exhibitions – cf., e.g., https://www.wikidata.org/wiki/Q4797115). At
> the moment, I’m thinking of Text Entries, at least for now – though in the
> case of Media, these don’t link to individual renditions, but to
> MediaMaster only – and we have stored different versions of text files
> (e.g. display labels) as separate renditions, so would want to record a URI
> against a rendition, rather than a media master record).
>
>
>
> And of course there’s the thesaurus, where it seems to make sense to
> record URIs simply as further terms.
>
>
>
> Going forward, of course, it’d be useful to have AltNums more widely
> available across TMS – would anyone else like to join me in requesting this
> as an enhancement in future versions? This could go quite far – for
> example, we might want to consider an accession as an a event that needs
> its own ID (thinking in terms of the CIDOC-CRM).
>
>
>
> With best wishes
>
>
>
> Rupert
>
>
>
> *Rupert Shepherd, PhD FSA*
>
> Collection Information Manager
>
> [log in to unmask]
>
> Tel: +44 (0)20 7747 5921
>
>
>
> *From:* The Museum System (TMS) Users [mailto:[log in to unmask]
> <[log in to unmask]>] *On Behalf Of *Danielle Uchitelle
> *Sent:* 08 June 2017 14:19
> *To:* [log in to unmask]
> *Subject:* Re: Adding VIAF and other linked data references to
> Constituents
>
>
>
> At Gallery Systems, our recommended best practice for leveraging linked
> data such as VIAF and ULAN is to use the Alternate Number field to hold
> this information, as Jeff, Emmanuelle, and others have already said.
>
>
>
> Beginning with TMS 2016R2, the Alternate Number field can include a URI
> that is dereferenceable (resolvable) to any linked web resource, so that
> clicking on the link within the TMS record immediately opens the associated
> web page in a browser:
>
>
>
> If you are using eMuseum to publish your collection information, these
> linked data references will allow you to include canonic information from
> the linked authority in your museum’s collection website.  I’ll be hosting
> a webinar later this summer to demonstrate this feature using eMuseum 5.1,
> the latest version supporting linked open data.
>
>
>
> Regarding field lengths, an argument can be made for entering only the
> root ID (in the above example, the ULAN ID 500017300) rather than the
> entire URL (http://vocab.getty.edu/ulan/500017300).  This would assure
> that the linking ID would fit easily within the 450 character limit of this
> field, and would also make it easier to manage in cases where a linked web
> server changed URL addresses without any change to the URI, although this
> should not happen often.  Entering the ID without the full URL would still
> allow linking data using eMuseum but would mean that you wouldn’t have a
> dereferenceable URL to click on inside TMS.  In practice, I’ve sometimes
> done both in the same record, using the Alternate Number description field
> to denote separate rows for ULAN ID and ULAN Subject URL.
>
>
>
> Best,
>
> Danielle Uchitelle
>
>
> ------------------------------
>
> Danielle Uchitelle *| *Chief Operating Officer
>
> [log in to unmask] *|* 646.733.2239 x264 <(646)%20733-2239>
>
> *GallerySystems | *www.gallerysystems.com
>
>
>
>
>
>
>
> *From:* The Museum System (TMS) Users [mailto:[log in to unmask]
> <[log in to unmask]>] *On Behalf Of *Delmas-Glass, Emmanuelle
> *Sent:* Wednesday, June 7, 2017 3:55 PM
> *To:* [log in to unmask]
> *Subject:* Re: Adding VIAF and other linked data references to
> Constituents
>
>
>
> Same as Jeff: Constituent alternate numbers – using the full VIAF URL as
> the number and with ULAN chosen from the drop down as source of the data.
>
> Emmanuelle
>
>
>
> Emmanuelle Delmas-Glass
>
> Collections Data Manager
>
> Yale Center for British Art
>
> 203-410-4069 <(203)%20410-4069>
>
>
>
>
>
>
> On Jun 7, 2017, at 19:27, Smith, Jeffrey <[log in to unmask]> wrote:
>
> Constituent alternate numbers – using the full VIAF URL as the number.
>
>
>
> *From:* The Museum System (TMS) Users [mailto:[log in to unmask]
> <[log in to unmask]>] *On Behalf Of *Welsh, Sylvia C.
> *Sent:* Wednesday, June 07, 2017 11:20 AM
> *To:* [log in to unmask]
> *Subject:* Adding VIAF and other linked data references to Constituents
>
>
>
> Hello TMS list,
>
>
>
> I was wondering where in your Constituents Module you add information from
> VIAF, etc.? We are looking to start adding that data and were wondering if
> anyone had suggestions for best practices?
>
>
>
> Thank you,
>
>
>
> Sylvia,
>
>
>
> _____________________________
>
> *Sylvia Welsh, MS LIS, CSI, LEED AP BD+C*
>
>
>
> Harvard Property Information Resource Center
>
> 1350 Massachusetts Avenue, 547
>
> Cambridge, MA 02138
>
> T 617-496-8275 <(617)%20496-8275>  F 617-495-0559 <(617)%20495-0559>
>
>
>
> To unsubscribe, send an email to [log in to unmask] with the
> following commands in the body of the email:
>
> signoff TMSUSERS
>
> // eoj
>
> You will receive a confirmation that your subscription has been removed.
>
> To unsubscribe, send an email to [log in to unmask] with the
> following commands in the body of the email:
>
> signoff TMSUSERS
>
> // eoj
>
> You will receive a confirmation that your subscription has been removed.
>
> To unsubscribe, send an email to [log in to unmask] with the
> following commands in the body of the email:
>
> signoff TMSUSERS
>
> // eoj
>
> You will receive a confirmation that your subscription has been removed.
>
> To unsubscribe, send an email to [log in to unmask] with the
> following commands in the body of the email:
>
> signoff TMSUSERS
>
> // eoj
>
> You will receive a confirmation that your subscription has been removed.
>
> To unsubscribe, send an email to [log in to unmask] with the
> following commands in the body of the email:
>
> signoff TMSUSERS
>
> // eoj
>
> You will receive a confirmation that your subscription has been removed.
>
> To unsubscribe, send an email to [log in to unmask] with the
> following commands in the body of the email:
>
> signoff TMSUSERS
>
> // eoj
>
> You will receive a confirmation that your subscription has been removed.
>
> To unsubscribe, send an email to [log in to unmask] with the
> following commands in the body of the email:
>
> signoff TMSUSERS
>
> // eoj
>
> You will receive a confirmation that your subscription has been removed.
> To unsubscribe, send an email to [log in to unmask] with the
> following commands in the body of the email:
>
> signoff TMSUSERS
>
> // eoj
>
> You will receive a confirmation that your subscription has been removed.
>

-- 
 <http://4thfloor.nyhistory.org/>

To unsubscribe, send an email to [log in to unmask] with the following commands in the body of the email:

     signoff TMSUSERS

     //  eoj


You will receive a confirmation that your subscription has been removed.