Hello everyone. I am trying to understand how CSpace does things. I see we can create "material resources" where we store images for objects. And I see that I can link this image to all other "processes". Suppose I did an "intake" and I created a "material resource" and I linked it. Then I did a "acquisition" for the same object.. again I linked the image to this process. So with every process, I will need to link the image to each process? this can be pretty tedious. I was thinking that I will make "cataloging" the "main" record, then attach all other records to it. Meaning, always start by creating a catalog record. This way all links to images will be centralized and I will always know that images are linked to cataloging records. But this will force me to use "cataloging" for all objects, even when not needed. Is this a good practice? Is there a better way to accomplish what I am trying to do? Thank you everyone. Toni.

Toni, Thanks for the note. Can you please let us know what types of materials you have in your collection, and what your goals are for CollectionSpace? It will help us figure out the best way to get them organized. Thanks, Megan Megan Forbes CollectionSpace Program Manager megan.forbes@lyrasis.org 917.267.9676 Cell meganbforbes Skype ________________________________________ From: Talk <talk-bounces@lists.collectionspace.org> on behalf of toni hanna <toni@creyasoft.com> Sent: Thursday, March 31, 2016 4:14 AM To: talk@lists.collectionspace.org Subject: [Talk] CS Linking Best Practice Hello everyone. I am trying to understand how CSpace does things. I see we can create "material resources" where we store images for objects. And I see that I can link this image to all other "processes". Suppose I did an "intake" and I created a "material resource" and I linked it. Then I did a "acquisition" for the same object.. again I linked the image to this process. So with every process, I will need to link the image to each process? this can be pretty tedious. I was thinking that I will make "cataloging" the "main" record, then attach all other records to it. Meaning, always start by creating a catalog record. This way all links to images will be centralized and I will always know that images are linked to cataloging records. But this will force me to use "cataloging" for all objects, even when not needed. Is this a good practice? Is there a better way to accomplish what I am trying to do? Thank you everyone. Toni. _______________________________________________ Talk mailing list Talk@lists.collectionspace.org http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org

Megan, my mistake: I wrote "material resources" when I was supposed to write "media resources". Apologies. I do not have a collection. I am an IT person working for an IT consulting company who was asked to evaluate CSpace as a whole. I am just trying to understand how CSpace works, and I am exploring the possibilities. Thanks. On Fri, April 1, 2016 10:49 am, Megan Forbes wrote: > Toni, > > > Thanks for the note. Can you please let us know what types of materials > you have in your collection, and what your goals are for CollectionSpace? > It will help us figure out the best way to get them organized. > > > Thanks, > Megan > > > > Megan Forbes > CollectionSpace Program Manager > megan.forbes@lyrasis.org 917.267.9676 Cell > meganbforbes Skype > > > > ________________________________________ > From: Talk <talk-bounces@lists.collectionspace.org> on behalf of toni > hanna <toni@creyasoft.com> Sent: Thursday, March 31, 2016 4:14 AM > To: talk@lists.collectionspace.org > Subject: [Talk] CS Linking Best Practice > > > Hello everyone. > I am trying to understand how CSpace does things. I see we can create > "material resources" where we store images for objects. And I see that I > can link this image to all other "processes". Suppose I did an "intake" and > I created a "material resource" and I linked > it. Then I did a "acquisition" for the same object.. again I linked the > image to this process. So with every process, I will need to link the > image to each process? this can be pretty tedious. I was thinking that I > will make "cataloging" the "main" record, then attach all other records to > it. Meaning, always start by creating a catalog record. This way all links > to images will be centralized and I will always know that images are > linked to cataloging records. But this will force me to use "cataloging" > for all objects, even when not needed. Is this a good practice? > Is there a better way to accomplish what I am trying to do? > Thank you everyone. > Toni. > > > > _______________________________________________ > Talk mailing list > Talk@lists.collectionspace.org > http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspa > ce.org >

