Hi all, Has anyone created or designed a Work authority or procedure separate from Collection Objects? I remember in some of the IMLS workshops that there was discussion about building a separate authority (I think) when the collection object was really something that was related to a Work (e.g., a costume that was part of a performance of a work). If so, do you have a schema, wireframe, or anything like that? The reason I'm asking is that for our visual resource collections, we have decided to model the collections as basically being centered around the Media Handling record. The digital images would be Media Handling records. They will be related to Cataloging records that are basically the Work that the image relates to. For example, if the visual resource collection has a digital image of a painting, the digital image is the media handling file; the original painting is a collection object record, but that object is not physically part of the visual resource collection's holdings. The Cataloging record is not what the museum collects, but they do need to manage rich metadata about the Work because in the end, that's what they are trying to understand and interpret through their image collections. Jesse and Megan: How are you modeling the films that your collection objects are related to? Walker colleagues: I know this was an issue in the discussion about cataloging performance. SMK colleagues: How are you handling images that might relate to objects not in your collection? Thanks all for your input and perspective! I'm just trying to make sure I'm going down the right design path. Regards, Chris Hoffman UC Berkeley

There is an analogy here to the shoemaker's kids going shoeless, I think... We have developed a work authority at MMI, and I was sure we had emailed the list with the wireframes & schema, but it appears the only thing I emailed the list about was condition check. The schema is available on the deploy wiki - it's pretty bare bones, and could easily be expanded to include fields more appropriate to describing works of art. I have attached here a screenshot of our implemented version of the authority. Jesse can speak to when this contribution would be ready for review by the core team. You'll see in the schema and screenshot that there are a few MMI-specific fields; these would not be included in our contributed version. -M http://wiki.collectionspace.org/display/deploy/Work+Authority+Schema On Thu, Oct 18, 2012 at 4:20 PM, Chris Hoffman <chris.hoffman@berkeley.edu>wrote: > Hi all, > > Has anyone created or designed a Work authority or procedure separate from > Collection Objects? I remember in some of the IMLS workshops that there > was discussion about building a separate authority (I think) when the > collection object was really something that was related to a Work (e.g., a > costume that was part of a performance of a work). If so, do you have a > schema, wireframe, or anything like that? > > The reason I'm asking is that for our visual resource collections, we have > decided to model the collections as basically being centered around the > Media Handling record. The digital images would be Media Handling records. > They will be related to Cataloging records that are basically the Work that > the image relates to. For example, if the visual resource collection has a > digital image of a painting, the digital image is the media handling file; > the original painting is a collection object record, but that object is not > physically part of the visual resource collection's holdings. The > Cataloging record is not what the museum collects, but they do need to > manage rich metadata about the Work because in the end, that's what they > are trying to understand and interpret through their image collections. > > Jesse and Megan: How are you modeling the films that your collection > objects are related to? > > Walker colleagues: I know this was an issue in the discussion about > cataloging performance. > > SMK colleagues: How are you handling images that might relate to objects > not in your collection? > > Thanks all for your input and perspective! I'm just trying to make sure > I'm going down the right design path. > > Regards, > Chris Hoffman > UC Berkeley > _______________________________________________ > Talk mailing list > Talk@lists.collectionspace.org > > http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org > -- Megan Forbes Collection Manager Museum of the Moving Image 36-01 35 Avenue Astoria, NY 11106 movingimage.us 718 777 6800 Direct 718 777 6834

