Well, I'm not really trying to give anybody driving directions to a 100
year old photo studio, so for my purposes "close enough" is good enough.
I'm more interested in visualizing the general distribution of these
locations. The bigger problems for me are that streets have been
renumbered, renamed, or disappeared altogether. So at the street/address
level, one should take these points with a grain of salt. But a more robust
handling of geographies (whether in Constituent Addresses, or Object
Locationa, etc.) could allow one to be as specific as one wants/needs/is
able.


*David Lowe | The New York Public Library**Specialist II, Photography
Collection*

*Photographers' Identities Catalog <http://pic.nypl.org>*

On Wed, Aug 23, 2017 at 10:26 AM, Brad Millen <[log in to unmask]> wrote:

> Hi:
>
>
>
> Be aware of limitations using Geographic coordinates for locations. All
> coordinates must have a Geodetic Datum. If not, you get what is called
> “Datum Shift”. A NAD27 Decimal Latitude is slightly different than a NAD83
> or even a WGS84. You can correct this but a lat and long may not plot
> properly for an address if a NAD83 is used on Google Maps, which is WGS84.
> A street address may be a block away and the distance from the equator will
> make that shift worse.
>
>
>
>
>
>
>
>
>
> *From:* The Museum System (TMS) Users [mailto:[log in to unmask]]
> *On Behalf Of *David Lowe
> *Sent:* 2017-08-23 10:14 AM
>
> *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.
>
> [image: Out of the Depths: The Blue Whale Story. Du fond des mers: La
> baleine bleue] <https://www.rom.on.ca/blue-whale>
>
> The ROM gratefully acknowledges the financial support of the Ontario
> Government for this Ontario150 initiative.
>
> *Le ROM tient à remercier le gouvernement de l’Ontario du soutien
> financier qu’il apporte à cette initiative du Musée à l’occasion
> d’Ontario150.*
> 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.