Jon,
I'd be interested in NYPL joining the discussion.
Thanks,
David
*David Lowe | The New York Public Library**Specialist II, Photography
Collection*
*Photographers' Identities Catalog <http://pic.nypl.org>*
On Wed, Aug 23, 2017 at 1:18 PM, Jon Thristan <
[log in to unmask]> wrote:
> Hi
>
>
>
> Interesting to read everyone’s ideas about linked data! We’re very keen to
> find out more about your requirements in this area, to input into TMS
> development. To this end, please would you email me
> [log in to unmask] if you’d be interested in discussing
> further, and possibly joining a small group of people to jointly develop a
> set of requirements? Once we have a set of agreed requirements it would
> also be great for the same group to review and comment on specifications
> for TMS development, to help ensure that they meet your needs. The aim
> would be to incorporate the new functionality into the next couple of
> releases of TMS.
>
>
>
> Best wishes
>
> Jon
>
>
>
> *From:* The Museum System (TMS) Users [mailto:[log in to unmask]]
> *On Behalf Of *Shepherd, Rupert
> *Sent:* 23 August 2017 15:36
>
> *To:* [log in to unmask]
> *Subject:* Re: Adding VIAF and other linked data references to
> Constituents
>
>
>
> An elegant solution that I’ll bear in mind! I have my reservations about
> using Text Entries in the absence of Alternate Numbers, and this may be a
> way to avoid them (plus of course – what is a LOD URI, if not an Attribute?)
>
>
>
> Best wishes
>
>
>
> Rupert
>
>
>
> *From:* The Museum System (TMS) Users [mailto:[log in to unmask]
> <[log in to unmask]>] *On Behalf Of *Cathryn Goodwin
> *Sent:* 23 August 2017 15:33
> *To:* [log in to unmask]
> *Subject:* Re: Adding VIAF and other linked data references to
> Constituents
>
>
>
> Yes, that’s correct – a fudge to get out of the thesaurus to other lod
> resources….
>
>
>
> *From:* The Museum System (TMS) Users [mailto:[log in to unmask]
> <[log in to unmask]>] *On Behalf Of *Shepherd, Rupert
> *Sent:* Wednesday, August 23, 2017 10:31 AM
> *To:* [log in to unmask]
> *Subject:* Re: Adding VIAF and other linked data references to
> Constituents
>
>
>
> Cathryn, thanks. The ‘Is related to’ Attributes are interesting – it looks
> from your example as though you have a Thesaurus XRefs record, but with no
> actual link to the thesaurus, and the URI in Remarks instead (needing to be
> parsed out as ‘text following a semi-colon’). Am I right?
>
>
>
> 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 *Cathryn Goodwin
> *Sent:* 23 August 2017 15:20
> *To:* [log in to unmask]
> *Subject:* Re: Adding VIAF and other linked data references to
> Constituents
>
>
>
> Here at Princeton we are actively cataloguing with linked data in mind –
> adding links to altnums in constituents (viaf, ULAN, LCNames) and
> bibliography (worldcat, jstor, etc), as well as a constructed ‘is related
> to’ attribute, where we link to all kinds of outside persistent resources
> for subjects depicted or referred to in our objects.
>
>
>
>
>
>
>
> We use the map reference field in geography for georeference links to
> geonames.
>
>
>
> Best,
>
> Cathryn
>
>
>
> *Manager, Collections Information and Access*
>
> *Princeton University Art Museum*
>
> *609.258.9374 <(609)%20258-9374>*
>
> *[log in to unmask] <[log in to unmask]>*
>
>
>
>
>
>
>
> *From:* The Museum System (TMS) Users [mailto:[log in to unmask]
> <[log in to unmask]>] *On Behalf Of *David Lowe
> *Sent:* Wednesday, August 23, 2017 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.
>
> 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.