The code for MMI's implemented work authority is publicly available on my github account. I've added the work authority code to the core tenant/default directories across all the branches. The code is available for review, but keep in mind it was originally developed on a v2.5 stack. A few of the UI unit tests were untested due to other constraints, yet has performed well in production. Services: https://github.com/jessemartinez/services/tree/MMI-30/services/work Application: https://github.com/jessemartinez/application/tree/MMI-30/ UI: https://github.com/jessemartinez/ui/tree/MMI-30/ As Megan stated earlier, MMI has a custom work authority that differs slightly from "core" work authority. Here is the core contributed schema: https://github.com/jessemartinez/services/blob/MMI-30/services/work/3rdparty/nuxeo-platform-cs-work/src/main/resources/schemas/works_common.xsd Please let me know if there is anything else I can provide or answer. Thank, - Jesse On Thu, Oct 18, 2012 at 4:32 PM, Megan Forbes <mforbes@movingimage.us> wrote: > There is an analogy here to the shoemaker's kids going shoeless, I think... > > We have developed a work authority at MMI, and I was sure we had emailed the > list with the wireframes & schema, but it appears the only thing I emailed > the list about was condition check. The schema is available on the deploy > wiki - it's pretty bare bones, and could easily be expanded to include > fields more appropriate to describing works of art. > > I have attached here a screenshot of our implemented version of the > authority. Jesse can speak to when this contribution would be ready for > review by the core team. You'll see in the schema and screenshot that there > are a few MMI-specific fields; these would not be included in our > contributed version. > > -M > > http://wiki.collectionspace.org/display/deploy/Work+Authority+Schema > > > > On Thu, Oct 18, 2012 at 4:20 PM, Chris Hoffman <chris.hoffman@berkeley.edu> > wrote: >> >> Hi all, >> >> Has anyone created or designed a Work authority or procedure separate from >> Collection Objects? I remember in some of the IMLS workshops that there was >> discussion about building a separate authority (I think) when the collection >> object was really something that was related to a Work (e.g., a costume that >> was part of a performance of a work). If so, do you have a schema, >> wireframe, or anything like that? >> >> The reason I'm asking is that for our visual resource collections, we have >> decided to model the collections as basically being centered around the >> Media Handling record. The digital images would be Media Handling records. >> They will be related to Cataloging records that are basically the Work that >> the image relates to. For example, if the visual resource collection has a >> digital image of a painting, the digital image is the media handling file; >> the original painting is a collection object record, but that object is not >> physically part of the visual resource collection's holdings. The >> Cataloging record is not what the museum collects, but they do need to >> manage rich metadata about the Work because in the end, that's what they are >> trying to understand and interpret through their image collections. >> >> Jesse and Megan: How are you modeling the films that your collection >> objects are related to? >> >> Walker colleagues: I know this was an issue in the discussion about >> cataloging performance. >> >> SMK colleagues: How are you handling images that might relate to objects >> not in your collection? >> >> Thanks all for your input and perspective! I'm just trying to make sure >> I'm going down the right design path. >> >> Regards, >> Chris Hoffman >> UC Berkeley >> _______________________________________________ >> Talk mailing list >> Talk@lists.collectionspace.org >> >> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org > > > > > -- > Megan Forbes > Collection Manager > > Museum of the Moving Image > 36-01 35 Avenue Astoria, NY 11106 > movingimage.us 718 777 6800 > Direct 718 777 6834 > > > > _______________________________________________ > Talk mailing list > Talk@lists.collectionspace.org > http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org >