Hi Toni, >From a data modeling point of view, I think the correct way to do it with an out-of-the-box installation is to make Cataloging the main record, and link other procedures to it. A better name for "Cataloging" is "Object." The other procedures, like Intake and Acquisition, all refer to objects. So if you have an intake, you should create a Cataloging record for each object in the intake, and relate the Intake record to the Cataloging records. (You might also set the Identification Number on each Cataloging record to have a prefix indicating that it is in the intake stage). If you have an image of the object, you would create a Media Handling record, and link it to the Cataloging record, not the Intake. This way you have properly normalized data. You might also have an image of the intake itself, not the object. A common case for this is a museum that is moving from a paper-based system to CollectionSpace. In that case, they might scan the paper intake record, and store that as a Media Record related to the Intake record -- not the Cataloging record, since the image really is of the intake, not the object. That said, each museum has a workflow that they're able to accommodate, and maybe what I've described is more work than they're willing to do. At that point they could customize CSpace to create a workflow that works for them, or hire a consultant like yourself to do those customizations. For example, for one museum we moved some of the fields on the Acquisition record onto the Cataloging record, so that they don't have to create Acquisition records at all. It means that every object is a separate acquisition. They can't have acquisitions that contain more than one object. But that's how they were already thinking of acquisitions, so it worked for them, and it streamlines the process. Ray On Sat, Apr 2, 2016 at 4:52 AM, toni hanna <toni@creyasoft.com> wrote: > Megan, my mistake: > I wrote "material resources" when I was supposed to write "media > resources". Apologies. > I do not have a collection. I am an IT person working for an IT consulting > company who was asked to evaluate CSpace as a whole. I am just trying to > understand how CSpace works, and I am exploring the possibilities. > Thanks. > > On Fri, April 1, 2016 10:49 am, Megan Forbes wrote: > > Toni, > > > > > > Thanks for the note. Can you please let us know what types of materials > > you have in your collection, and what your goals are for CollectionSpace? > > It will help us figure out the best way to get them organized. > > > > > > Thanks, > > Megan > > > > > > > > Megan Forbes > > CollectionSpace Program Manager > > megan.forbes@lyrasis.org 917.267.9676 Cell > > meganbforbes Skype > > > > > > > > ________________________________________ > > From: Talk <talk-bounces@lists.collectionspace.org> on behalf of toni > > hanna <toni@creyasoft.com> Sent: Thursday, March 31, 2016 4:14 AM > > To: talk@lists.collectionspace.org > > Subject: [Talk] CS Linking Best Practice > > > > > > Hello everyone. > > I am trying to understand how CSpace does things. I see we can create > > "material resources" where we store images for objects. And I see that I > > can link this image to all other "processes". Suppose I did an "intake" > and > > I created a "material resource" and I linked > > it. Then I did a "acquisition" for the same object.. again I linked the > > image to this process. So with every process, I will need to link the > > image to each process? this can be pretty tedious. I was thinking that I > > will make "cataloging" the "main" record, then attach all other records > to > > it. Meaning, always start by creating a catalog record. This way all > links > > to images will be centralized and I will always know that images are > > linked to cataloging records. But this will force me to use "cataloging" > > for all objects, even when not needed. Is this a good practice? > > Is there a better way to accomplish what I am trying to do? > > Thank you everyone. > > Toni. > > > > > > > > _______________________________________________ > > Talk mailing list > > Talk@lists.collectionspace.org > > > http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspa > > ce.org > > > > > > _______________________________________________ > Talk mailing list > Talk@lists.collectionspace.org > > http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org >

