Thanks to everyone who’s replied re the linked data group. I’ll email everyone individually to confirm!

 

Best wishes

Jon

 

From: The Museum System (TMS) Users [mailto:[log in to unmask]] On Behalf Of Cathryn Goodwin
Sent: 23 August 2017 18:25
To: [log in to unmask]
Subject: Re: Adding VIAF and other linked data references to Constituents

 

Same here Jon.

 

Thanks

cathryn

 

From: The Museum System (TMS) Users [mailto:[log in to unmask]] On Behalf Of Delmas-Glass, Emmanuelle
Sent: Wednesday, August 23, 2017 1:24 PM
To: [log in to unmask]
Subject: Re: Adding VIAF and other linked data references to Constituents

 

Hi Jon,

 

Sign me up for the LOD group!

 

Thanks. 

Emmanuelle 

 

Emmanuelle Delmas-Glass

Collections Data Manager

Yale Center for British Art

203-410-4069

 

 


On Aug 23, 2017, at 13:18, 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]] 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]] 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]] 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.

 

<image001.png> 

 

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

[log in to unmask]

 

 

 

From: The Museum System (TMS) Users [mailto:[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.

 

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

 

MUNCHMUSEET | THE MUNCH MUSEUM

+47 97787931

 

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]] 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

GallerySystems | www.gallerysystems.com

 

 

 

From: The Museum System (TMS) Users [mailto:[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

 

 


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]] 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  F 617-495-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.

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.