Addendum: I find it helpful to use github's built-in diff tool to compare between two branches: https://github.com/jessemartinez/services/compare/v2.5...MMI-30 https://github.com/jessemartinez/application/compare/v2.5...MMI-30 https://github.com/jessemartinez/ui/compare/v2.5...MMI-30 - Jesse On Thu, Oct 18, 2012 at 5:21 PM, Jesse Martinez <jmartinez@movingimage.us> wrote: > The code for MMI's implemented work authority is publicly available on > my github account. I've added the work authority code to the core > tenant/default directories across all the branches. The code is > available for review, but keep in mind it was originally developed on > a v2.5 stack. A few of the UI unit tests were untested due to other > constraints, yet has performed well in production. > > Services: > https://github.com/jessemartinez/services/tree/MMI-30/services/work > Application: > https://github.com/jessemartinez/application/tree/MMI-30/ > UI: > https://github.com/jessemartinez/ui/tree/MMI-30/ > > As Megan stated earlier, MMI has a custom work authority that differs > slightly from "core" work authority. Here is the core contributed > schema: > https://github.com/jessemartinez/services/blob/MMI-30/services/work/3rdparty/nuxeo-platform-cs-work/src/main/resources/schemas/works_common.xsd > > Please let me know if there is anything else I can provide or answer. > > Thank, > > - Jesse > > On Thu, Oct 18, 2012 at 4:32 PM, Megan Forbes <mforbes@movingimage.us> wrote: >> There is an analogy here to the shoemaker's kids going shoeless, I think... >> >> We have developed a work authority at MMI, and I was sure we had emailed the >> list with the wireframes & schema, but it appears the only thing I emailed >> the list about was condition check. The schema is available on the deploy >> wiki - it's pretty bare bones, and could easily be expanded to include >> fields more appropriate to describing works of art. >> >> I have attached here a screenshot of our implemented version of the >> authority. Jesse can speak to when this contribution would be ready for >> review by the core team. You'll see in the schema and screenshot that there >> are a few MMI-specific fields; these would not be included in our >> contributed version. >> >> -M >> >> http://wiki.collectionspace.org/display/deploy/Work+Authority+Schema >> >> >> >> On Thu, Oct 18, 2012 at 4:20 PM, Chris Hoffman <chris.hoffman@berkeley.edu> >> wrote: >>> >>> Hi all, >>> >>> Has anyone created or designed a Work authority or procedure separate from >>> Collection Objects? I remember in some of the IMLS workshops that there was >>> discussion about building a separate authority (I think) when the collection >>> object was really something that was related to a Work (e.g., a costume that >>> was part of a performance of a work). If so, do you have a schema, >>> wireframe, or anything like that? >>> >>> The reason I'm asking is that for our visual resource collections, we have >>> decided to model the collections as basically being centered around the >>> Media Handling record. The digital images would be Media Handling records. >>> They will be related to Cataloging records that are basically the Work that >>> the image relates to. For example, if the visual resource collection has a >>> digital image of a painting, the digital image is the media handling file; >>> the original painting is a collection object record, but that object is not >>> physically part of the visual resource collection's holdings. The >>> Cataloging record is not what the museum collects, but they do need to >>> manage rich metadata about the Work because in the end, that's what they are >>> trying to understand and interpret through their image collections. >>> >>> Jesse and Megan: How are you modeling the films that your collection >>> objects are related to? >>> >>> Walker colleagues: I know this was an issue in the discussion about >>> cataloging performance. >>> >>> SMK colleagues: How are you handling images that might relate to objects >>> not in your collection? >>> >>> Thanks all for your input and perspective! I'm just trying to make sure >>> I'm going down the right design path. >>> >>> Regards, >>> Chris Hoffman >>> UC Berkeley >>> _______________________________________________ >>> Talk mailing list >>> Talk@lists.collectionspace.org >>> >>> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org >> >> >> >> >> -- >> Megan Forbes >> Collection Manager >> >> Museum of the Moving Image >> 36-01 35 Avenue Astoria, NY 11106 >> movingimage.us 718 777 6800 >> Direct 718 777 6834 >> >> >> >> _______________________________________________ >> Talk mailing list >> Talk@lists.collectionspace.org >> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org >>