Hi Toni, Just piping up here as a cspace user/implementer at the Oakland Museum of California. We use CSpace with the object(cataloging)-centric way that Ray described, though as he mentioned, it's also convenient to be able to relate different types of records together - for instance, we can create a Valuation procedure for an Acquisition, where an entire accession was purchased or appraised. If it would help your evaluation process to talk to current users, I'd be happy to have a conversation, or answer other questions. Thanks, Al On Mon, Apr 4, 2016 at 5:05 PM, Ray Lee <rhlee@berkeley.edu> wrote: > Hi Toni, > From a data modeling point of view, I think the correct way to do it with > an out-of-the-box installation is to make Cataloging the main record, and > link other procedures to it. A better name for "Cataloging" is "Object." > The other procedures, like Intake and Acquisition, all refer to objects. So > if you have an intake, you should create a Cataloging record for each > object in the intake, and relate the Intake record to the Cataloging > records. (You might also set the Identification Number on each Cataloging > record to have a prefix indicating that it is in the intake stage). If you > have an image of the object, you would create a Media Handling record, and > link it to the Cataloging record, not the Intake. This way you have > properly normalized data. > > You might also have an image of the intake itself, not the object. A > common case for this is a museum that is moving from a paper-based system > to CollectionSpace. In that case, they might scan the paper intake record, > and store that as a Media Record related to the Intake record -- not the > Cataloging record, since the image really is of the intake, not the object. > > That said, each museum has a workflow that they're able to accommodate, > and maybe what I've described is more work than they're willing to do. At > that point they could customize CSpace to create a workflow that works for > them, or hire a consultant like yourself to do those customizations. For > example, for one museum we moved some of the fields on the Acquisition > record onto the Cataloging record, so that they don't have to create > Acquisition records at all. It means that every object is a separate > acquisition. They can't have acquisitions that contain more than one > object. But that's how they were already thinking of acquisitions, so it > worked for them, and it streamlines the process. > > Ray > > > On Sat, Apr 2, 2016 at 4:52 AM, toni hanna <toni@creyasoft.com> wrote: > >> Megan, my mistake: >> I wrote "material resources" when I was supposed to write "media >> resources". Apologies. >> I do not have a collection. I am an IT person working for an IT consulting >> company who was asked to evaluate CSpace as a whole. I am just trying to >> understand how CSpace works, and I am exploring the possibilities. >> Thanks. >> >> On Fri, April 1, 2016 10:49 am, Megan Forbes wrote: >> > Toni, >> > >> > >> > Thanks for the note. Can you please let us know what types of materials >> > you have in your collection, and what your goals are for >> CollectionSpace? >> > It will help us figure out the best way to get them organized. >> > >> > >> > Thanks, >> > Megan >> > >> > >> > >> > Megan Forbes >> > CollectionSpace Program Manager >> > megan.forbes@lyrasis.org 917.267.9676 Cell >> > meganbforbes Skype >> > >> > >> > >> > ________________________________________ >> > From: Talk <talk-bounces@lists.collectionspace.org> on behalf of toni >> > hanna <toni@creyasoft.com> Sent: Thursday, March 31, 2016 4:14 AM >> > To: talk@lists.collectionspace.org >> > Subject: [Talk] CS Linking Best Practice >> > >> > >> > Hello everyone. >> > I am trying to understand how CSpace does things. I see we can create >> > "material resources" where we store images for objects. And I see that I >> > can link this image to all other "processes". Suppose I did an "intake" >> and >> > I created a "material resource" and I linked >> > it. Then I did a "acquisition" for the same object.. again I linked the >> > image to this process. So with every process, I will need to link the >> > image to each process? this can be pretty tedious. I was thinking that I >> > will make "cataloging" the "main" record, then attach all other records >> to >> > it. Meaning, always start by creating a catalog record. This way all >> links >> > to images will be centralized and I will always know that images are >> > linked to cataloging records. But this will force me to use "cataloging" >> > for all objects, even when not needed. Is this a good practice? >> > Is there a better way to accomplish what I am trying to do? >> > Thank you everyone. >> > Toni. >> > >> > >> > >> > _______________________________________________ >> > Talk mailing list >> > Talk@lists.collectionspace.org >> > >> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspa >> > ce.org >> > >> >> >> >> _______________________________________________ >> Talk mailing list >> Talk@lists.collectionspace.org >> >> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org >> > > > _______________________________________________ > Talk mailing list > Talk@lists.collectionspace.org > > http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org > > -- Al Bersch Collections Systems Manager Oakland Museum of California 1000 Oak Street, Oakland, CA 94607 abersch@museumca.org 510-318-8468

That makes a lot of sense, Ray. Thank you for the details. Couple questions: Concerning "we moved some of the fields on the Acquisition record onto the Cataloging record", I have to check the documentation in more detail but in general how would this impact future upgrades of CSpace? Is there a clean way to keep custom code separate from plain CSpace code? "could customize CSpace to create a workflow that works for them", is CSpace built on some workflow engine which facilitates the creation of workflows? or do you mean this generically i.e. to create actual java code? Thank you. Toni. On Mon, April 4, 2016 7:05 pm, Ray Lee wrote: > Hi Toni, > From a data modeling point of view, I think the correct way to do it with > an out-of-the-box installation is to make Cataloging the main record, and > link other procedures to it. A better name for "Cataloging" is "Object." > The other procedures, like Intake and Acquisition, all refer to objects. > So > if you have an intake, you should create a Cataloging record for each > object in the intake, and relate the Intake record to the Cataloging > records. (You might also set the Identification Number on each Cataloging > record to have a prefix indicating that it is in the intake stage). If > you have an image of the object, you would create a Media Handling record, > and link it to the Cataloging record, not the Intake. This way you have > properly normalized data. > > You might also have an image of the intake itself, not the object. A > common case for this is a museum that is moving from a paper-based system > to CollectionSpace. In that case, they might scan the paper intake record, > and store that as a Media Record related to the Intake record -- not the > Cataloging record, since the image really is of the intake, not the > object. > > That said, each museum has a workflow that they're able to accommodate, > and maybe what I've described is more work than they're willing to do. At > that point they could customize CSpace to create a workflow that works for > them, or hire a consultant like yourself to do those customizations. For > example, for one museum we moved some of the fields on the Acquisition > record onto the Cataloging record, so that they don't have to create > Acquisition > records at all. It means that every object is a separate acquisition. They > can't have acquisitions that contain more than one object. But that's > how they were already thinking of acquisitions, so it worked for them, and > it streamlines the process. > > Ray > > > > On Sat, Apr 2, 2016 at 4:52 AM, toni hanna <toni@creyasoft.com> wrote: > > >> Megan, my mistake: >> I wrote "material resources" when I was supposed to write "media >> resources". Apologies. I do not have a collection. I am an IT person >> working for an IT consulting company who was asked to evaluate CSpace as >> a whole. I am just trying to understand how CSpace works, and I am >> exploring the possibilities. Thanks. >> >> >> On Fri, April 1, 2016 10:49 am, Megan Forbes wrote: >> >>> Toni, >>> >>> >>> >>> Thanks for the note. Can you please let us know what types of >>> materials you have in your collection, and what your goals are for >>> CollectionSpace? >>> It will help us figure out the best way to get them organized. >>> >>> >>> >>> Thanks, >>> Megan >>> >>> >>> >>> >>> Megan Forbes >>> CollectionSpace Program Manager >>> megan.forbes@lyrasis.org 917.267.9676 Cell meganbforbes Skype >>> >>> >>> >>> ________________________________________ >>> From: Talk <talk-bounces@lists.collectionspace.org> on behalf of toni >>> hanna <toni@creyasoft.com> Sent: Thursday, March 31, 2016 4:14 AM To: >>> talk@lists.collectionspace.org Subject: [Talk] CS Linking Best >>> Practice >>> >>> >>> >>> Hello everyone. >>> I am trying to understand how CSpace does things. I see we can create >>> "material resources" where we store images for objects. And I see that >>> I >>> can link this image to all other "processes". Suppose I did an >>> "intake" >>> >> and >>> I created a "material resource" and I linked >>> it. Then I did a "acquisition" for the same object.. again I linked >>> the image to this process. So with every process, I will need to link >>> the image to each process? this can be pretty tedious. I was thinking >>> that I will make "cataloging" the "main" record, then attach all other >>> records >> to >>> it. Meaning, always start by creating a catalog record. This way all >> links >>> to images will be centralized and I will always know that images are >>> linked to cataloging records. But this will force me to use >>> "cataloging" >>> for all objects, even when not needed. Is this a good practice? Is >>> there a better way to accomplish what I am trying to do? Thank you >>> everyone. Toni. >>> >>> >>> >>> >>> _______________________________________________ >>> Talk mailing list >>> Talk@lists.collectionspace.org >>> >>> >> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collection >> spa >>> ce.org >>> >> >> >> >> _______________________________________________ >> Talk mailing list >> Talk@lists.collectionspace.org >> >> >> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collection >> space.org >> >

