Toni, There is an open issue for allowing an admin to configure which tabs will show for which procedures (https://issues.collectionspace.org/browse/CSPACE-3941), but it's never risen to a priority level that would push us to spend development time on it. I think we'd hesitate to determine on a universal basis which procedures should be allowed to be related to other procedures - if we did implement this functionality it would need to be on a per-institution basis. In anticipation of doing some work on the underlying UI code this fall, we are planning a UX review this spring, and it will be very interesting to hear what our current implementers think of the tab structure as a whole, and its positives and negatives. Once the report is complete we'll be sure to share it with the community. Best regards, Megan Megan Forbes CollectionSpace Program Manager megan.forbes@lyrasis.org 917.267.9676 Cell meganbforbes Skype ________________________________________ From: toni hanna <toni@creyasoft.com> Sent: Thursday, April 14, 2016 2:01 PM To: Megan Forbes Cc: toni hanna; Al Bersch; talk@lists.collectionspace.org Subject: Re: [Talk] CS Linking Best Practice 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 >