More on Jesse's tip: https://github.com/blog/609-tracking-deploys-with-compare-view And as Jesse notes in his examples below, you can use GitHub's "compare view" to generate a dynamic 'diff' between two branches, as well as between any two specific commits. On Thu, Oct 18, 2012 at 2:49 PM, Jesse Martinez <jmartinez@movingimage.us> wrote: > Addendum: I find it helpful to use github's built-in diff tool to > compare between two branches: > > https://github.com/jessemartinez/services/compare/v2.5...MMI-30 > https://github.com/jessemartinez/application/compare/v2.5...MMI-30 > https://github.com/jessemartinez/ui/compare/v2.5...MMI-30 > > - Jesse > > On Thu, Oct 18, 2012 at 5:21 PM, Jesse Martinez > <jmartinez@movingimage.us> wrote: >> The code for MMI's implemented work authority is publicly available on >> my github account. I've added the work authority code to the core >> tenant/default directories across all the branches. The code is >> available for review, but keep in mind it was originally developed on >> a v2.5 stack. A few of the UI unit tests were untested due to other >> constraints, yet has performed well in production. >> >> Services: >> https://github.com/jessemartinez/services/tree/MMI-30/services/work >> Application: >> https://github.com/jessemartinez/application/tree/MMI-30/ >> UI: >> https://github.com/jessemartinez/ui/tree/MMI-30/ >> >> As Megan stated earlier, MMI has a custom work authority that differs >> slightly from "core" work authority. Here is the core contributed >> schema: >> https://github.com/jessemartinez/services/blob/MMI-30/services/work/3rdparty/nuxeo-platform-cs-work/src/main/resources/schemas/works_common.xsd >> >> Please let me know if there is anything else I can provide or answer. >> >> Thank, >> >> - Jesse >> >> On Thu, Oct 18, 2012 at 4:32 PM, Megan Forbes <mforbes@movingimage.us> wrote: >>> There is an analogy here to the shoemaker's kids going shoeless, I think... >>> >>> We have developed a work authority at MMI, and I was sure we had emailed the >>> list with the wireframes & schema, but it appears the only thing I emailed >>> the list about was condition check. The schema is available on the deploy >>> wiki - it's pretty bare bones, and could easily be expanded to include >>> fields more appropriate to describing works of art. >>> >>> I have attached here a screenshot of our implemented version of the >>> authority. Jesse can speak to when this contribution would be ready for >>> review by the core team. You'll see in the schema and screenshot that there >>> are a few MMI-specific fields; these would not be included in our >>> contributed version. >>> >>> -M >>> >>> http://wiki.collectionspace.org/display/deploy/Work+Authority+Schema >>> >>> >>> >>> On Thu, Oct 18, 2012 at 4:20 PM, Chris Hoffman <chris.hoffman@berkeley.edu> >>> wrote: >>>> >>>> Hi all, >>>> >>>> Has anyone created or designed a Work authority or procedure separate from >>>> Collection Objects? I remember in some of the IMLS workshops that there was >>>> discussion about building a separate authority (I think) when the collection >>>> object was really something that was related to a Work (e.g., a costume that >>>> was part of a performance of a work). If so, do you have a schema, >>>> wireframe, or anything like that? >>>> >>>> The reason I'm asking is that for our visual resource collections, we have >>>> decided to model the collections as basically being centered around the >>>> Media Handling record. The digital images would be Media Handling records. >>>> They will be related to Cataloging records that are basically the Work that >>>> the image relates to. For example, if the visual resource collection has a >>>> digital image of a painting, the digital image is the media handling file; >>>> the original painting is a collection object record, but that object is not >>>> physically part of the visual resource collection's holdings. The >>>> Cataloging record is not what the museum collects, but they do need to >>>> manage rich metadata about the Work because in the end, that's what they are >>>> trying to understand and interpret through their image collections. >>>> >>>> Jesse and Megan: How are you modeling the films that your collection >>>> objects are related to? >>>> >>>> Walker colleagues: I know this was an issue in the discussion about >>>> cataloging performance. >>>> >>>> SMK colleagues: How are you handling images that might relate to objects >>>> not in your collection? >>>> >>>> Thanks all for your input and perspective! I'm just trying to make sure >>>> I'm going down the right design path. >>>> >>>> Regards, >>>> Chris Hoffman >>>> UC Berkeley >>>> _______________________________________________ >>>> Talk mailing list >>>> Talk@lists.collectionspace.org >>>> >>>> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org >>> >>> >>> >>> >>> -- >>> Megan Forbes >>> Collection Manager >>> >>> Museum of the Moving Image >>> 36-01 35 Avenue Astoria, NY 11106 >>> movingimage.us 718 777 6800 >>> Direct 718 777 6834 >>> >>> >>> >>> _______________________________________________ >>> 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