Thank you for your comments, Al. I appreciate your willingness to help, and will surely need it as we go forward. Concerning linking, my main concern (from an IT guy's perspective) is that if the linking is not somehow controlled for a specific target implementation (either procedurally or through some code), these links could get out of hand and users may end up having to jump from one procedure to another, trying to find linked information. >From the readings, I do realize that this design is intentional to keep the product flexible and that's a great design goal, but I still feel it needs to be managed in some manner. Am I off in my thinking? On Tue, April 5, 2016 11:36 am, Al Bersch wrote: > Hi Toni, > > > Just piping up here as a cspace user/implementer at the Oakland Museum of > California. We use CSpace with the object(cataloging)-centric way that > Ray > described, though as he mentioned, it's also convenient to be able to > relate different types of records together - for instance, we can create > a Valuation procedure for an Acquisition, where an entire accession was > purchased or appraised. > > If it would help your evaluation process to talk to current users, I'd be > happy to have a conversation, or answer other questions. > > > Thanks, > > > Al > > > On Mon, Apr 4, 2016 at 5:05 PM, Ray Lee <rhlee@berkeley.edu> wrote: > > >> Hi Toni, >> From a data modeling point of view, I think the correct way to do it >> with an out-of-the-box installation is to make Cataloging the main >> record, and link other procedures to it. A better name for "Cataloging" >> is "Object." The other procedures, like Intake and Acquisition, all >> refer to objects. So if you have an intake, you should create a >> Cataloging record for each >> object in the intake, and relate the Intake record to the Cataloging >> records. (You might also set the Identification Number on each >> Cataloging >> record to have a prefix indicating that it is in the intake stage). If >> you have an image of the object, you would create a Media Handling >> record, and link it to the Cataloging record, not the Intake. This way >> you have properly normalized data. >> >> You might also have an image of the intake itself, not the object. A >> common case for this is a museum that is moving from a paper-based >> system to CollectionSpace. In that case, they might scan the paper >> intake record, and store that as a Media Record related to the Intake >> record -- not the Cataloging record, since the image really is of the >> intake, not the object. >> >> That said, each museum has a workflow that they're able to accommodate, >> and maybe what I've described is more work than they're willing to do. >> At >> that point they could customize CSpace to create a workflow that works >> for them, or hire a consultant like yourself to do those customizations. >> For >> example, for one museum we moved some of the fields on the Acquisition >> record onto the Cataloging record, so that they don't have to create >> Acquisition records at all. It means that every object is a separate >> acquisition. They can't have acquisitions that contain more than one >> object. But that's how they were already thinking of acquisitions, so >> it worked for them, and it streamlines the process. >> >> Ray >> >> >> >> On Sat, Apr 2, 2016 at 4:52 AM, toni hanna <toni@creyasoft.com> wrote: >> >> >>> Megan, my mistake: >>> I wrote "material resources" when I was supposed to write "media >>> resources". Apologies. I do not have a collection. I am an IT person >>> working for an IT consulting company who was asked to evaluate CSpace >>> as a whole. I am just trying to understand how CSpace works, and I am >>> exploring the possibilities. Thanks. >>> >>> >>> On Fri, April 1, 2016 10:49 am, Megan Forbes wrote: >>> >>>> Toni, >>>> >>>> >>>> >>>> Thanks for the note. Can you please let us know what types of >>>> materials you have in your collection, and what your goals are for >>> CollectionSpace? >>> >>>> It will help us figure out the best way to get them organized. >>>> >>>> >>>> >>>> Thanks, >>>> Megan >>>> >>>> >>>> >>>> >>>> Megan Forbes >>>> CollectionSpace Program Manager >>>> megan.forbes@lyrasis.org 917.267.9676 Cell meganbforbes Skype >>>> >>>> >>>> >>>> ________________________________________ >>>> From: Talk <talk-bounces@lists.collectionspace.org> on behalf of >>>> toni hanna <toni@creyasoft.com> Sent: Thursday, March 31, 2016 4:14 >>>> AM >>>> To: talk@lists.collectionspace.org >>>> Subject: [Talk] CS Linking Best Practice >>>> >>>> >>>> >>>> Hello everyone. >>>> I am trying to understand how CSpace does things. I see we can >>>> create "material resources" where we store images for objects. And I >>>> see that I can link this image to all other "processes". Suppose I >>>> did an "intake" >>> and >>>> I created a "material resource" and I linked >>>> it. Then I did a "acquisition" for the same object.. again I linked >>>> the image to this process. So with every process, I will need to >>>> link the image to each process? this can be pretty tedious. I was >>>> thinking that I will make "cataloging" the "main" record, then >>>> attach all other records >>> to >>>> it. Meaning, always start by creating a catalog record. This way >>>> all >>> links >>>> to images will be centralized and I will always know that images >>>> are linked to cataloging records. But this will force me to use >>>> "cataloging" >>>> for all objects, even when not needed. Is this a good practice? Is >>>> there a better way to accomplish what I am trying to do? Thank you >>>> everyone. Toni. >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Talk mailing list >>>> Talk@lists.collectionspace.org >>>> >>>> >>> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collecti >>> onspa >>>> ce.org >>>> >>> >>> >>> >>> _______________________________________________ >>> Talk mailing list >>> Talk@lists.collectionspace.org >>> >>> >>> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collecti >>> onspace.org >>> >> >> >> _______________________________________________ >> Talk mailing list >> Talk@lists.collectionspace.org >> >> >> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collection >> space.org >> >> > > > -- > Al Bersch > Collections Systems Manager > Oakland Museum of California > 1000 Oak Street, Oakland, CA 94607 > abersch@museumca.org 510-318-8468 > >

Thanks for the great discussion, everyone. The main goal of the CSpace information architecture...aka all the linking...is to present the collections staff with a contextual picture of the objects in their care. So an object may indeed have dozens of links out to other procedures, each of which illustrates something that has happened to that object - it was acquired, loaned out, given a storage location, conserved, etc. Going back to your original question, you can indeed link a media record to the acquisition, the object itself, etc., but generally this is handled procedurally - folks only link the media record where it's useful. So, they might link a photograph of the object when it first comes in the door to the acquisition, but after that all photos would just be attached to the object record. Photographs taken during an exhibition installation would be linked to the exhibition record, and so on. I hope this helps - if you have some free time I'd be happy to walk you through the software, as it can help to see how it all works. Megan Forbes CollectionSpace Program Manager megan.forbes@lyrasis.org 917.267.9676 Cell meganbforbes Skype ________________________________________ From: Talk <talk-bounces@lists.collectionspace.org> on behalf of toni hanna <toni@creyasoft.com> Sent: Thursday, April 7, 2016 3:51 AM To: Al Bersch Cc: toni hanna; talk@lists.collectionspace.org Subject: Re: [Talk] CS Linking Best Practice Thank you for your comments, Al. I appreciate your willingness to help, and will surely need it as we go forward. Concerning linking, my main concern (from an IT guy's perspective) is that if the linking is not somehow controlled for a specific target implementation (either procedurally or through some code), these links could get out of hand and users may end up having to jump from one procedure to another, trying to find linked information. >From the readings, I do realize that this design is intentional to keep the product flexible and that's a great design goal, but I still feel it needs to be managed in some manner. Am I off in my thinking? On Tue, April 5, 2016 11:36 am, Al Bersch wrote: > Hi Toni, > > > Just piping up here as a cspace user/implementer at the Oakland Museum of > California. We use CSpace with the object(cataloging)-centric way that > Ray > described, though as he mentioned, it's also convenient to be able to > relate different types of records together - for instance, we can create > a Valuation procedure for an Acquisition, where an entire accession was > purchased or appraised. > > If it would help your evaluation process to talk to current users, I'd be > happy to have a conversation, or answer other questions. > > > Thanks, > > > Al > > > On Mon, Apr 4, 2016 at 5:05 PM, Ray Lee <rhlee@berkeley.edu> wrote: > > >> Hi Toni, >> From a data modeling point of view, I think the correct way to do it >> with an out-of-the-box installation is to make Cataloging the main >> record, and link other procedures to it. A better name for "Cataloging" >> is "Object." The other procedures, like Intake and Acquisition, all >> refer to objects. So if you have an intake, you should create a >> Cataloging record for each >> object in the intake, and relate the Intake record to the Cataloging >> records. (You might also set the Identification Number on each >> Cataloging >> record to have a prefix indicating that it is in the intake stage). If >> you have an image of the object, you would create a Media Handling >> record, and link it to the Cataloging record, not the Intake. This way >> you have properly normalized data. >> >> You might also have an image of the intake itself, not the object. A >> common case for this is a museum that is moving from a paper-based >> system to CollectionSpace. In that case, they might scan the paper >> intake record, and store that as a Media Record related to the Intake >> record -- not the Cataloging record, since the image really is of the >> intake, not the object. >> >> That said, each museum has a workflow that they're able to accommodate, >> and maybe what I've described is more work than they're willing to do. >> At >> that point they could customize CSpace to create a workflow that works >> for them, or hire a consultant like yourself to do those customizations. >> For >> example, for one museum we moved some of the fields on the Acquisition >> record onto the Cataloging record, so that they don't have to create >> Acquisition records at all. It means that every object is a separate >> acquisition. They can't have acquisitions that contain more than one >> object. But that's how they were already thinking of acquisitions, so >> it worked for them, and it streamlines the process. >> >> Ray >> >> >> >> On Sat, Apr 2, 2016 at 4:52 AM, toni hanna <toni@creyasoft.com> wrote: >> >> >>> Megan, my mistake: >>> I wrote "material resources" when I was supposed to write "media >>> resources". Apologies. I do not have a collection. I am an IT person >>> working for an IT consulting company who was asked to evaluate CSpace >>> as a whole. I am just trying to understand how CSpace works, and I am >>> exploring the possibilities. Thanks. >>> >>> >>> On Fri, April 1, 2016 10:49 am, Megan Forbes wrote: >>> >>>> Toni, >>>> >>>> >>>> >>>> Thanks for the note. Can you please let us know what types of >>>> materials you have in your collection, and what your goals are for >>> CollectionSpace? >>> >>>> It will help us figure out the best way to get them organized. >>>> >>>> >>>> >>>> Thanks, >>>> Megan >>>> >>>> >>>> >>>> >>>> Megan Forbes >>>> CollectionSpace Program Manager >>>> megan.forbes@lyrasis.org 917.267.9676 Cell meganbforbes Skype >>>> >>>> >>>> >>>> ________________________________________ >>>> From: Talk <talk-bounces@lists.collectionspace.org> on behalf of >>>> toni hanna <toni@creyasoft.com> Sent: Thursday, March 31, 2016 4:14 >>>> AM >>>> To: talk@lists.collectionspace.org >>>> Subject: [Talk] CS Linking Best Practice >>>> >>>> >>>> >>>> Hello everyone. >>>> I am trying to understand how CSpace does things. I see we can >>>> create "material resources" where we store images for objects. And I >>>> see that I can link this image to all other "processes". Suppose I >>>> did an "intake" >>> and >>>> I created a "material resource" and I linked >>>> it. Then I did a "acquisition" for the same object.. again I linked >>>> the image to this process. So with every process, I will need to >>>> link the image to each process? this can be pretty tedious. I was >>>> thinking that I will make "cataloging" the "main" record, then >>>> attach all other records >>> to >>>> it. Meaning, always start by creating a catalog record. This way >>>> all >>> links >>>> to images will be centralized and I will always know that images >>>> are linked to cataloging records. But this will force me to use >>>> "cataloging" >>>> for all objects, even when not needed. Is this a good practice? Is >>>> there a better way to accomplish what I am trying to do? Thank you >>>> everyone. Toni. >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Talk mailing list >>>> Talk@lists.collectionspace.org >>>> >>>> >>> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collecti >>> onspa >>>> ce.org >>>> >>> >>> >>> >>> _______________________________________________ >>> Talk mailing list >>> Talk@lists.collectionspace.org >>> >>> >>> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collecti >>> onspace.org >>> >> >> >> _______________________________________________ >> Talk mailing list >> Talk@lists.collectionspace.org >> >> >> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collection >> space.org >> >> > > > -- > Al Bersch > Collections Systems Manager > Oakland Museum of California > 1000 Oak Street, Oakland, CA 94607 > abersch@museumca.org 510-318-8468 > > _______________________________________________ Talk mailing list Talk@lists.collectionspace.org http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org

Thanks a lot for these details, Megan. Yes, it makes a lot of sense to attach an image to the different procedure which would show what the object looked like at the moment. This type of flexibility is great. However, would it always make sense to link any procedure to any other procedure? I mean wouldn't it be better to have some rules that state which procedure is allowed to be related to which other? or alternatively, to have rules which prevent links between certain procedure that would not make sense? Just thinking out loud here to grasp how the application works :-) Thanks. On Thu, April 7, 2016 9:01 am, Megan Forbes wrote: > Thanks for the great discussion, everyone. > > > The main goal of the CSpace information architecture...aka all the > linking...is to present the collections staff with a contextual picture > of the objects in their care. So an object may indeed have dozens of > links out to other procedures, each of which illustrates something that > has happened to that object - it was acquired, loaned out, given a > storage location, conserved, etc. > > Going back to your original question, you can indeed link a media record > to the acquisition, the object itself, etc., but generally this is > handled procedurally - folks only link the media record where it's > useful. So, they might link a photograph of the object when it first > comes in the door to the acquisition, but after that all photos would > just be attached to the object record. Photographs taken during an > exhibition installation would be linked to the exhibition record, and so > on. > > I hope this helps - if you have some free time I'd be happy to walk you > through the software, as it can help to see how it all works. > > Megan Forbes > CollectionSpace Program Manager > megan.forbes@lyrasis.org 917.267.9676 Cell > meganbforbes Skype > > > > ________________________________________ > From: Talk <talk-bounces@lists.collectionspace.org> on behalf of toni > hanna <toni@creyasoft.com> Sent: Thursday, April 7, 2016 3:51 AM > To: Al Bersch > Cc: toni hanna; talk@lists.collectionspace.org > Subject: Re: [Talk] CS Linking Best Practice > > > Thank you for your comments, Al. I appreciate your willingness to help, > and will surely need it as we go forward. > > Concerning linking, my main concern (from an IT guy's perspective) is > that if the linking is not somehow controlled for a specific target > implementation (either procedurally or through some code), these links > could get out of hand and users may end up having to jump from one > procedure to another, trying to find linked information. From the > readings, I do realize that this design is intentional to keep the product > flexible and that's a great design goal, but I still feel it needs to be > managed in some manner. Am I off in my thinking? > > On Tue, April 5, 2016 11:36 am, Al Bersch wrote: > >> Hi Toni, >> >> >> >> Just piping up here as a cspace user/implementer at the Oakland Museum >> of California. We use CSpace with the object(cataloging)-centric way >> that Ray >> described, though as he mentioned, it's also convenient to be able to >> relate different types of records together - for instance, we can >> create a Valuation procedure for an Acquisition, where an entire >> accession was purchased or appraised. >> >> If it would help your evaluation process to talk to current users, I'd >> be happy to have a conversation, or answer other questions. >> >> >> Thanks, >> >> >> >> Al >> >> >> >> On Mon, Apr 4, 2016 at 5:05 PM, Ray Lee <rhlee@berkeley.edu> wrote: >> >> >> >>> Hi Toni, >>> From a data modeling point of view, I think the correct way to do it >>> with an out-of-the-box installation is to make Cataloging the main >>> record, and link other procedures to it. A better name for >>> "Cataloging" >>> is "Object." The other procedures, like Intake and Acquisition, all >>> refer to objects. So if you have an intake, you should create a >>> Cataloging record for each >>> object in the intake, and relate the Intake record to the Cataloging >>> records. (You might also set the Identification Number on each >>> Cataloging >>> record to have a prefix indicating that it is in the intake stage). If >>> you have an image of the object, you would create a Media Handling >>> record, and link it to the Cataloging record, not the Intake. This >>> way you have properly normalized data. >>> >>> You might also have an image of the intake itself, not the object. A >>> common case for this is a museum that is moving from a paper-based >>> system to CollectionSpace. In that case, they might scan the paper >>> intake record, and store that as a Media Record related to the Intake >>> record -- not the Cataloging record, since the image really is of >>> the intake, not the object. >>> >>> That said, each museum has a workflow that they're able to >>> accommodate, and maybe what I've described is more work than they're >>> willing to do. At >>> that point they could customize CSpace to create a workflow that works >>> for them, or hire a consultant like yourself to do those >>> customizations. For >>> example, for one museum we moved some of the fields on the Acquisition >>> record onto the Cataloging record, so that they don't have to create >>> Acquisition records at all. It means that every object is a separate >>> acquisition. They can't have acquisitions that contain more than one >>> object. But that's how they were already thinking of acquisitions, >>> so it worked for them, and it streamlines the process. >>> >>> Ray >>> >>> >>> >>> >>> On Sat, Apr 2, 2016 at 4:52 AM, toni hanna <toni@creyasoft.com> >>> wrote: >>> >>> >>> >>>> Megan, my mistake: >>>> I wrote "material resources" when I was supposed to write "media >>>> resources". Apologies. I do not have a collection. I am an IT person >>>> working for an IT consulting company who was asked to evaluate >>>> CSpace >>>> as a whole. I am just trying to understand how CSpace works, and I >>>> am exploring the possibilities. Thanks. >>>> >>>> >>>> On Fri, April 1, 2016 10:49 am, Megan Forbes wrote: >>>> >>>> >>>>> Toni, >>>>> >>>>> >>>>> >>>>> >>>>> Thanks for the note. Can you please let us know what types of >>>>> materials you have in your collection, and what your goals are for >>>>> >>>> CollectionSpace? >>>> >>>> >>>>> It will help us figure out the best way to get them organized. >>>>> >>>>> >>>>> >>>>> >>>>> Thanks, >>>>> Megan >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Megan Forbes >>>>> CollectionSpace Program Manager >>>>> megan.forbes@lyrasis.org 917.267.9676 Cell meganbforbes Skype >>>>> >>>>> >>>>> >>>>> ________________________________________ >>>>> From: Talk <talk-bounces@lists.collectionspace.org> on behalf of >>>>> toni hanna <toni@creyasoft.com> Sent: Thursday, March 31, 2016 >>>>> 4:14 >>>>> AM >>>>> To: talk@lists.collectionspace.org >>>>> Subject: [Talk] CS Linking Best Practice >>>>> >>>>> >>>>> >>>>> >>>>> Hello everyone. >>>>> I am trying to understand how CSpace does things. I see we can >>>>> create "material resources" where we store images for objects. And >>>>> I >>>>> see that I can link this image to all other "processes". Suppose I >>>>> did an "intake" >>>> and >>>>> I created a "material resource" and I linked >>>>> it. Then I did a "acquisition" for the same object.. again I >>>>> linked the image to this process. So with every process, I will >>>>> need to link the image to each process? this can be pretty >>>>> tedious. I was thinking that I will make "cataloging" the "main" >>>>> record, then attach all other records >>>> to >>>>> it. Meaning, always start by creating a catalog record. This way >>>>> all >>>> links >>>>> to images will be centralized and I will always know that images >>>>> are linked to cataloging records. But this will force me to use >>>>> "cataloging" >>>>> for all objects, even when not needed. Is this a good practice? Is >>>>> there a better way to accomplish what I am trying to do? Thank >>>>> you everyone. Toni. >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Talk mailing list >>>>> Talk@lists.collectionspace.org >>>>> >>>>> >>>>> >>>> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collec >>>> ti onspa >>>>> ce.org >>>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Talk mailing list >>>> Talk@lists.collectionspace.org >>>> >>>> >>>> >>>> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collec >>>> ti onspace.org >>>> >>> >>> >>> _______________________________________________ >>> Talk mailing list >>> Talk@lists.collectionspace.org >>> >>> >>> >>> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collecti >>> on space.org >>> >>> >> >> >> -- >> Al Bersch >> Collections Systems Manager >> Oakland Museum of California >> 1000 Oak Street, Oakland, CA 94607 >> abersch@museumca.org 510-318-8468 >> >> > > > > _______________________________________________ > Talk mailing list > Talk@lists.collectionspace.org > http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspa > ce.org >

Hi Toni, Concerning "we moved some of the fields on the Acquisition record onto the > Cataloging record", I have to check the documentation in more detail but > in general how would this impact future upgrades of CSpace? Is there a > clean way to keep custom code separate from plain CSpace code? > It really depends on the kinds of customizations you do and the changes that are in the CSpace upgrade. There is usually at least a little work required to upgrade your customizations for a new version of CSpace. Adding fields to a record is pretty safe. When you do customizations, you create a set of files in your own folder that either merge with or override files in the default installation. "could customize CSpace to create a workflow that works for them", is > CSpace built on some workflow engine which facilitates the creation of > workflows? or do you mean this generically i.e. to create actual java > code? There is not a workflow engine. Mostly I mean creating fields, hiding unused fields, moving fields around, hiding unused procedures, and creating procedures if none of the existing ones fit for something the museum wants to do. Most of these are XML configuration and editing HTML templates. Adding procedures also requires writing some Java. Ray