SMK Deployment Wireframes
- Kim Brasen (Unlicensed)
In progress...
Generally, these wireframes are adapted to our requirements in Corpus (SMK's implementation of CollectionSpace), i.e. the fields and functionalities that we want to use from the CollectionSpace Core, plus our extensions that are either specific to SMK / Corpus or belongs to the Fine Arts Domain - CDWA (see also: SMK Gap Analysis I). The field names are still in English but will eventually be translated into Danish. In order to be able to fully display data on collection objects in other languages than Danish on our web site and in reports etc., we have added language fields to a number of text fields and made them group repeatable (in our actual deployment some of this work still awaits further development from CollectionSpace).
In order to secure a meaningfull exchange of data with other institutions using the application, we have maintained the original definitions (and data types) of all CS Core fields; so rather than manipulating field definitions to our local needs we have added new fields and removed others. Regarding Information Groups we have adjusted them to our practice of registration.
Acquisition
.bmp?version=1&modificationDate=1314781739000&cacheVersion=1&api=v2){kind=link}
All fields derive from CollectionSpace Core. The only noteworthys change are that we have reduced the number of fields in the Purchase Price group, and hidden the Transfer of Title Number field since we have no use for it.
Object Entry
The fields in this wireframe generally reflect the sequence in CS Core but adabted to the 'chronology' of the actual procedure (from the first to the second column). We have added the fields Consignee and Responsible as SMK specific extensions, and hidden the Depositor fields along with the Entry Method. Regarding the additional Information Groups of this procedure we either have no use for them, or they are not in corcordance with our current practice, so for now they have been hidden.
Cataloguing
As will be apparent in comparison with the CollectionSpace Core we have rearranged and hidden existing fields, and added new ones. In the Identification Information Group we have moved Responsible Department and Collection (and Number of Objects) to the top because the information of these fields is sort of the starting point of the type of object that is going to be registered, and the information entered here will help autogenerate an Identification or Accession Number. The Object Name group of fields has been reduced to a single field and has been moved up.
In the Title group of fields we have hidden the Title Translation and Title Translation Language fields, and added a Translated tick box that along with the Verso tick box, and the Language field added to Comments are SMK specific extensions.
The Brief Description and Distinguishing Features fields have been moved to another information group since their new placement is in concordance to our existing practice of registration.
The Object Production Information Group we have moved up. As a Fine Arts institution the artist sort of reigns supreme and again this is in line with the way of registration in our existing system. The sequence of fields also reflects current practice. We have decided to implement a number of extensions Creation Information Group in the CDWA. These fields will be classed as Fine Art Domain extensions.
A SMK specific Language field has been added to the Production Note, and the group made repeatable.
The Production People and Production Reason fields have been hidden, and the Production Technique moved to another information group.
The next information group which we now call Physical Characteristics is partly a new information group consisting a number of fields from the Description Information Group in CS Core plus a number of SMK specific extensions. Overall these data relate to the work's physical appearence; materials, production technique (from the Object Production Information group), and dimensions.
Material Role, Watermarks and Shape are Fine Arts Domain extensions from the CDWA. While the Language field added to the Production Technique and the Tecnical Appliance group of fields are SMK specific extensions, the lather used for the recording of technical appliances as parts of works of art - be it hairdryers, drills, record players or whatever.
In Object Description Information we have hidden several fields and added others. Common to these is that they relate to data of a more descriptive nature reflectingan academic art historical knowledge such as Work Status, State (of prints), and the arrangement of works of art in multiple pieces.
Brief Description and Distiguishing Features have been moved here from the Object Identification Information group. Related Work Label, State Description, Orientation and Orientation Remarks are Fine Arts domain extensions. Regarding Textual Inscription we have hidden a few fields and generally rearranged the sequense of fields. Simerlarly for the much reduced Content group of fields, to which we have added the Event Name fields from Object History and Association Information.
The Reference Information Group have been extended with an Archive and Text group of fields respectively. The archive relation will eventualy point to an archive authority build here as part of the SMK specific extensions.
Provenance Information is a new 'group' we have added since the Object History Note is the only field we will use from Object History and Association Information, apart from the Event Name fields that we moved to Content (see above).
Finally we have added af new information group called Object Administration Information in which all fields are SMK specific extensions except the Copyright Statemant and Legal Status fields which are Fine Arts Domain extensions.
Loan In
Only two changes have been made; the three date field have been moved towards the top, since this is in consistancy with the the placing of similar fields in other procedures; and Lender's Credit Line (SMK-extension) has been added.
Note:Â The CS Loan In Schema is not fully implemented yet. Fields need to be added to the "Borrower" repeatable group (similar to the Lender group of fields), and the sub-loan schema is not yet implemented to this procedure (CSPACE-3269) . A final wireframe will await the fully implemented schema.
Loan Out
As in Loan In the date fields have been moved towards the top, again this is in consistency with the placement of similar fields in other procedures.
Location/Movement/Inventory Control
Location/Movement/Inventory Control
Location and Movement has recently undergone change with the addition of Inventory Control. This wireframe is markedly different from the CS implementation and reflects our requirements for a Location and Movement procedure. The Current Location field will be fed from both the Person and Organization authorities; the ability to record Location Types, as well as multiple contacts and ordering of future locations in movement records a.m.. This wireframe may still be subject to change especially regarding planned future locations which might become a distinct information group in this procedure.
Object Exit
The fields in this procedure all derive from CS Core except Consignor, which is an SMK specific extension. In this version the placing of fields mirror the placing of fields in the Object Entry procedure. Although the fields to a certain extent is separated between the actual procedure and 'inherent' static values (owner and reason).
Name Authority
The Name Authority schemae and wireframes have recently been changed substantially and are not fully implemented yet - this is reflected in these wireframes especially regarding hierarchical relationships and contact information.
Person Name Authority
Most fields derive from CS Core (including Name Type). The Copyright Statement field and the Person Event group of fields are Fine Arts (CDWA) extensions. The Language field added to the Biographical Note and the whole Reference Information Group are SMK extensions.
Organization Name Authority
All fields derive from CS Core with the exception of Organization's Reference Number (this field used to be in the CS Schema, but apparently it will now become a SMK extension - since we need it).