Thanks, Jesse and Megan! Are you adding new fields or using existing fields on Cataloging and elsewhere that are then tied to the Work authority? Chris On Oct 18, 2012, at 2:49 PM, Jesse Martinez wrote: > Addendum: I find it helpful to use github's built-in diff tool to > compare between two branches: > > https://github.com/jessemartinez/services/compare/v2.5...MMI-30 > https://github.com/jessemartinez/application/compare/v2.5...MMI-30 > https://github.com/jessemartinez/ui/compare/v2.5...MMI-30 > > - Jesse > > On Thu, Oct 18, 2012 at 5:21 PM, Jesse Martinez > <jmartinez@movingimage.us> wrote: >> The code for MMI's implemented work authority is publicly available on >> my github account. I've added the work authority code to the core >> tenant/default directories across all the branches. The code is >> available for review, but keep in mind it was originally developed on >> a v2.5 stack. A few of the UI unit tests were untested due to other >> constraints, yet has performed well in production. >> >> Services: >> https://github.com/jessemartinez/services/tree/MMI-30/services/work >> Application: >> https://github.com/jessemartinez/application/tree/MMI-30/ >> UI: >> https://github.com/jessemartinez/ui/tree/MMI-30/ >> >> As Megan stated earlier, MMI has a custom work authority that differs >> slightly from "core" work authority. Here is the core contributed >> schema: >> https://github.com/jessemartinez/services/blob/MMI-30/services/work/3rdparty/nuxeo-platform-cs-work/src/main/resources/schemas/works_common.xsd >> >> Please let me know if there is anything else I can provide or answer. >> >> Thank, >> >> - Jesse >> >> On Thu, Oct 18, 2012 at 4:32 PM, Megan Forbes <mforbes@movingimage.us> wrote: >>> There is an analogy here to the shoemaker's kids going shoeless, I think... >>> >>> We have developed a work authority at MMI, and I was sure we had emailed the >>> list with the wireframes & schema, but it appears the only thing I emailed >>> the list about was condition check. The schema is available on the deploy >>> wiki - it's pretty bare bones, and could easily be expanded to include >>> fields more appropriate to describing works of art. >>> >>> I have attached here a screenshot of our implemented version of the >>> authority. Jesse can speak to when this contribution would be ready for >>> review by the core team. You'll see in the schema and screenshot that there >>> are a few MMI-specific fields; these would not be included in our >>> contributed version. >>> >>> -M >>> >>> http://wiki.collectionspace.org/display/deploy/Work+Authority+Schema >>> >>> >>> >>> On Thu, Oct 18, 2012 at 4:20 PM, Chris Hoffman <chris.hoffman@berkeley.edu> >>> wrote: >>>> >>>> Hi all, >>>> >>>> Has anyone created or designed a Work authority or procedure separate from >>>> Collection Objects? I remember in some of the IMLS workshops that there was >>>> discussion about building a separate authority (I think) when the collection >>>> object was really something that was related to a Work (e.g., a costume that >>>> was part of a performance of a work). If so, do you have a schema, >>>> wireframe, or anything like that? >>>> >>>> The reason I'm asking is that for our visual resource collections, we have >>>> decided to model the collections as basically being centered around the >>>> Media Handling record. The digital images would be Media Handling records. >>>> They will be related to Cataloging records that are basically the Work that >>>> the image relates to. For example, if the visual resource collection has a >>>> digital image of a painting, the digital image is the media handling file; >>>> the original painting is a collection object record, but that object is not >>>> physically part of the visual resource collection's holdings. The >>>> Cataloging record is not what the museum collects, but they do need to >>>> manage rich metadata about the Work because in the end, that's what they are >>>> trying to understand and interpret through their image collections. >>>> >>>> Jesse and Megan: How are you modeling the films that your collection >>>> objects are related to? >>>> >>>> Walker colleagues: I know this was an issue in the discussion about >>>> cataloging performance. >>>> >>>> SMK colleagues: How are you handling images that might relate to objects >>>> not in your collection? >>>> >>>> Thanks all for your input and perspective! I'm just trying to make sure >>>> I'm going down the right design path. >>>> >>>> Regards, >>>> Chris Hoffman >>>> UC Berkeley >>>> _______________________________________________ >>>> Talk mailing list >>>> Talk@lists.collectionspace.org >>>> >>>> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org >>> >>> >>> >>> >>> -- >>> Megan Forbes >>> Collection Manager >>> >>> Museum of the Moving Image >>> 36-01 35 Avenue Astoria, NY 11106 >>> movingimage.us 718 777 6800 >>> Direct 718 777 6834 >>> >>> >>> >>> _______________________________________________ >>> Talk mailing list >>> Talk@lists.collectionspace.org >>> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org >>>

