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
From: The Museum System (TMS) Users [mailto:[log in to unmask]
SI.EDU] 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 ConstituentsTo unsubscribe, send an email to [log in to unmask] with the following commands in the body of the email:
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
Tel: +44 (0)20 7747 5921
From: The Museum System (TMS) Users [mailto:[log in to unmask]
SI.EDU ] 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]
SI.EDU ] 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]
SI.EDU ] 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
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.
signoff TMSUSERS
// eoj
You will receive a confirmation that your subscription has been removed.