We have one new field in a custom tenant that is wired to use the work authority. - Jesse On Thu, Oct 18, 2012 at 6:40 PM, Chris Hoffman <chris.hoffman@berkeley.edu> wrote: > Thanks, Jesse and Megan! > > Are you adding new fields or using existing fields on Cataloging and elsewhere that are then tied to the Work authority? > > Chris > > > On Oct 18, 2012, at 2:49 PM, Jesse Martinez wrote: > >> Addendum: I find it helpful to use github's built-in diff tool to >> compare between two branches: >> >> https://github.com/jessemartinez/services/compare/v2.5...MMI-30 >> https://github.com/jessemartinez/application/compare/v2.5...MMI-30 >> https://github.com/jessemartinez/ui/compare/v2.5...MMI-30 >> >> - Jesse >> >> On Thu, Oct 18, 2012 at 5:21 PM, Jesse Martinez >> <jmartinez@movingimage.us> wrote: >>> The code for MMI's implemented work authority is publicly available on >>> my github account. I've added the work authority code to the core >>> tenant/default directories across all the branches. The code is >>> available for review, but keep in mind it was originally developed on >>> a v2.5 stack. A few of the UI unit tests were untested due to other >>> constraints, yet has performed well in production. >>> >>> Services: >>> https://github.com/jessemartinez/services/tree/MMI-30/services/work >>> Application: >>> https://github.com/jessemartinez/application/tree/MMI-30/ >>> UI: >>> https://github.com/jessemartinez/ui/tree/MMI-30/ >>> >>> As Megan stated earlier, MMI has a custom work authority that differs >>> slightly from "core" work authority. Here is the core contributed >>> schema: >>> https://github.com/jessemartinez/services/blob/MMI-30/services/work/3rdparty/nuxeo-platform-cs-work/src/main/resources/schemas/works_common.xsd >>> >>> Please let me know if there is anything else I can provide or answer. >>> >>> Thank, >>> >>> - Jesse >>> >>> On Thu, Oct 18, 2012 at 4:32 PM, Megan Forbes <mforbes@movingimage.us> wrote: >>>> There is an analogy here to the shoemaker's kids going shoeless, I think... >>>> >>>> We have developed a work authority at MMI, and I was sure we had emailed the >>>> list with the wireframes & schema, but it appears the only thing I emailed >>>> the list about was condition check. The schema is available on the deploy >>>> wiki - it's pretty bare bones, and could easily be expanded to include >>>> fields more appropriate to describing works of art. >>>> >>>> I have attached here a screenshot of our implemented version of the >>>> authority. Jesse can speak to when this contribution would be ready for >>>> review by the core team. You'll see in the schema and screenshot that there >>>> are a few MMI-specific fields; these would not be included in our >>>> contributed version. >>>> >>>> -M >>>> >>>> http://wiki.collectionspace.org/display/deploy/Work+Authority+Schema >>>> >>>> >>>> >>>> On Thu, Oct 18, 2012 at 4:20 PM, Chris Hoffman <chris.hoffman@berkeley.edu> >>>> wrote: >>>>> >>>>> Hi all, >>>>> >>>>> Has anyone created or designed a Work authority or procedure separate from >>>>> Collection Objects? I remember in some of the IMLS workshops that there was >>>>> discussion about building a separate authority (I think) when the collection >>>>> object was really something that was related to a Work (e.g., a costume that >>>>> was part of a performance of a work). If so, do you have a schema, >>>>> wireframe, or anything like that? >>>>> >>>>> The reason I'm asking is that for our visual resource collections, we have >>>>> decided to model the collections as basically being centered around the >>>>> Media Handling record. The digital images would be Media Handling records. >>>>> They will be related to Cataloging records that are basically the Work that >>>>> the image relates to. For example, if the visual resource collection has a >>>>> digital image of a painting, the digital image is the media handling file; >>>>> the original painting is a collection object record, but that object is not >>>>> physically part of the visual resource collection's holdings. The >>>>> Cataloging record is not what the museum collects, but they do need to >>>>> manage rich metadata about the Work because in the end, that's what they are >>>>> trying to understand and interpret through their image collections. >>>>> >>>>> Jesse and Megan: How are you modeling the films that your collection >>>>> objects are related to? >>>>> >>>>> Walker colleagues: I know this was an issue in the discussion about >>>>> cataloging performance. >>>>> >>>>> SMK colleagues: How are you handling images that might relate to objects >>>>> not in your collection? >>>>> >>>>> Thanks all for your input and perspective! I'm just trying to make sure >>>>> I'm going down the right design path. >>>>> >>>>> Regards, >>>>> Chris Hoffman >>>>> UC Berkeley >>>>> _______________________________________________ >>>>> Talk mailing list >>>>> Talk@lists.collectionspace.org >>>>> >>>>> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org >>>> >>>> >>>> >>>> >>>> -- >>>> Megan Forbes >>>> Collection Manager >>>> >>>> Museum of the Moving Image >>>> 36-01 35 Avenue Astoria, NY 11106 >>>> movingimage.us 718 777 6800 >>>> Direct 718 777 6834 >>>> >>>> >>>> >>>> _______________________________________________ >>>> Talk mailing list >>>> Talk@lists.collectionspace.org >>>> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org >>>> >

Just to clarify: the work authority hasn't been officially submitted for review yet. It's complete, yes, but hasn't been introduced as a branch on the collectionspace repo. This will be coming soon. - Jesse On Thu, Oct 18, 2012 at 5:49 PM, Jesse Martinez <jmartinez@movingimage.us> wrote: > Addendum: I find it helpful to use github's built-in diff tool to > compare between two branches: > > https://github.com/jessemartinez/services/compare/v2.5...MMI-30 > https://github.com/jessemartinez/application/compare/v2.5...MMI-30 > https://github.com/jessemartinez/ui/compare/v2.5...MMI-30 > > - Jesse > > On Thu, Oct 18, 2012 at 5:21 PM, Jesse Martinez > <jmartinez@movingimage.us> wrote: >> The code for MMI's implemented work authority is publicly available on >> my github account. I've added the work authority code to the core >> tenant/default directories across all the branches. The code is >> available for review, but keep in mind it was originally developed on >> a v2.5 stack. A few of the UI unit tests were untested due to other >> constraints, yet has performed well in production. >> >> Services: >> https://github.com/jessemartinez/services/tree/MMI-30/services/work >> Application: >> https://github.com/jessemartinez/application/tree/MMI-30/ >> UI: >> https://github.com/jessemartinez/ui/tree/MMI-30/ >> >> As Megan stated earlier, MMI has a custom work authority that differs >> slightly from "core" work authority. Here is the core contributed >> schema: >> https://github.com/jessemartinez/services/blob/MMI-30/services/work/3rdparty/nuxeo-platform-cs-work/src/main/resources/schemas/works_common.xsd >> >> Please let me know if there is anything else I can provide or answer. >> >> Thank, >> >> - Jesse >> >> On Thu, Oct 18, 2012 at 4:32 PM, Megan Forbes <mforbes@movingimage.us> wrote: >>> There is an analogy here to the shoemaker's kids going shoeless, I think... >>> >>> We have developed a work authority at MMI, and I was sure we had emailed the >>> list with the wireframes & schema, but it appears the only thing I emailed >>> the list about was condition check. The schema is available on the deploy >>> wiki - it's pretty bare bones, and could easily be expanded to include >>> fields more appropriate to describing works of art. >>> >>> I have attached here a screenshot of our implemented version of the >>> authority. Jesse can speak to when this contribution would be ready for >>> review by the core team. You'll see in the schema and screenshot that there >>> are a few MMI-specific fields; these would not be included in our >>> contributed version. >>> >>> -M >>> >>> http://wiki.collectionspace.org/display/deploy/Work+Authority+Schema >>> >>> >>> >>> On Thu, Oct 18, 2012 at 4:20 PM, Chris Hoffman <chris.hoffman@berkeley.edu> >>> wrote: >>>> >>>> Hi all, >>>> >>>> Has anyone created or designed a Work authority or procedure separate from >>>> Collection Objects? I remember in some of the IMLS workshops that there was >>>> discussion about building a separate authority (I think) when the collection >>>> object was really something that was related to a Work (e.g., a costume that >>>> was part of a performance of a work). If so, do you have a schema, >>>> wireframe, or anything like that? >>>> >>>> The reason I'm asking is that for our visual resource collections, we have >>>> decided to model the collections as basically being centered around the >>>> Media Handling record. The digital images would be Media Handling records. >>>> They will be related to Cataloging records that are basically the Work that >>>> the image relates to. For example, if the visual resource collection has a >>>> digital image of a painting, the digital image is the media handling file; >>>> the original painting is a collection object record, but that object is not >>>> physically part of the visual resource collection's holdings. The >>>> Cataloging record is not what the museum collects, but they do need to >>>> manage rich metadata about the Work because in the end, that's what they are >>>> trying to understand and interpret through their image collections. >>>> >>>> Jesse and Megan: How are you modeling the films that your collection >>>> objects are related to? >>>> >>>> Walker colleagues: I know this was an issue in the discussion about >>>> cataloging performance. >>>> >>>> SMK colleagues: How are you handling images that might relate to objects >>>> not in your collection? >>>> >>>> Thanks all for your input and perspective! I'm just trying to make sure >>>> I'm going down the right design path. >>>> >>>> Regards, >>>> Chris Hoffman >>>> UC Berkeley >>>> _______________________________________________ >>>> Talk mailing list >>>> Talk@lists.collectionspace.org >>>> >>>> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org >>> >>> >>> >>> >>> -- >>> Megan Forbes >>> Collection Manager >>> >>> Museum of the Moving Image >>> 36-01 35 Avenue Astoria, NY 11106 >>> movingimage.us 718 777 6800 >>> Direct 718 777 6834 >>> >>> >>> >>> _______________________________________________ >>> Talk mailing list >>> Talk@lists.collectionspace.org >>> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org >>>

Hi Chris, Regarding your SMK specific question. At present we don't really handle images relating to objects outside our collection. In future we have talked about creating catalogue records for objects on loan for instance; or for objects with some relation to our collection, an exhibition or another event. It is our plan to distinguish these objects from our own by separate number patterns. As with images of our own objects I suppose images would be stored in a future DAM system with a link to the relevant object records in CollectionSpace. But this approach may raise some questions regarding search and search results, so we'll follow this discussion with great interest. I hope this answers your question. Cheers, Kim -----Oprindelig meddelelse----- Fra: Talk [mailto:talk-bounces@lists.collectionspace.org] På vegne af Chris Hoffman Sendt: 18. oktober 2012 22:20 Til: CollectionSpace Talk List Emne: [Talk] Work authority or procedure? Hi all, Has anyone created or designed a Work authority or procedure separate from Collection Objects? I remember in some of the IMLS workshops that there was discussion about building a separate authority (I think) when the collection object was really something that was related to a Work (e.g., a costume that was part of a performance of a work). If so, do you have a schema, wireframe, or anything like that? The reason I'm asking is that for our visual resource collections, we have decided to model the collections as basically being centered around the Media Handling record. The digital images would be Media Handling records. They will be related to Cataloging records that are basically the Work that the image relates to. For example, if the visual resource collection has a digital image of a painting, the digital image is the media handling file; the original painting is a collection object record, but that object is not physically part of the visual resource collection's holdings. The Cataloging record is not what the museum collects, but they do need to manage rich metadata about the Work because in the end, that's what they are trying to understand and interpret through their image collections. Jesse and Megan: How are you modeling the films that your collection objects are related to? Walker colleagues: I know this was an issue in the discussion about cataloging performance. SMK colleagues: How are you handling images that might relate to objects not in your collection? Thanks all for your input and perspective! I'm just trying to make sure I'm going down the right design path. Regards, Chris Hoffman UC Berkeley _______________________________________________ Talk mailing list Talk@lists.collectionspace.org http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org