CP
Christopher Pott
Tue, Jun 22, 2010 1:27 PM
Hi,
We have a requirement for storage of some basic data relating to all
museum employees with the possibility to make (some) of this data (eg.
phone number, name, department etc.) available to a web site (and
probably some other applications) via a web service.
Would it be appropriate to store this data within CollectionSpace as
Person Name Authority records?
Many of the persons would already have roles (for example, as an
authority for relocating an object) and therefore some of their details
within CollectionSpace, but others could have no relationships to any
current CollectionObjects or procedures (for example, a secretary or a
museum guide). Without these relationships, what would distinguish these
persons as employees as opposed to other roles (eg. artists, or external
contacts)?
/Chris
Developer, Corpus Project
Statens Museum for Kunst (National Gallery of Denmark)
Hi,
We have a requirement for storage of some basic data relating to all
museum employees with the possibility to make (some) of this data (eg.
phone number, name, department etc.) available to a web site (and
probably some other applications) via a web service.
Would it be appropriate to store this data within CollectionSpace as
Person Name Authority records?
Many of the persons would already have roles (for example, as an
authority for relocating an object) and therefore some of their details
within CollectionSpace, but others could have no relationships to any
current CollectionObjects or procedures (for example, a secretary or a
museum guide). Without these relationships, what would distinguish these
persons as employees as opposed to other roles (eg. artists, or external
contacts)?
/Chris
Developer, Corpus Project
Statens Museum for Kunst (National Gallery of Denmark)
AS
Angela Spinazze
Tue, Jun 22, 2010 2:21 PM
Hi Chris,
Walker Art Center are considering doing a similar thing with an active
list of names/addresses/contacts. Some of the names included in the
list are staff who do work with the collections.
It is possible to identify the role a person plays without creating a
relationship to anything else in CSpace (use the Person's occupation
field). And, you could use the field Person's group to indicate that
they are a member of staff.
Does that help?
Angela
On 22 Jun, 2010, at 8:27, Christopher Pott wrote:
Hi,
We have a requirement for storage of some basic data relating to all
museum employees with the possibility to make (some) of this data (eg.
phone number, name, department etc.) available to a web site (and
probably some other applications) via a web service.
Would it be appropriate to store this data within CollectionSpace as
Person Name Authority records?
Many of the persons would already have roles (for example, as an
authority for relocating an object) and therefore some of their
details
within CollectionSpace, but others could have no relationships to any
current CollectionObjects or procedures (for example, a secretary or a
museum guide). Without these relationships, what would distinguish
these
persons as employees as opposed to other roles (eg. artists, or
external
contacts)?
/Chris
Developer, Corpus Project
Statens Museum for Kunst (National Gallery of Denmark)
Talk mailing list
Talk@lists.collectionspace.org
http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org
Hi Chris,
Walker Art Center are considering doing a similar thing with an active
list of names/addresses/contacts. Some of the names included in the
list are staff who do work with the collections.
It is possible to identify the role a person plays without creating a
relationship to anything else in CSpace (use the Person's occupation
field). And, you could use the field Person's group to indicate that
they are a member of staff.
Does that help?
Angela
On 22 Jun, 2010, at 8:27, Christopher Pott wrote:
> Hi,
>
> We have a requirement for storage of some basic data relating to all
> museum employees with the possibility to make (some) of this data (eg.
> phone number, name, department etc.) available to a web site (and
> probably some other applications) via a web service.
>
> Would it be appropriate to store this data within CollectionSpace as
> Person Name Authority records?
>
> Many of the persons would already have roles (for example, as an
> authority for relocating an object) and therefore some of their
> details
> within CollectionSpace, but others could have no relationships to any
> current CollectionObjects or procedures (for example, a secretary or a
> museum guide). Without these relationships, what would distinguish
> these
> persons as employees as opposed to other roles (eg. artists, or
> external
> contacts)?
>
> /Chris
>
> Developer, Corpus Project
> Statens Museum for Kunst (National Gallery of Denmark)
>
>
>
> _______________________________________________
> Talk mailing list
> Talk@lists.collectionspace.org
> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org
PS
Patrick Schmitz
Tue, Jun 22, 2010 4:22 PM
Hi Chris -
In addition, a feature planned for a coming release is something like tags
for people in the Person Authority, to allow filtering in certain contexts.
E.g., if you have a set of people who are donors, this feature will make it
possible for the UI to just show "persons-marked-as-donors" in an
autocomplete widget for a donor field. Staff could be similarly marked and
filtered in a given context, as well. (This feature will be available for
all authorities).
We should perhaps talk about the security issues of having this PII
(personally identifying information) in the system, and whether we need
additional protections in place (encryption of fields in the DB, etc.).
Patrick
-----Original Message-----
From: talk-bounces@lists.collectionspace.org
[mailto:talk-bounces@lists.collectionspace.org] On Behalf Of
Angela Spinazze
Sent: Tuesday, June 22, 2010 7:22 AM
To: Christopher Pott
Cc: talk@lists.collectionspace.org
Subject: Re: [Talk] employee data in CollectionSpace
Hi Chris,
Walker Art Center are considering doing a similar thing with
an active list of names/addresses/contacts. Some of the
names included in the list are staff who do work with the collections.
It is possible to identify the role a person plays without
creating a relationship to anything else in CSpace (use the
Person's occupation field). And, you could use the field
Person's group to indicate that they are a member of staff.
Does that help?
Angela
On 22 Jun, 2010, at 8:27, Christopher Pott wrote:
Hi,
We have a requirement for storage of some basic data
museum employees with the possibility to make (some) of
phone number, name, department etc.) available to a web site (and
probably some other applications) via a web service.
Would it be appropriate to store this data within
Person Name Authority records?
Many of the persons would already have roles (for example, as an
authority for relocating an object) and therefore some of their
details within CollectionSpace, but others could have no
to any current CollectionObjects or procedures (for example, a
secretary or a museum guide). Without these relationships,
distinguish these persons as employees as opposed to other
artists, or external contacts)?
/Chris
Developer, Corpus Project
Statens Museum for Kunst (National Gallery of Denmark)
Talk mailing list
Talk@lists.collectionspace.org
Hi Chris -
In addition, a feature planned for a coming release is something like tags
for people in the Person Authority, to allow filtering in certain contexts.
E.g., if you have a set of people who are donors, this feature will make it
possible for the UI to just show "persons-marked-as-donors" in an
autocomplete widget for a donor field. Staff could be similarly marked and
filtered in a given context, as well. (This feature will be available for
all authorities).
We should perhaps talk about the security issues of having this PII
(personally identifying information) in the system, and whether we need
additional protections in place (encryption of fields in the DB, etc.).
Patrick
> -----Original Message-----
> From: talk-bounces@lists.collectionspace.org
> [mailto:talk-bounces@lists.collectionspace.org] On Behalf Of
> Angela Spinazze
> Sent: Tuesday, June 22, 2010 7:22 AM
> To: Christopher Pott
> Cc: talk@lists.collectionspace.org
> Subject: Re: [Talk] employee data in CollectionSpace
>
> Hi Chris,
>
> Walker Art Center are considering doing a similar thing with
> an active list of names/addresses/contacts. Some of the
> names included in the list are staff who do work with the collections.
>
> It is possible to identify the role a person plays without
> creating a relationship to anything else in CSpace (use the
> Person's occupation field). And, you could use the field
> Person's group to indicate that they are a member of staff.
>
> Does that help?
>
> Angela
>
>
> On 22 Jun, 2010, at 8:27, Christopher Pott wrote:
>
> > Hi,
> >
> > We have a requirement for storage of some basic data
> relating to all
> > museum employees with the possibility to make (some) of
> this data (eg.
> > phone number, name, department etc.) available to a web site (and
> > probably some other applications) via a web service.
> >
> > Would it be appropriate to store this data within
> CollectionSpace as
> > Person Name Authority records?
> >
> > Many of the persons would already have roles (for example, as an
> > authority for relocating an object) and therefore some of their
> > details within CollectionSpace, but others could have no
> relationships
> > to any current CollectionObjects or procedures (for example, a
> > secretary or a museum guide). Without these relationships,
> what would
> > distinguish these persons as employees as opposed to other
> roles (eg.
> > artists, or external contacts)?
> >
> > /Chris
> >
> > Developer, Corpus Project
> > Statens Museum for Kunst (National Gallery of Denmark)
> >
> >
> >
> > _______________________________________________
> > Talk mailing list
> > Talk@lists.collectionspace.org
> >
> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectio
> > nspace.org
>
>
> _______________________________________________
> Talk mailing list
> Talk@lists.collectionspace.org
> http://lists.collectionspace.org/mailman/listinfo/talk_lists.c
> ollectionspace.org
>
AR
Aron Roberts
Tue, Jun 22, 2010 4:53 PM
We have a requirement for storage of some basic data relating to all
museum employees with the possibility to make (some) of this data (eg.
phone number, name, department etc.) available to a web site (and
probably some other applications) via a web service.
Would it be appropriate to store this data within CollectionSpace as
Person Name Authority records?
A followup to the two very interesting messages so far in this thread:
-
Angela's comment on the use of the "Person's occupation" and
"Person's group" fields.
-
Patrick's preview of future functionality around tagging and
filtering of person authority records, and his comment on securing
personally identifiable information (e.g. identification of a person
as a "donor").
Yes, it can be appropriate to store basic contact and affiliation
information for museum employees in CollectionSpace.
In the CollectionSpace services layer, there is today a very
rudimentary Contact record, at least a placeholder for future
functionality. There is a many to one relationship between Contacts
and Person (and Organization) records:
PersonAuthority ==> 0...n Persons
|__ each Person ==> 0..n Contacts
OrganizationAuthority => 0...n Organizations
|__ each Organization ==> 0...n Contacts
These RESTful API documents have been recently updated to describe
how you can add Contacts to Persons and Organizations, via the Person
and Organization services:
http://wiki.collectionspace.org/display/collectionspace/Person+Service+REST+APIs+-+Release+v0.8#PersonServiceRESTAPIs-Releasev0.8-ContactCRUDLservices
http://wiki.collectionspace.org/display/collectionspace/Organization+Service+REST+APIs+-+Release+v0.8#OrganizationServiceRESTAPIs-Releasev0.8-ContactCRUDLservices
There will be full-stack support for adding Contacts through the UI
in a future release. The current wireframes / designs for this:
http://wiki.collectionspace.org/display/collectionspace/Wireframes+-+Name+Authority
The current Contact schema looks like this:
In 0.8:
http://wiki.collectionspace.org/display/collectionspace/Name+Authority+Schema+-+Limited+for+Release+0.8
(see the "Contact Information" subhead)
For post-1.0 implementation:
http://wiki.collectionspace.org/display/collectionspace/Name+Authority+Schema#NameAuthoritySchema-ContactInformation
There have also been some ambitious suggestions to revise the
'post-1.0' Contact schema above, from modestly to radically, to make
it even more flexible for today's mix of physical and electronic
address types. There is a JIRA issue for this, which includes a
summary description and pointer to a December 2009 discussion on this
topic with Michael Black of PAHMA and several of our Museum
Informatics folks:
"Revise the Contact info schema"
http://issues.collectionspace.org/browse/CSPACE-836
We very much invite your - ongoing - feedback on the Contact record
schema, with respect to meeting SMK's needs.
Aron
P.S. It's also my personal hope that we will at some point support
import and export of Contacts in the standard vCard format, although
this might not be on the 1.0/2.0 roadmap.
Chris wrote:
> We have a requirement for storage of some basic data relating to all
museum employees with the possibility to make (some) of this data (eg.
phone number, name, department etc.) available to a web site (and
probably some other applications) via a web service.
> Would it be appropriate to store this data within CollectionSpace as
Person Name Authority records?
A followup to the two very interesting messages so far in this thread:
- Angela's comment on the use of the "Person's occupation" and
"Person's group" fields.
- Patrick's preview of future functionality around tagging and
filtering of person authority records, and his comment on securing
personally identifiable information (e.g. identification of a person
as a "donor").
Yes, it can be appropriate to store basic contact and affiliation
information for museum employees in CollectionSpace.
In the CollectionSpace services layer, there is today a *very*
rudimentary Contact record, at least a placeholder for future
functionality. There is a many to one relationship between Contacts
and Person (and Organization) records:
PersonAuthority ==> 0...n Persons
|__ each Person ==> 0..n Contacts
OrganizationAuthority => 0...n Organizations
|__ each Organization ==> 0...n Contacts
These RESTful API documents have been recently updated to describe
how you can add Contacts to Persons and Organizations, via the Person
and Organization services:
http://wiki.collectionspace.org/display/collectionspace/Person+Service+REST+APIs+-+Release+v0.8#PersonServiceRESTAPIs-Releasev0.8-ContactCRUDLservices
http://wiki.collectionspace.org/display/collectionspace/Organization+Service+REST+APIs+-+Release+v0.8#OrganizationServiceRESTAPIs-Releasev0.8-ContactCRUDLservices
There will be full-stack support for adding Contacts through the UI
in a future release. The current wireframes / designs for this:
http://wiki.collectionspace.org/display/collectionspace/Wireframes+-+Name+Authority
The current Contact schema looks like this:
In 0.8:
http://wiki.collectionspace.org/display/collectionspace/Name+Authority+Schema+-+Limited+for+Release+0.8
(see the "Contact Information" subhead)
For post-1.0 implementation:
http://wiki.collectionspace.org/display/collectionspace/Name+Authority+Schema#NameAuthoritySchema-ContactInformation
There have also been some ambitious suggestions to revise the
'post-1.0' Contact schema above, from modestly to radically, to make
it even more flexible for today's mix of physical and electronic
address types. There is a JIRA issue for this, which includes a
summary description and pointer to a December 2009 discussion on this
topic with Michael Black of PAHMA and several of our Museum
Informatics folks:
"Revise the Contact info schema"
http://issues.collectionspace.org/browse/CSPACE-836
We very much invite your - ongoing - feedback on the Contact record
schema, with respect to meeting SMK's needs.
Aron
P.S. It's also my personal hope that we will at some point support
import and export of Contacts in the standard vCard format, although
this might not be on the 1.0/2.0 roadmap.
CP
Christopher Pott
Wed, Jun 23, 2010 11:38 AM
Thank you all for your comments. I was hoping we could use CollectionSpace for this purpose, and it's great to see it will fit our requirements. Do you have any further words of comfort about the following points?...
- the ability to add new fields (CV, conferences attended, qualifications etc.) which I hope we can accomplish via schema extensions either to the Contact or Person schemas.
- the ability to mark individual fields for internet or intranet publishing
- support for images (presumeably supported via media snapshot relationship?)
I'm unclear on whether it's preferable to organise Persons via internal fields as Angela suggested, or by relating Person records within a hierarchy of Organisations (if I've understood correctly this is also a possibility).
Encryption would be necessary for some of our confidential employee data used by our Administration department. However, we don't have immediate plans to migrate this to CollectionSpace.
I'd like to soon use a local deployment of CollectionSpace for trying this out. ie. serving Person data to an intranet site from which we can implement the ability, via web services, to update/edit employee details (for test use only). Should 0.8 be able to handle this?
/Chris
Developer, Corpus Project
Statens Museum for Kunst (National Gallery of Denmark)
-----Oprindelig meddelelse-----
Fra: aronroberts@gmail.com [mailto:aronroberts@gmail.com] På vegne af Aron Roberts
Sendt: 22. juni 2010 18:53
Til: Christopher Pott
Cc: talk@lists.collectionspace.org
Emne: Re: [Talk] employee data in CollectionSpace
Chris wrote:
We have a requirement for storage of some basic data relating to all
museum employees with the possibility to make (some) of this data (eg.
phone number, name, department etc.) available to a web site (and
probably some other applications) via a web service.
Would it be appropriate to store this data within CollectionSpace as
Person Name Authority records?
A followup to the two very interesting messages so far in this thread:
-
Angela's comment on the use of the "Person's occupation" and
"Person's group" fields.
-
Patrick's preview of future functionality around tagging and
filtering of person authority records, and his comment on securing
personally identifiable information (e.g. identification of a person
as a "donor").
Yes, it can be appropriate to store basic contact and affiliation
information for museum employees in CollectionSpace.
In the CollectionSpace services layer, there is today a very
rudimentary Contact record, at least a placeholder for future
functionality. There is a many to one relationship between Contacts
and Person (and Organization) records:
PersonAuthority ==> 0...n Persons
|__ each Person ==> 0..n Contacts
OrganizationAuthority => 0...n Organizations
|__ each Organization ==> 0...n Contacts
These RESTful API documents have been recently updated to describe
how you can add Contacts to Persons and Organizations, via the Person
and Organization services:
http://wiki.collectionspace.org/display/collectionspace/Person+Service+REST+APIs+-+Release+v0.8#PersonServiceRESTAPIs-Releasev0.8-ContactCRUDLservices
http://wiki.collectionspace.org/display/collectionspace/Organization+Service+REST+APIs+-+Release+v0.8#OrganizationServiceRESTAPIs-Releasev0.8-ContactCRUDLservices
There will be full-stack support for adding Contacts through the UI
in a future release. The current wireframes / designs for this:
http://wiki.collectionspace.org/display/collectionspace/Wireframes+-+Name+Authority
The current Contact schema looks like this:
In 0.8:
http://wiki.collectionspace.org/display/collectionspace/Name+Authority+Schema+-+Limited+for+Release+0.8
(see the "Contact Information" subhead)
For post-1.0 implementation:
http://wiki.collectionspace.org/display/collectionspace/Name+Authority+Schema#NameAuthoritySchema-ContactInformation
There have also been some ambitious suggestions to revise the
'post-1.0' Contact schema above, from modestly to radically, to make
it even more flexible for today's mix of physical and electronic
address types. There is a JIRA issue for this, which includes a
summary description and pointer to a December 2009 discussion on this
topic with Michael Black of PAHMA and several of our Museum
Informatics folks:
"Revise the Contact info schema"
http://issues.collectionspace.org/browse/CSPACE-836
We very much invite your - ongoing - feedback on the Contact record
schema, with respect to meeting SMK's needs.
Aron
P.S. It's also my personal hope that we will at some point support
import and export of Contacts in the standard vCard format, although
this might not be on the 1.0/2.0 roadmap.
Thank you all for your comments. I was hoping we could use CollectionSpace for this purpose, and it's great to see it will fit our requirements. Do you have any further words of comfort about the following points?...
* the ability to add new fields (CV, conferences attended, qualifications etc.) which I hope we can accomplish via schema extensions either to the Contact or Person schemas.
* the ability to mark individual fields for internet or intranet publishing
* support for images (presumeably supported via media snapshot relationship?)
I'm unclear on whether it's preferable to organise Persons via internal fields as Angela suggested, or by relating Person records within a hierarchy of Organisations (if I've understood correctly this is also a possibility).
Encryption would be necessary for some of our confidential employee data used by our Administration department. However, we don't have immediate plans to migrate this to CollectionSpace.
I'd like to soon use a local deployment of CollectionSpace for trying this out. ie. serving Person data to an intranet site from which we can implement the ability, via web services, to update/edit employee details (for test use only). Should 0.8 be able to handle this?
/Chris
Developer, Corpus Project
Statens Museum for Kunst (National Gallery of Denmark)
-----Oprindelig meddelelse-----
Fra: aronroberts@gmail.com [mailto:aronroberts@gmail.com] På vegne af Aron Roberts
Sendt: 22. juni 2010 18:53
Til: Christopher Pott
Cc: talk@lists.collectionspace.org
Emne: Re: [Talk] employee data in CollectionSpace
Chris wrote:
> We have a requirement for storage of some basic data relating to all
museum employees with the possibility to make (some) of this data (eg.
phone number, name, department etc.) available to a web site (and
probably some other applications) via a web service.
> Would it be appropriate to store this data within CollectionSpace as
Person Name Authority records?
A followup to the two very interesting messages so far in this thread:
- Angela's comment on the use of the "Person's occupation" and
"Person's group" fields.
- Patrick's preview of future functionality around tagging and
filtering of person authority records, and his comment on securing
personally identifiable information (e.g. identification of a person
as a "donor").
Yes, it can be appropriate to store basic contact and affiliation
information for museum employees in CollectionSpace.
In the CollectionSpace services layer, there is today a *very*
rudimentary Contact record, at least a placeholder for future
functionality. There is a many to one relationship between Contacts
and Person (and Organization) records:
PersonAuthority ==> 0...n Persons
|__ each Person ==> 0..n Contacts
OrganizationAuthority => 0...n Organizations
|__ each Organization ==> 0...n Contacts
These RESTful API documents have been recently updated to describe
how you can add Contacts to Persons and Organizations, via the Person
and Organization services:
http://wiki.collectionspace.org/display/collectionspace/Person+Service+REST+APIs+-+Release+v0.8#PersonServiceRESTAPIs-Releasev0.8-ContactCRUDLservices
http://wiki.collectionspace.org/display/collectionspace/Organization+Service+REST+APIs+-+Release+v0.8#OrganizationServiceRESTAPIs-Releasev0.8-ContactCRUDLservices
There will be full-stack support for adding Contacts through the UI
in a future release. The current wireframes / designs for this:
http://wiki.collectionspace.org/display/collectionspace/Wireframes+-+Name+Authority
The current Contact schema looks like this:
In 0.8:
http://wiki.collectionspace.org/display/collectionspace/Name+Authority+Schema+-+Limited+for+Release+0.8
(see the "Contact Information" subhead)
For post-1.0 implementation:
http://wiki.collectionspace.org/display/collectionspace/Name+Authority+Schema#NameAuthoritySchema-ContactInformation
There have also been some ambitious suggestions to revise the
'post-1.0' Contact schema above, from modestly to radically, to make
it even more flexible for today's mix of physical and electronic
address types. There is a JIRA issue for this, which includes a
summary description and pointer to a December 2009 discussion on this
topic with Michael Black of PAHMA and several of our Museum
Informatics folks:
"Revise the Contact info schema"
http://issues.collectionspace.org/browse/CSPACE-836
We very much invite your - ongoing - feedback on the Contact record
schema, with respect to meeting SMK's needs.
Aron
P.S. It's also my personal hope that we will at some point support
import and export of Contacts in the standard vCard format, although
this might not be on the 1.0/2.0 roadmap.
AR
Aron Roberts
Wed, Jun 23, 2010 2:14 PM
Do you have any further words of comfort about the following points?...
- the ability to add new fields (CV, conferences attended, qualifications etc.) which I hope we can accomplish via schema extensions either to the Contact or Person schemas.
Contact records are amenable to schema extension.
- the ability to mark individual fields for internet or intranet publishing
You can let us know if this response might meet your needs for this:
through the Person service, you can programmatically retrieve Person
records and their associated Contact record(s), and extract data from
selected Contact record fields for re-publishing. As one of many
options, a web application that generates dynamic pages - using PHP,
ColdFusion, JSP, ASP, etc. - could presumably make these calls
directly to the CollectionSpace services layer.
- support for images (presumeably supported via media snapshot relationship?)
Interesting. Any record can be related to any other in
CollectionSpace through relationship / relations records, and Media
records are coming in 0.9, so as one option, it might be possible in
this way to relate, say, a Media record referring to a portrait
photograph to a Person record or a Media record referring to a
photograph of a group at a conference to multiple depicted Peron
records.
I'm unclear on whether it's preferable to organise Persons via internal fields as Angela suggested, or by relating Person records within a hierarchy of Organisations (if I've understood correctly this is also a possibility).
Perhaps others might wish to comment on this ...
Encryption would be necessary for some of our confidential employee data used by our Administration department. However, we don't have immediate plans to migrate this to CollectionSpace.
I'd like to soon use a local deployment of CollectionSpace for trying this out. ie. serving Person data to an intranet site from which we can implement the ability, via web services, to update/edit employee details (for test use only). Should 0.8 be able to handle this?
Yes, with the caveat that the Contact record schema for 0.8 is
rudimentary. Nonetheless, any mechanism you create now for retrieving
/ editing employee details has a high likelihood - schema changes
notwithstanding - of working 'as is', or with only minor modification,
when accessing future releases as well.
Aron
We have a requirement for storage of some basic data relating to all
museum employees with the possibility to make (some) of this data (eg.
phone number, name, department etc.) available to a web site (and
probably some other applications) via a web service.
Would it be appropriate to store this data within CollectionSpace as
Person Name Authority records?
A followup to the two very interesting messages so far in this thread:
- Angela's comment on the use of the "Person's occupation" and
"Person's group" fields.
- Patrick's preview of future functionality around tagging and
filtering of person authority records, and his comment on securing
personally identifiable information (e.g. identification of a person
as a "donor").
Yes, it can be appropriate to store basic contact and affiliation
information for museum employees in CollectionSpace.
In the CollectionSpace services layer, there is today a very
rudimentary Contact record, at least a placeholder for future
functionality. There is a many to one relationship between Contacts
and Person (and Organization) records:
PersonAuthority ==> 0...n Persons
|__ each Person ==> 0..n Contacts
OrganizationAuthority => 0...n Organizations
|__ each Organization ==> 0...n Contacts
These RESTful API documents have been recently updated to describe
how you can add Contacts to Persons and Organizations, via the Person
and Organization services:
http://wiki.collectionspace.org/display/collectionspace/Person+Service+REST+APIs+-+Release+v0.8#PersonServiceRESTAPIs-Releasev0.8-ContactCRUDLservices
http://wiki.collectionspace.org/display/collectionspace/Organization+Service+REST+APIs+-+Release+v0.8#OrganizationServiceRESTAPIs-Releasev0.8-ContactCRUDLservices
There will be full-stack support for adding Contacts through the UI
in a future release. The current wireframes / designs for this:
http://wiki.collectionspace.org/display/collectionspace/Wireframes+-+Name+Authority
The current Contact schema looks like this:
In 0.8:
http://wiki.collectionspace.org/display/collectionspace/Name+Authority+Schema+-+Limited+for+Release+0.8
(see the "Contact Information" subhead)
For post-1.0 implementation:
http://wiki.collectionspace.org/display/collectionspace/Name+Authority+Schema#NameAuthoritySchema-ContactInformation
There have also been some ambitious suggestions to revise the
'post-1.0' Contact schema above, from modestly to radically, to make
it even more flexible for today's mix of physical and electronic
address types. There is a JIRA issue for this, which includes a
summary description and pointer to a December 2009 discussion on this
topic with Michael Black of PAHMA and several of our Museum
Informatics folks:
"Revise the Contact info schema"
http://issues.collectionspace.org/browse/CSPACE-836
We very much invite your - ongoing - feedback on the Contact record
schema, with respect to meeting SMK's needs.
Aron
P.S. It's also my personal hope that we will at some point support
import and export of Contacts in the standard vCard format, although
this might not be on the 1.0/2.0 roadmap.
On Wed, Jun 23, 2010 at 4:38 AM, Christopher Pott
<Christopher.Pott@smk.dk> wrote:
> Do you have any further words of comfort about the following points?...
>
> * the ability to add new fields (CV, conferences attended, qualifications etc.) which I hope we can accomplish via schema extensions either to the Contact or Person schemas.
Contact records are amenable to schema extension.
> * the ability to mark individual fields for internet or intranet publishing
You can let us know if this response might meet your needs for this:
through the Person service, you can programmatically retrieve Person
records and their associated Contact record(s), and extract data from
selected Contact record fields for re-publishing. As one of many
options, a web application that generates dynamic pages - using PHP,
ColdFusion, JSP, ASP, etc. - could presumably make these calls
directly to the CollectionSpace services layer.
> * support for images (presumeably supported via media snapshot relationship?)
Interesting. Any record can be related to any other in
CollectionSpace through relationship / relations records, and Media
records are coming in 0.9, so as one option, it might be possible in
this way to relate, say, a Media record referring to a portrait
photograph to a Person record or a Media record referring to a
photograph of a group at a conference to multiple depicted Peron
records.
> I'm unclear on whether it's preferable to organise Persons via internal fields as Angela suggested, or by relating Person records within a hierarchy of Organisations (if I've understood correctly this is also a possibility).
Perhaps others might wish to comment on this ...
> Encryption would be necessary for some of our confidential employee data used by our Administration department. However, we don't have immediate plans to migrate this to CollectionSpace.
>
> I'd like to soon use a local deployment of CollectionSpace for trying this out. ie. serving Person data to an intranet site from which we can implement the ability, via web services, to update/edit employee details (for test use only). Should 0.8 be able to handle this?
Yes, with the caveat that the Contact record schema for 0.8 is
rudimentary. Nonetheless, any mechanism you create now for retrieving
/ editing employee details has a high likelihood - schema changes
notwithstanding - of working 'as is', or with only minor modification,
when accessing future releases as well.
Aron
>
> /Chris
>
> Developer, Corpus Project
> Statens Museum for Kunst (National Gallery of Denmark)
>
> -----Oprindelig meddelelse-----
> Fra: aronroberts@gmail.com [mailto:aronroberts@gmail.com] På vegne af Aron Roberts
> Sendt: 22. juni 2010 18:53
> Til: Christopher Pott
> Cc: talk@lists.collectionspace.org
> Emne: Re: [Talk] employee data in CollectionSpace
>
> Chris wrote:
>> We have a requirement for storage of some basic data relating to all
> museum employees with the possibility to make (some) of this data (eg.
> phone number, name, department etc.) available to a web site (and
> probably some other applications) via a web service.
>
>> Would it be appropriate to store this data within CollectionSpace as
> Person Name Authority records?
>
> A followup to the two very interesting messages so far in this thread:
> - Angela's comment on the use of the "Person's occupation" and
> "Person's group" fields.
> - Patrick's preview of future functionality around tagging and
> filtering of person authority records, and his comment on securing
> personally identifiable information (e.g. identification of a person
> as a "donor").
>
> Yes, it can be appropriate to store basic contact and affiliation
> information for museum employees in CollectionSpace.
>
> In the CollectionSpace services layer, there is today a *very*
> rudimentary Contact record, at least a placeholder for future
> functionality. There is a many to one relationship between Contacts
> and Person (and Organization) records:
>
> PersonAuthority ==> 0...n Persons
> |__ each Person ==> 0..n Contacts
>
> OrganizationAuthority => 0...n Organizations
> |__ each Organization ==> 0...n Contacts
>
> These RESTful API documents have been recently updated to describe
> how you can add Contacts to Persons and Organizations, via the Person
> and Organization services:
>
> http://wiki.collectionspace.org/display/collectionspace/Person+Service+REST+APIs+-+Release+v0.8#PersonServiceRESTAPIs-Releasev0.8-ContactCRUDLservices
>
> http://wiki.collectionspace.org/display/collectionspace/Organization+Service+REST+APIs+-+Release+v0.8#OrganizationServiceRESTAPIs-Releasev0.8-ContactCRUDLservices
>
> There will be full-stack support for adding Contacts through the UI
> in a future release. The current wireframes / designs for this:
>
> http://wiki.collectionspace.org/display/collectionspace/Wireframes+-+Name+Authority
>
> The current Contact schema looks like this:
>
> In 0.8:
>
> http://wiki.collectionspace.org/display/collectionspace/Name+Authority+Schema+-+Limited+for+Release+0.8
> (see the "Contact Information" subhead)
>
> For post-1.0 implementation:
>
> http://wiki.collectionspace.org/display/collectionspace/Name+Authority+Schema#NameAuthoritySchema-ContactInformation
>
> There have also been some ambitious suggestions to revise the
> 'post-1.0' Contact schema above, from modestly to radically, to make
> it even more flexible for today's mix of physical and electronic
> address types. There is a JIRA issue for this, which includes a
> summary description and pointer to a December 2009 discussion on this
> topic with Michael Black of PAHMA and several of our Museum
> Informatics folks:
>
> "Revise the Contact info schema"
> http://issues.collectionspace.org/browse/CSPACE-836
>
> We very much invite your - ongoing - feedback on the Contact record
> schema, with respect to meeting SMK's needs.
>
> Aron
>
> P.S. It's also my personal hope that we will at some point support
> import and export of Contacts in the standard vCard format, although
> this might not be on the 1.0/2.0 roadmap.
>
PS
Patrick Schmitz
Wed, Jun 23, 2010 4:05 PM
Agreed with Aron's comments, and would add that yes, I think that
Organization is a good way to relate Persons to one another, e.g., w.r.t.
the museum political/structural organization.
However, if what you want is to model personal or familial relationships
between and among Persons, this can be done with a combination of Person and
Relations. We will be adding hierarchy support to the Person (and several
other) Authority services soon, and this will allow modeling of families,
spice (that's the plural of spouse, right?), etc. Doing it this way (rather
than Orgs) will make things like search work better, so you can search for
gifts from a family and it will find all gifts from the family as a unit,
from any marriages as a unit, as well as all the individuals in the family.
If you really want to import FOAF files, we could model that too, but we
have no plans on the books for that.
Patrick
Do you have any further words of comfort about the
- the ability to add new fields (CV, conferences attended,
qualifications etc.) which I hope we can accomplish via
schema extensions either to the Contact or Person schemas.
Contact records are amenable to schema extension.
- the ability to mark individual fields for internet or intranet
publishing
You can let us know if this response might meet your needs for this:
through the Person service, you can programmatically retrieve
Person records and their associated Contact record(s), and
extract data from selected Contact record fields for
re-publishing. As one of many options, a web application
that generates dynamic pages - using PHP, ColdFusion, JSP,
ASP, etc. - could presumably make these calls directly to the
CollectionSpace services layer.
- support for images (presumeably supported via media snapshot
relationship?)
Interesting. Any record can be related to any other in
CollectionSpace through relationship / relations records, and
Media records are coming in 0.9, so as one option, it might
be possible in this way to relate, say, a Media record
referring to a portrait photograph to a Person record or a
Media record referring to a photograph of a group at a
conference to multiple depicted Peron records.
I'm unclear on whether it's preferable to organise Persons
via internal fields as Angela suggested, or by relating
Person records within a hierarchy of Organisations (if I've
understood correctly this is also a possibility).
Perhaps others might wish to comment on this ...
Encryption would be necessary for some of our confidential
employee data used by our Administration department. However,
we don't have immediate plans to migrate this to CollectionSpace.
I'd like to soon use a local deployment of CollectionSpace
for trying this out. ie. serving Person data to an intranet
site from which we can implement the ability, via web
services, to update/edit employee details (for test use
only). Should 0.8 be able to handle this?
Yes, with the caveat that the Contact record schema for 0.8
is rudimentary. Nonetheless, any mechanism you create now
for retrieving / editing employee details has a high
likelihood - schema changes notwithstanding - of working 'as
is', or with only minor modification, when accessing future
releases as well.
Aron
Aron Roberts
Sendt: 22. juni 2010 18:53
Til: Christopher Pott
Cc: talk@lists.collectionspace.org
Emne: Re: [Talk] employee data in CollectionSpace
Chris wrote:
We have a requirement for storage of some basic data
museum employees with the possibility to make (some) of
phone number, name, department etc.) available to a web site (and
probably some other applications) via a web service.
Would it be appropriate to store this data within
Person Name Authority records?
A followup to the two very interesting messages so far in
- Angela's comment on the use of the "Person's occupation" and
"Person's group" fields.
- Patrick's preview of future functionality around tagging and
filtering of person authority records, and his comment on securing
personally identifiable information (e.g. identification of
as a "donor").
Yes, it can be appropriate to store basic contact and affiliation
information for museum employees in CollectionSpace.
In the CollectionSpace services layer, there is today a very
rudimentary Contact record, at least a placeholder for future
functionality. There is a many to one relationship between
and Person (and Organization) records:
PersonAuthority ==> 0...n Persons
|__ each Person ==> 0..n Contacts
OrganizationAuthority => 0...n Organizations
|__ each Organization ==> 0...n Contacts
These RESTful API documents have been recently updated to describe
how you can add Contacts to Persons and Organizations, via
and Organization services:
+REST+APIs+-+Release+v0.8#PersonServiceRESTAPIs-Releasev0.8-ContactCRU
ervice+REST+APIs+-+Release+v0.8#OrganizationServiceRESTAPIs-Releasev0.
8-ContactCRUDLservices
There will be full-stack support for adding Contacts
in a future release. The current wireframes / designs for this:
ame+Authority
The current Contact schema looks like this:
In 0.8:
+Schema+-+Limited+for+Release+0.8 (see the "Contact Information"
subhead)
For post-1.0 implementation:
+Schema#NameAuthoritySchema-ContactInformation
There have also been some ambitious suggestions to revise the
'post-1.0' Contact schema above, from modestly to
it even more flexible for today's mix of physical and electronic
address types. There is a JIRA issue for this, which includes a
summary description and pointer to a December 2009
topic with Michael Black of PAHMA and several of our Museum
Informatics folks:
"Revise the Contact info schema"
http://issues.collectionspace.org/browse/CSPACE-836
We very much invite your - ongoing - feedback on the
schema, with respect to meeting SMK's needs.
Aron
P.S. It's also my personal hope that we will at some point support
import and export of Contacts in the standard vCard format,
this might not be on the 1.0/2.0 roadmap.
Agreed with Aron's comments, and would add that yes, I think that
Organization is a good way to relate Persons to one another, e.g., w.r.t.
the museum political/structural organization.
However, if what you want is to model personal or familial relationships
between and among Persons, this can be done with a combination of Person and
Relations. We will be adding hierarchy support to the Person (and several
other) Authority services soon, and this will allow modeling of families,
spice (that's the plural of spouse, right?), etc. Doing it this way (rather
than Orgs) will make things like search work better, so you can search for
gifts from a family and it will find all gifts from the family as a unit,
from any marriages as a unit, as well as all the individuals in the family.
If you really want to import FOAF files, we could model that too, but we
have no plans on the books for that.
Patrick
> -----Original Message-----
> From: talk-bounces@lists.collectionspace.org
> [mailto:talk-bounces@lists.collectionspace.org] On Behalf Of
> Aron Roberts
> Sent: Wednesday, June 23, 2010 7:14 AM
> To: Christopher Pott
> Cc: talk@lists.collectionspace.org
> Subject: Re: [Talk] employee data in CollectionSpace
>
> On Wed, Jun 23, 2010 at 4:38 AM, Christopher Pott
> <Christopher.Pott@smk.dk> wrote:
> > Do you have any further words of comfort about the
> following points?...
> >
> > * the ability to add new fields (CV, conferences attended,
> qualifications etc.) which I hope we can accomplish via
> schema extensions either to the Contact or Person schemas.
>
> Contact records are amenable to schema extension.
>
> > * the ability to mark individual fields for internet or intranet
> > publishing
>
> You can let us know if this response might meet your needs for this:
> through the Person service, you can programmatically retrieve
> Person records and their associated Contact record(s), and
> extract data from selected Contact record fields for
> re-publishing. As one of many options, a web application
> that generates dynamic pages - using PHP, ColdFusion, JSP,
> ASP, etc. - could presumably make these calls directly to the
> CollectionSpace services layer.
>
> > * support for images (presumeably supported via media snapshot
> > relationship?)
>
> Interesting. Any record can be related to any other in
> CollectionSpace through relationship / relations records, and
> Media records are coming in 0.9, so as one option, it might
> be possible in this way to relate, say, a Media record
> referring to a portrait photograph to a Person record or a
> Media record referring to a photograph of a group at a
> conference to multiple depicted Peron records.
>
> > I'm unclear on whether it's preferable to organise Persons
> via internal fields as Angela suggested, or by relating
> Person records within a hierarchy of Organisations (if I've
> understood correctly this is also a possibility).
>
> Perhaps others might wish to comment on this ...
>
> > Encryption would be necessary for some of our confidential
> employee data used by our Administration department. However,
> we don't have immediate plans to migrate this to CollectionSpace.
> >
> > I'd like to soon use a local deployment of CollectionSpace
> for trying this out. ie. serving Person data to an intranet
> site from which we can implement the ability, via web
> services, to update/edit employee details (for test use
> only). Should 0.8 be able to handle this?
>
> Yes, with the caveat that the Contact record schema for 0.8
> is rudimentary. Nonetheless, any mechanism you create now
> for retrieving / editing employee details has a high
> likelihood - schema changes notwithstanding - of working 'as
> is', or with only minor modification, when accessing future
> releases as well.
>
> Aron
>
> >
> > /Chris
> >
> > Developer, Corpus Project
> > Statens Museum for Kunst (National Gallery of Denmark)
> >
> > -----Oprindelig meddelelse-----
> > Fra: aronroberts@gmail.com [mailto:aronroberts@gmail.com]
> På vegne af
> > Aron Roberts
> > Sendt: 22. juni 2010 18:53
> > Til: Christopher Pott
> > Cc: talk@lists.collectionspace.org
> > Emne: Re: [Talk] employee data in CollectionSpace
> >
> > Chris wrote:
> >> We have a requirement for storage of some basic data
> relating to all
> > museum employees with the possibility to make (some) of
> this data (eg.
> > phone number, name, department etc.) available to a web site (and
> > probably some other applications) via a web service.
> >
> >> Would it be appropriate to store this data within
> CollectionSpace as
> > Person Name Authority records?
> >
> > A followup to the two very interesting messages so far in
> this thread:
> > - Angela's comment on the use of the "Person's occupation" and
> > "Person's group" fields.
> > - Patrick's preview of future functionality around tagging and
> > filtering of person authority records, and his comment on securing
> > personally identifiable information (e.g. identification of
> a person
> > as a "donor").
> >
> > Yes, it can be appropriate to store basic contact and affiliation
> > information for museum employees in CollectionSpace.
> >
> > In the CollectionSpace services layer, there is today a *very*
> > rudimentary Contact record, at least a placeholder for future
> > functionality. There is a many to one relationship between
> Contacts
> > and Person (and Organization) records:
> >
> > PersonAuthority ==> 0...n Persons
> > |__ each Person ==> 0..n Contacts
> >
> > OrganizationAuthority => 0...n Organizations
> > |__ each Organization ==> 0...n Contacts
> >
> > These RESTful API documents have been recently updated to describe
> > how you can add Contacts to Persons and Organizations, via
> the Person
> > and Organization services:
> >
> >
> http://wiki.collectionspace.org/display/collectionspace/Person+Service
> >
> +REST+APIs+-+Release+v0.8#PersonServiceRESTAPIs-Releasev0.8-ContactCRU
> > DLservices
> >
> >
> http://wiki.collectionspace.org/display/collectionspace/Organization+S
> >
> ervice+REST+APIs+-+Release+v0.8#OrganizationServiceRESTAPIs-Releasev0.
> > 8-ContactCRUDLservices
> >
> > There will be full-stack support for adding Contacts
> through the UI
> > in a future release. The current wireframes / designs for this:
> >
> >
> >
> http://wiki.collectionspace.org/display/collectionspace/Wireframes+-+N
> > ame+Authority
> >
> > The current Contact schema looks like this:
> >
> > In 0.8:
> >
> >
> http://wiki.collectionspace.org/display/collectionspace/Name+Authority
> > +Schema+-+Limited+for+Release+0.8 (see the "Contact Information"
> > subhead)
> >
> > For post-1.0 implementation:
> >
> >
> http://wiki.collectionspace.org/display/collectionspace/Name+Authority
> > +Schema#NameAuthoritySchema-ContactInformation
> >
> > There have also been some ambitious suggestions to revise the
> > 'post-1.0' Contact schema above, from modestly to
> radically, to make
> > it even more flexible for today's mix of physical and electronic
> > address types. There is a JIRA issue for this, which includes a
> > summary description and pointer to a December 2009
> discussion on this
> > topic with Michael Black of PAHMA and several of our Museum
> > Informatics folks:
> >
> > "Revise the Contact info schema"
> > http://issues.collectionspace.org/browse/CSPACE-836
> >
> > We very much invite your - ongoing - feedback on the
> Contact record
> > schema, with respect to meeting SMK's needs.
> >
> > Aron
> >
> > P.S. It's also my personal hope that we will at some point support
> > import and export of Contacts in the standard vCard format,
> although
> > this might not be on the 1.0/2.0 roadmap.
> >
>
> _______________________________________________
> Talk mailing list
> Talk@lists.collectionspace.org
> http://lists.collectionspace.org/mailman/listinfo/talk_lists.c
> ollectionspace.org
>
CP
Christopher Pott
Thu, Jun 24, 2010 7:33 AM
Thanks for answering all my questions. There's just one point I'm still unclear about.....
- the ability to mark individual fields for internet or intranet >>publishing
You can let us know if this response might meet your needs for this:
through the Person service, you can programmatically retrieve Person
records and their associated Contact record(s), and extract data from
selected Contact record fields for re-publishing. As one of many
options, a web application that generates dynamic pages - using PHP,
ColdFusion, JSP, ASP, etc. - could presumably make these calls
directly to the CollectionSpace services layer.
That describes broadly what we'd like to accomplish, but what I was trying to describe was a detail related to this scenario - that we may need to allow an employee to mark any of their own Contact fields as a field which they would allow to be published internally, externally, niether or both. We could create yet more fields (via schema extension) to hold this information but I just wanted to check if there wasn't already a method in place related to capturing metadata about a field - in this case the fields visibility within different web domains.
/Chris
-----Oprindelig meddelelse-----
Fra: aronroberts@gmail.com [mailto:aronroberts@gmail.com] På vegne af Aron Roberts
Sendt: 23. juni 2010 16:14
Til: Christopher Pott
Cc: talk@lists.collectionspace.org
Emne: Re: [Talk] employee data in CollectionSpace
On Wed, Jun 23, 2010 at 4:38 AM, Christopher Pott
Christopher.Pott@smk.dk wrote:
Do you have any further words of comfort about the following points?...
- the ability to add new fields (CV, conferences attended, qualifications etc.) which I hope we can accomplish via schema extensions either to the Contact or Person schemas.
Contact records are amenable to schema extension.
- the ability to mark individual fields for internet or intranet publishing
You can let us know if this response might meet your needs for this:
through the Person service, you can programmatically retrieve Person
records and their associated Contact record(s), and extract data from
selected Contact record fields for re-publishing. As one of many
options, a web application that generates dynamic pages - using PHP,
ColdFusion, JSP, ASP, etc. - could presumably make these calls
directly to the CollectionSpace services layer.
- support for images (presumeably supported via media snapshot relationship?)
Interesting. Any record can be related to any other in
CollectionSpace through relationship / relations records, and Media
records are coming in 0.9, so as one option, it might be possible in
this way to relate, say, a Media record referring to a portrait
photograph to a Person record or a Media record referring to a
photograph of a group at a conference to multiple depicted Peron
records.
I'm unclear on whether it's preferable to organise Persons via internal fields as Angela suggested, or by relating Person records within a hierarchy of Organisations (if I've understood correctly this is also a possibility).
Perhaps others might wish to comment on this ...
Encryption would be necessary for some of our confidential employee data used by our Administration department. However, we don't have immediate plans to migrate this to CollectionSpace.
I'd like to soon use a local deployment of CollectionSpace for trying this out. ie. serving Person data to an intranet site from which we can implement the ability, via web services, to update/edit employee details (for test use only). Should 0.8 be able to handle this?
Yes, with the caveat that the Contact record schema for 0.8 is
rudimentary. Nonetheless, any mechanism you create now for retrieving
/ editing employee details has a high likelihood - schema changes
notwithstanding - of working 'as is', or with only minor modification,
when accessing future releases as well.
Aron
We have a requirement for storage of some basic data relating to all
museum employees with the possibility to make (some) of this data (eg.
phone number, name, department etc.) available to a web site (and
probably some other applications) via a web service.
Would it be appropriate to store this data within CollectionSpace as
Person Name Authority records?
A followup to the two very interesting messages so far in this thread:
- Angela's comment on the use of the "Person's occupation" and
"Person's group" fields.
- Patrick's preview of future functionality around tagging and
filtering of person authority records, and his comment on securing
personally identifiable information (e.g. identification of a person
as a "donor").
Yes, it can be appropriate to store basic contact and affiliation
information for museum employees in CollectionSpace.
In the CollectionSpace services layer, there is today a very
rudimentary Contact record, at least a placeholder for future
functionality. There is a many to one relationship between Contacts
and Person (and Organization) records:
PersonAuthority ==> 0...n Persons
|__ each Person ==> 0..n Contacts
OrganizationAuthority => 0...n Organizations
|__ each Organization ==> 0...n Contacts
These RESTful API documents have been recently updated to describe
how you can add Contacts to Persons and Organizations, via the Person
and Organization services:
http://wiki.collectionspace.org/display/collectionspace/Person+Service+REST+APIs+-+Release+v0.8#PersonServiceRESTAPIs-Releasev0.8-ContactCRUDLservices
http://wiki.collectionspace.org/display/collectionspace/Organization+Service+REST+APIs+-+Release+v0.8#OrganizationServiceRESTAPIs-Releasev0.8-ContactCRUDLservices
There will be full-stack support for adding Contacts through the UI
in a future release. The current wireframes / designs for this:
http://wiki.collectionspace.org/display/collectionspace/Wireframes+-+Name+Authority
The current Contact schema looks like this:
In 0.8:
http://wiki.collectionspace.org/display/collectionspace/Name+Authority+Schema+-+Limited+for+Release+0.8
(see the "Contact Information" subhead)
For post-1.0 implementation:
http://wiki.collectionspace.org/display/collectionspace/Name+Authority+Schema#NameAuthoritySchema-ContactInformation
There have also been some ambitious suggestions to revise the
'post-1.0' Contact schema above, from modestly to radically, to make
it even more flexible for today's mix of physical and electronic
address types. There is a JIRA issue for this, which includes a
summary description and pointer to a December 2009 discussion on this
topic with Michael Black of PAHMA and several of our Museum
Informatics folks:
"Revise the Contact info schema"
http://issues.collectionspace.org/browse/CSPACE-836
We very much invite your - ongoing - feedback on the Contact record
schema, with respect to meeting SMK's needs.
Aron
P.S. It's also my personal hope that we will at some point support
import and export of Contacts in the standard vCard format, although
this might not be on the 1.0/2.0 roadmap.
Thanks for answering all my questions. There's just one point I'm still unclear about.....
>> * the ability to mark individual fields for internet or intranet >>publishing
> You can let us know if this response might meet your needs for this:
>through the Person service, you can programmatically retrieve Person
>records and their associated Contact record(s), and extract data from
>selected Contact record fields for re-publishing. As one of many
>options, a web application that generates dynamic pages - using PHP,
>ColdFusion, JSP, ASP, etc. - could presumably make these calls
>directly to the CollectionSpace services layer.
That describes broadly what we'd like to accomplish, but what I was trying to describe was a detail related to this scenario - that we may need to allow an employee to mark any of their own Contact fields as a field which they would allow to be published internally, externally, niether or both. We could create yet more fields (via schema extension) to hold this information but I just wanted to check if there wasn't already a method in place related to capturing metadata about a field - in this case the fields visibility within different web domains.
/Chris
-----Oprindelig meddelelse-----
Fra: aronroberts@gmail.com [mailto:aronroberts@gmail.com] På vegne af Aron Roberts
Sendt: 23. juni 2010 16:14
Til: Christopher Pott
Cc: talk@lists.collectionspace.org
Emne: Re: [Talk] employee data in CollectionSpace
On Wed, Jun 23, 2010 at 4:38 AM, Christopher Pott
<Christopher.Pott@smk.dk> wrote:
> Do you have any further words of comfort about the following points?...
>
> * the ability to add new fields (CV, conferences attended, qualifications etc.) which I hope we can accomplish via schema extensions either to the Contact or Person schemas.
Contact records are amenable to schema extension.
> * the ability to mark individual fields for internet or intranet publishing
You can let us know if this response might meet your needs for this:
through the Person service, you can programmatically retrieve Person
records and their associated Contact record(s), and extract data from
selected Contact record fields for re-publishing. As one of many
options, a web application that generates dynamic pages - using PHP,
ColdFusion, JSP, ASP, etc. - could presumably make these calls
directly to the CollectionSpace services layer.
> * support for images (presumeably supported via media snapshot relationship?)
Interesting. Any record can be related to any other in
CollectionSpace through relationship / relations records, and Media
records are coming in 0.9, so as one option, it might be possible in
this way to relate, say, a Media record referring to a portrait
photograph to a Person record or a Media record referring to a
photograph of a group at a conference to multiple depicted Peron
records.
> I'm unclear on whether it's preferable to organise Persons via internal fields as Angela suggested, or by relating Person records within a hierarchy of Organisations (if I've understood correctly this is also a possibility).
Perhaps others might wish to comment on this ...
> Encryption would be necessary for some of our confidential employee data used by our Administration department. However, we don't have immediate plans to migrate this to CollectionSpace.
>
> I'd like to soon use a local deployment of CollectionSpace for trying this out. ie. serving Person data to an intranet site from which we can implement the ability, via web services, to update/edit employee details (for test use only). Should 0.8 be able to handle this?
Yes, with the caveat that the Contact record schema for 0.8 is
rudimentary. Nonetheless, any mechanism you create now for retrieving
/ editing employee details has a high likelihood - schema changes
notwithstanding - of working 'as is', or with only minor modification,
when accessing future releases as well.
Aron
>
> /Chris
>
> Developer, Corpus Project
> Statens Museum for Kunst (National Gallery of Denmark)
>
> -----Oprindelig meddelelse-----
> Fra: aronroberts@gmail.com [mailto:aronroberts@gmail.com] På vegne af Aron Roberts
> Sendt: 22. juni 2010 18:53
> Til: Christopher Pott
> Cc: talk@lists.collectionspace.org
> Emne: Re: [Talk] employee data in CollectionSpace
>
> Chris wrote:
>> We have a requirement for storage of some basic data relating to all
> museum employees with the possibility to make (some) of this data (eg.
> phone number, name, department etc.) available to a web site (and
> probably some other applications) via a web service.
>
>> Would it be appropriate to store this data within CollectionSpace as
> Person Name Authority records?
>
> A followup to the two very interesting messages so far in this thread:
> - Angela's comment on the use of the "Person's occupation" and
> "Person's group" fields.
> - Patrick's preview of future functionality around tagging and
> filtering of person authority records, and his comment on securing
> personally identifiable information (e.g. identification of a person
> as a "donor").
>
> Yes, it can be appropriate to store basic contact and affiliation
> information for museum employees in CollectionSpace.
>
> In the CollectionSpace services layer, there is today a *very*
> rudimentary Contact record, at least a placeholder for future
> functionality. There is a many to one relationship between Contacts
> and Person (and Organization) records:
>
> PersonAuthority ==> 0...n Persons
> |__ each Person ==> 0..n Contacts
>
> OrganizationAuthority => 0...n Organizations
> |__ each Organization ==> 0...n Contacts
>
> These RESTful API documents have been recently updated to describe
> how you can add Contacts to Persons and Organizations, via the Person
> and Organization services:
>
> http://wiki.collectionspace.org/display/collectionspace/Person+Service+REST+APIs+-+Release+v0.8#PersonServiceRESTAPIs-Releasev0.8-ContactCRUDLservices
>
> http://wiki.collectionspace.org/display/collectionspace/Organization+Service+REST+APIs+-+Release+v0.8#OrganizationServiceRESTAPIs-Releasev0.8-ContactCRUDLservices
>
> There will be full-stack support for adding Contacts through the UI
> in a future release. The current wireframes / designs for this:
>
> http://wiki.collectionspace.org/display/collectionspace/Wireframes+-+Name+Authority
>
> The current Contact schema looks like this:
>
> In 0.8:
>
> http://wiki.collectionspace.org/display/collectionspace/Name+Authority+Schema+-+Limited+for+Release+0.8
> (see the "Contact Information" subhead)
>
> For post-1.0 implementation:
>
> http://wiki.collectionspace.org/display/collectionspace/Name+Authority+Schema#NameAuthoritySchema-ContactInformation
>
> There have also been some ambitious suggestions to revise the
> 'post-1.0' Contact schema above, from modestly to radically, to make
> it even more flexible for today's mix of physical and electronic
> address types. There is a JIRA issue for this, which includes a
> summary description and pointer to a December 2009 discussion on this
> topic with Michael Black of PAHMA and several of our Museum
> Informatics folks:
>
> "Revise the Contact info schema"
> http://issues.collectionspace.org/browse/CSPACE-836
>
> We very much invite your - ongoing - feedback on the Contact record
> schema, with respect to meeting SMK's needs.
>
> Aron
>
> P.S. It's also my personal hope that we will at some point support
> import and export of Contacts in the standard vCard format, although
> this might not be on the 1.0/2.0 roadmap.
>
AR
Aron Roberts
Thu, Jun 24, 2010 1:48 PM
Thanks for answering all my questions. There's just one point I'm still unclear about.....
- the ability to mark individual fields for internet or intranet >>publishing
You can let us know if this response might meet your needs for this:
through the Person service, you can programmatically retrieve Person
records and their associated Contact record(s), and extract data from
selected Contact record fields for re-publishing. As one of many
options, a web application that generates dynamic pages - using PHP,
ColdFusion, JSP, ASP, etc. - could presumably make these calls
directly to the CollectionSpace services layer.
That describes broadly what we'd like to accomplish, but what I was trying to describe was a detail related to this scenario - that we may need to allow an employee to mark any of their own Contact fields as a field which they would allow to be published internally, externally, niether or both. We could create yet more fields (via schema extension) to hold this information but I just wanted to check if there wasn't already a method in place related to capturing metadata about a field - in this case the fields visibility within different web domains.
Others may wish to comment or correct; here are some initial
thoughts regarding your requirement:
The Contact schema - and to my knowledge, schemas for objects and
procedural entities more generally - currently does not / do not
expose any metadata on a per-field basis, such as the 'permission to
publish this field [internally|externally]' flag you describe.
(Having that is a really interesting idea, by the way.)
If you add fields that you don't wish to have automatically
published, to an extension schema for Contacts, those fields won't
automatically appear in the web UI in a CollectionSpace system. (To
enable those to show up in the UI, you'd also need to make changes in
the App and UI layers; if you don't, those fields will appear only in
services calls.)
However, values in those fields will be indexed, and the records
containing a particular value will be returned from a keyword search
on that value, even if the fields themselves will not be displayed in
summary listings of search results, or in full records.
In addition, as noted above, those extension fields will still be
retrievable via direct calls to the Person or Organization service, to
retrieve Contact record(s), if any, for a particular person or
organization. At best, placing the fields more likely to be
non-public in an extension schema is a form of "security through
obscurity."
Thinking out loud - this is untested, and hence may not work, but
... you might restrict access to the resource URL paths that allow
access to Contact records (e.g. .../Persons/{person ID}/Contacts) only
to a particular broad role, such as a ROLE_MUSEUM_STAFF role, as well
as to any applicable administrator-related roles. Presumably, that
would permit only logged in users with one or more of those roles
assigned to their accounts to access Contact information.
You could then set up an account for a publishing script or program,
perhaps giving it a different role, such as
ROLE_CONTACT_INFO_PUBLISHER, and give it read-only access to the
Contact URL resource paths. That script or program would then contain
its own, configurable or hard-coded, logic for determining what fields
should be published on the web, internally or externally to your
institution.
There is a functionality requirement, post release 1.0, to
facilitate more granular access controls, extending to the record
(resource) level and probably ultimately, to the field (attribute)
level. That might at least indirectly facilitate the behavior you're
describing.
Aron
Do you have any further words of comfort about the following points?...
- the ability to add new fields (CV, conferences attended, qualifications etc.) which I hope we can accomplish via schema extensions either to the Contact or Person schemas.
Contact records are amenable to schema extension.
- the ability to mark individual fields for internet or intranet publishing
You can let us know if this response might meet your needs for this:
through the Person service, you can programmatically retrieve Person
records and their associated Contact record(s), and extract data from
selected Contact record fields for re-publishing. As one of many
options, a web application that generates dynamic pages - using PHP,
ColdFusion, JSP, ASP, etc. - could presumably make these calls
directly to the CollectionSpace services layer.
- support for images (presumeably supported via media snapshot relationship?)
Interesting. Any record can be related to any other in
CollectionSpace through relationship / relations records, and Media
records are coming in 0.9, so as one option, it might be possible in
this way to relate, say, a Media record referring to a portrait
photograph to a Person record or a Media record referring to a
photograph of a group at a conference to multiple depicted Peron
records.
I'm unclear on whether it's preferable to organise Persons via internal fields as Angela suggested, or by relating Person records within a hierarchy of Organisations (if I've understood correctly this is also a possibility).
Perhaps others might wish to comment on this ...
Encryption would be necessary for some of our confidential employee data used by our Administration department. However, we don't have immediate plans to migrate this to CollectionSpace.
I'd like to soon use a local deployment of CollectionSpace for trying this out. ie. serving Person data to an intranet site from which we can implement the ability, via web services, to update/edit employee details (for test use only). Should 0.8 be able to handle this?
Yes, with the caveat that the Contact record schema for 0.8 is
rudimentary. Nonetheless, any mechanism you create now for retrieving
/ editing employee details has a high likelihood - schema changes
notwithstanding - of working 'as is', or with only minor modification,
when accessing future releases as well.
Aron
We have a requirement for storage of some basic data relating to all
museum employees with the possibility to make (some) of this data (eg.
phone number, name, department etc.) available to a web site (and
probably some other applications) via a web service.
Would it be appropriate to store this data within CollectionSpace as
Person Name Authority records?
A followup to the two very interesting messages so far in this thread:
- Angela's comment on the use of the "Person's occupation" and
"Person's group" fields.
- Patrick's preview of future functionality around tagging and
filtering of person authority records, and his comment on securing
personally identifiable information (e.g. identification of a person
as a "donor").
Yes, it can be appropriate to store basic contact and affiliation
information for museum employees in CollectionSpace.
In the CollectionSpace services layer, there is today a very
rudimentary Contact record, at least a placeholder for future
functionality. There is a many to one relationship between Contacts
and Person (and Organization) records:
PersonAuthority ==> 0...n Persons
|__ each Person ==> 0..n Contacts
OrganizationAuthority => 0...n Organizations
|__ each Organization ==> 0...n Contacts
These RESTful API documents have been recently updated to describe
how you can add Contacts to Persons and Organizations, via the Person
and Organization services:
http://wiki.collectionspace.org/display/collectionspace/Person+Service+REST+APIs+-+Release+v0.8#PersonServiceRESTAPIs-Releasev0.8-ContactCRUDLservices
http://wiki.collectionspace.org/display/collectionspace/Organization+Service+REST+APIs+-+Release+v0.8#OrganizationServiceRESTAPIs-Releasev0.8-ContactCRUDLservices
There will be full-stack support for adding Contacts through the UI
in a future release. The current wireframes / designs for this:
http://wiki.collectionspace.org/display/collectionspace/Wireframes+-+Name+Authority
The current Contact schema looks like this:
In 0.8:
http://wiki.collectionspace.org/display/collectionspace/Name+Authority+Schema+-+Limited+for+Release+0.8
(see the "Contact Information" subhead)
For post-1.0 implementation:
http://wiki.collectionspace.org/display/collectionspace/Name+Authority+Schema#NameAuthoritySchema-ContactInformation
There have also been some ambitious suggestions to revise the
'post-1.0' Contact schema above, from modestly to radically, to make
it even more flexible for today's mix of physical and electronic
address types. There is a JIRA issue for this, which includes a
summary description and pointer to a December 2009 discussion on this
topic with Michael Black of PAHMA and several of our Museum
Informatics folks:
"Revise the Contact info schema"
http://issues.collectionspace.org/browse/CSPACE-836
We very much invite your - ongoing - feedback on the Contact record
schema, with respect to meeting SMK's needs.
Aron
P.S. It's also my personal hope that we will at some point support
import and export of Contacts in the standard vCard format, although
this might not be on the 1.0/2.0 roadmap.
Hi Chris,
On Thu, Jun 24, 2010 at 12:33 AM, Christopher Pott
<Christopher.Pott@smk.dk> wrote:
> Thanks for answering all my questions. There's just one point I'm still unclear about.....
>
>>> * the ability to mark individual fields for internet or intranet >>publishing
>
>> You can let us know if this response might meet your needs for this:
>>through the Person service, you can programmatically retrieve Person
>>records and their associated Contact record(s), and extract data from
>>selected Contact record fields for re-publishing. As one of many
>>options, a web application that generates dynamic pages - using PHP,
>>ColdFusion, JSP, ASP, etc. - could presumably make these calls
>>directly to the CollectionSpace services layer.
>
> That describes broadly what we'd like to accomplish, but what I was trying to describe was a detail related to this scenario - that we may need to allow an employee to mark any of their own Contact fields as a field which they would allow to be published internally, externally, niether or both. We could create yet more fields (via schema extension) to hold this information but I just wanted to check if there wasn't already a method in place related to capturing metadata about a field - in this case the fields visibility within different web domains.
Others may wish to comment or correct; here are some initial
thoughts regarding your requirement:
The Contact schema - and to my knowledge, schemas for objects and
procedural entities more generally - currently does not / do not
expose any metadata on a per-field basis, such as the 'permission to
publish this field [internally|externally]' flag you describe.
(Having that is a really interesting idea, by the way.)
If you add fields that you don't wish to have automatically
published, to an extension schema for Contacts, those fields won't
automatically appear in the web UI in a CollectionSpace system. (To
enable those to show up in the UI, you'd also need to make changes in
the App and UI layers; if you don't, those fields will appear only in
services calls.)
However, values in those fields will be indexed, and the records
containing a particular value will be returned from a keyword search
on that value, even if the fields themselves will not be displayed in
summary listings of search results, or in full records.
In addition, as noted above, those extension fields will still be
retrievable via direct calls to the Person or Organization service, to
retrieve Contact record(s), if any, for a particular person or
organization. At best, placing the fields more likely to be
non-public in an extension schema is a form of "security through
obscurity."
Thinking out loud - this is untested, and hence may not work, but
... you might restrict access to the resource URL paths that allow
access to Contact records (e.g. .../Persons/{person ID}/Contacts) only
to a particular broad role, such as a ROLE_MUSEUM_STAFF role, as well
as to any applicable administrator-related roles. Presumably, that
would permit only logged in users with one or more of those roles
assigned to their accounts to access Contact information.
You could then set up an account for a publishing script or program,
perhaps giving it a different role, such as
ROLE_CONTACT_INFO_PUBLISHER, and give it read-only access to the
Contact URL resource paths. That script or program would then contain
its own, configurable or hard-coded, logic for determining what fields
should be published on the web, internally or externally to your
institution.
There is a functionality requirement, post release 1.0, to
facilitate more granular access controls, extending to the record
(resource) level and probably ultimately, to the field (attribute)
level. That might at least indirectly facilitate the behavior you're
describing.
Aron
>
> /Chris
>
> -----Oprindelig meddelelse-----
> Fra: aronroberts@gmail.com [mailto:aronroberts@gmail.com] På vegne af Aron Roberts
> Sendt: 23. juni 2010 16:14
> Til: Christopher Pott
> Cc: talk@lists.collectionspace.org
> Emne: Re: [Talk] employee data in CollectionSpace
>
> On Wed, Jun 23, 2010 at 4:38 AM, Christopher Pott
> <Christopher.Pott@smk.dk> wrote:
>> Do you have any further words of comfort about the following points?...
>>
>> * the ability to add new fields (CV, conferences attended, qualifications etc.) which I hope we can accomplish via schema extensions either to the Contact or Person schemas.
>
> Contact records are amenable to schema extension.
>
>> * the ability to mark individual fields for internet or intranet publishing
>
> You can let us know if this response might meet your needs for this:
> through the Person service, you can programmatically retrieve Person
> records and their associated Contact record(s), and extract data from
> selected Contact record fields for re-publishing. As one of many
> options, a web application that generates dynamic pages - using PHP,
> ColdFusion, JSP, ASP, etc. - could presumably make these calls
> directly to the CollectionSpace services layer.
>
>> * support for images (presumeably supported via media snapshot relationship?)
>
> Interesting. Any record can be related to any other in
> CollectionSpace through relationship / relations records, and Media
> records are coming in 0.9, so as one option, it might be possible in
> this way to relate, say, a Media record referring to a portrait
> photograph to a Person record or a Media record referring to a
> photograph of a group at a conference to multiple depicted Peron
> records.
>
>> I'm unclear on whether it's preferable to organise Persons via internal fields as Angela suggested, or by relating Person records within a hierarchy of Organisations (if I've understood correctly this is also a possibility).
>
> Perhaps others might wish to comment on this ...
>
>> Encryption would be necessary for some of our confidential employee data used by our Administration department. However, we don't have immediate plans to migrate this to CollectionSpace.
>>
>> I'd like to soon use a local deployment of CollectionSpace for trying this out. ie. serving Person data to an intranet site from which we can implement the ability, via web services, to update/edit employee details (for test use only). Should 0.8 be able to handle this?
>
> Yes, with the caveat that the Contact record schema for 0.8 is
> rudimentary. Nonetheless, any mechanism you create now for retrieving
> / editing employee details has a high likelihood - schema changes
> notwithstanding - of working 'as is', or with only minor modification,
> when accessing future releases as well.
>
> Aron
>
>>
>> /Chris
>>
>> Developer, Corpus Project
>> Statens Museum for Kunst (National Gallery of Denmark)
>>
>> -----Oprindelig meddelelse-----
>> Fra: aronroberts@gmail.com [mailto:aronroberts@gmail.com] På vegne af Aron Roberts
>> Sendt: 22. juni 2010 18:53
>> Til: Christopher Pott
>> Cc: talk@lists.collectionspace.org
>> Emne: Re: [Talk] employee data in CollectionSpace
>>
>> Chris wrote:
>>> We have a requirement for storage of some basic data relating to all
>> museum employees with the possibility to make (some) of this data (eg.
>> phone number, name, department etc.) available to a web site (and
>> probably some other applications) via a web service.
>>
>>> Would it be appropriate to store this data within CollectionSpace as
>> Person Name Authority records?
>>
>> A followup to the two very interesting messages so far in this thread:
>> - Angela's comment on the use of the "Person's occupation" and
>> "Person's group" fields.
>> - Patrick's preview of future functionality around tagging and
>> filtering of person authority records, and his comment on securing
>> personally identifiable information (e.g. identification of a person
>> as a "donor").
>>
>> Yes, it can be appropriate to store basic contact and affiliation
>> information for museum employees in CollectionSpace.
>>
>> In the CollectionSpace services layer, there is today a *very*
>> rudimentary Contact record, at least a placeholder for future
>> functionality. There is a many to one relationship between Contacts
>> and Person (and Organization) records:
>>
>> PersonAuthority ==> 0...n Persons
>> |__ each Person ==> 0..n Contacts
>>
>> OrganizationAuthority => 0...n Organizations
>> |__ each Organization ==> 0...n Contacts
>>
>> These RESTful API documents have been recently updated to describe
>> how you can add Contacts to Persons and Organizations, via the Person
>> and Organization services:
>>
>> http://wiki.collectionspace.org/display/collectionspace/Person+Service+REST+APIs+-+Release+v0.8#PersonServiceRESTAPIs-Releasev0.8-ContactCRUDLservices
>>
>> http://wiki.collectionspace.org/display/collectionspace/Organization+Service+REST+APIs+-+Release+v0.8#OrganizationServiceRESTAPIs-Releasev0.8-ContactCRUDLservices
>>
>> There will be full-stack support for adding Contacts through the UI
>> in a future release. The current wireframes / designs for this:
>>
>> http://wiki.collectionspace.org/display/collectionspace/Wireframes+-+Name+Authority
>>
>> The current Contact schema looks like this:
>>
>> In 0.8:
>>
>> http://wiki.collectionspace.org/display/collectionspace/Name+Authority+Schema+-+Limited+for+Release+0.8
>> (see the "Contact Information" subhead)
>>
>> For post-1.0 implementation:
>>
>> http://wiki.collectionspace.org/display/collectionspace/Name+Authority+Schema#NameAuthoritySchema-ContactInformation
>>
>> There have also been some ambitious suggestions to revise the
>> 'post-1.0' Contact schema above, from modestly to radically, to make
>> it even more flexible for today's mix of physical and electronic
>> address types. There is a JIRA issue for this, which includes a
>> summary description and pointer to a December 2009 discussion on this
>> topic with Michael Black of PAHMA and several of our Museum
>> Informatics folks:
>>
>> "Revise the Contact info schema"
>> http://issues.collectionspace.org/browse/CSPACE-836
>>
>> We very much invite your - ongoing - feedback on the Contact record
>> schema, with respect to meeting SMK's needs.
>>
>> Aron
>>
>> P.S. It's also my personal hope that we will at some point support
>> import and export of Contacts in the standard vCard format, although
>> this might not be on the 1.0/2.0 roadmap.
>>
>
PS
Patrick Schmitz
Thu, Jun 24, 2010 9:26 PM
Field-level security is planned for a later release, however, we'd have to
create a new class of permissions for "sharing" in this manner. This is
doable, but I'd want to know more about what you are trying to do, in the
hopes that work we did would be more generally reusable.
Another approach is to configure this access through the application layer,
but this would leave a security hole in the services, as Aron mentions
below.
Another possibility would be to group the sensitive data into a single
schema within Contact, and control access to that. In any case, we should
probably talk some more about your requirements.
Thanks, hope this helps -
Patrick
Thanks for answering all my questions. There's just one
point I'm still unclear about.....
- the ability to mark individual fields for internet or intranet
You can let us know if this response might meet your needs
through the Person service, you can programmatically
records and their associated Contact record(s), and extract
selected Contact record fields for re-publishing. As one of many
options, a web application that generates dynamic pages -
ColdFusion, JSP, ASP, etc. - could presumably make these calls
directly to the CollectionSpace services layer.
That describes broadly what we'd like to accomplish, but
what I was trying to describe was a detail related to this
scenario - that we may need to allow an employee to mark any
of their own Contact fields as a field which they would allow
to be published internally, externally, niether or both. We
could create yet more fields (via schema extension) to hold
this information but I just wanted to check if there wasn't
already a method in place related to capturing metadata about
a field - in this case the fields visibility within different
web domains.
Others may wish to comment or correct; here are some
initial thoughts regarding your requirement:
The Contact schema - and to my knowledge, schemas for
objects and procedural entities more generally - currently
does not / do not expose any metadata on a per-field basis,
such as the 'permission to publish this field
[internally|externally]' flag you describe.
(Having that is a really interesting idea, by the way.)
If you add fields that you don't wish to have automatically
published, to an extension schema for Contacts, those fields
won't automatically appear in the web UI in a CollectionSpace
system. (To enable those to show up in the UI, you'd also
need to make changes in the App and UI layers; if you don't,
those fields will appear only in services calls.)
However, values in those fields will be indexed, and the
records containing a particular value will be returned from a
keyword search on that value, even if the fields themselves
will not be displayed in summary listings of search results,
or in full records.
In addition, as noted above, those extension fields will
still be retrievable via direct calls to the Person or
Organization service, to retrieve Contact record(s), if any,
for a particular person or organization. At best, placing
the fields more likely to be non-public in an extension
schema is a form of "security through obscurity."
Thinking out loud - this is untested, and hence may not
work, but ... you might restrict access to the resource URL
paths that allow access to Contact records (e.g.
.../Persons/{person ID}/Contacts) only to a particular broad
role, such as a ROLE_MUSEUM_STAFF role, as well as to any
applicable administrator-related roles. Presumably, that
would permit only logged in users with one or more of those
roles assigned to their accounts to access Contact information.
You could then set up an account for a publishing script or
program, perhaps giving it a different role, such as
ROLE_CONTACT_INFO_PUBLISHER, and give it read-only access to
the Contact URL resource paths. That script or program would
then contain its own, configurable or hard-coded, logic for
determining what fields should be published on the web,
internally or externally to your institution.
There is a functionality requirement, post release 1.0, to
facilitate more granular access controls, extending to the record
(resource) level and probably ultimately, to the field
(attribute) level. That might at least indirectly facilitate
the behavior you're describing.
Aron
Do you have any further words of comfort about the
- the ability to add new fields (CV, conferences attended,
qualifications etc.) which I hope we can accomplish via
schema extensions either to the Contact or Person schemas.
Contact records are amenable to schema extension.
- the ability to mark individual fields for internet or intranet
publishing
You can let us know if this response might meet your needs
through the Person service, you can programmatically
records and their associated Contact record(s), and extract
selected Contact record fields for re-publishing. As one of many
options, a web application that generates dynamic pages -
ColdFusion, JSP, ASP, etc. - could presumably make these calls
directly to the CollectionSpace services layer.
- support for images (presumeably supported via media snapshot
relationship?)
Interesting. Any record can be related to any other in
CollectionSpace through relationship / relations records, and Media
records are coming in 0.9, so as one option, it might be
this way to relate, say, a Media record referring to a portrait
photograph to a Person record or a Media record referring to a
photograph of a group at a conference to multiple depicted Peron
records.
I'm unclear on whether it's preferable to organise Persons
via internal fields as Angela suggested, or by relating
Person records within a hierarchy of Organisations (if I've
understood correctly this is also a possibility).
Perhaps others might wish to comment on this ...
Encryption would be necessary for some of our confidential
employee data used by our Administration department. However,
we don't have immediate plans to migrate this to CollectionSpace.
I'd like to soon use a local deployment of CollectionSpace
for trying this out. ie. serving Person data to an intranet
site from which we can implement the ability, via web
services, to update/edit employee details (for test use
only). Should 0.8 be able to handle this?
Yes, with the caveat that the Contact record schema for 0.8 is
rudimentary. Nonetheless, any mechanism you create now for
/ editing employee details has a high likelihood - schema changes
notwithstanding - of working 'as is', or with only minor
when accessing future releases as well.
Aron
Aron Roberts
Sendt: 22. juni 2010 18:53
Til: Christopher Pott
Cc: talk@lists.collectionspace.org
Emne: Re: [Talk] employee data in CollectionSpace
Chris wrote:
We have a requirement for storage of some basic data
museum employees with the possibility to make (some) of
phone number, name, department etc.) available to a web site (and
probably some other applications) via a web service.
Would it be appropriate to store this data within
Person Name Authority records?
A followup to the two very interesting messages so far in
- Angela's comment on the use of the "Person's occupation" and
"Person's group" fields.
- Patrick's preview of future functionality around tagging and
filtering of person authority records, and his comment on securing
personally identifiable information (e.g. identification
as a "donor").
Yes, it can be appropriate to store basic contact and affiliation
information for museum employees in CollectionSpace.
In the CollectionSpace services layer, there is today a very
rudimentary Contact record, at least a placeholder for future
functionality. There is a many to one relationship
and Person (and Organization) records:
PersonAuthority ==> 0...n Persons
|__ each Person ==> 0..n Contacts
OrganizationAuthority => 0...n Organizations
|__ each Organization ==> 0...n Contacts
These RESTful API documents have been recently updated to
how you can add Contacts to Persons and Organizations, via
and Organization services:
e+REST+APIs+-+Release+v0.8#PersonServiceRESTAPIs-Releasev0.8-ContactC
Service+REST+APIs+-+Release+v0.8#OrganizationServiceRESTAPIs-Releasev
0.8-ContactCRUDLservices
There will be full-stack support for adding Contacts
in a future release. The current wireframes / designs for this:
Name+Authority
The current Contact schema looks like this:
In 0.8:
y+Schema+-+Limited+for+Release+0.8
(see the "Contact Information" subhead)
For post-1.0 implementation:
y+Schema#NameAuthoritySchema-ContactInformation
There have also been some ambitious suggestions to revise the
'post-1.0' Contact schema above, from modestly to
it even more flexible for today's mix of physical and electronic
address types. There is a JIRA issue for this, which includes a
summary description and pointer to a December 2009
topic with Michael Black of PAHMA and several of our Museum
Informatics folks:
"Revise the Contact info schema"
http://issues.collectionspace.org/browse/CSPACE-836
We very much invite your - ongoing - feedback on the
schema, with respect to meeting SMK's needs.
Aron
P.S. It's also my personal hope that we will at some point support
import and export of Contacts in the standard vCard
this might not be on the 1.0/2.0 roadmap.
Field-level security is planned for a later release, however, we'd have to
create a new class of permissions for "sharing" in this manner. This is
doable, but I'd want to know more about what you are trying to do, in the
hopes that work we did would be more generally reusable.
Another approach is to configure this access through the application layer,
but this would leave a security hole in the services, as Aron mentions
below.
Another possibility would be to group the sensitive data into a single
schema within Contact, and control access to that. In any case, we should
probably talk some more about your requirements.
Thanks, hope this helps -
Patrick
> -----Original Message-----
> From: talk-bounces@lists.collectionspace.org
> [mailto:talk-bounces@lists.collectionspace.org] On Behalf Of
> Aron Roberts
> Sent: Thursday, June 24, 2010 6:49 AM
> To: Christopher Pott
> Cc: talk@lists.collectionspace.org
> Subject: Re: [Talk] employee data in CollectionSpace
>
> Hi Chris,
>
> On Thu, Jun 24, 2010 at 12:33 AM, Christopher Pott
> <Christopher.Pott@smk.dk> wrote:
> > Thanks for answering all my questions. There's just one
> point I'm still unclear about.....
> >
> >>> * the ability to mark individual fields for internet or intranet
> >>> >>publishing
> >
> >> You can let us know if this response might meet your needs
> for this:
> >>through the Person service, you can programmatically
> retrieve Person
> >>records and their associated Contact record(s), and extract
> data from
> >>selected Contact record fields for re-publishing. As one of many
> >>options, a web application that generates dynamic pages -
> using PHP,
> >>ColdFusion, JSP, ASP, etc. - could presumably make these calls
> >>directly to the CollectionSpace services layer.
> >
> > That describes broadly what we'd like to accomplish, but
> what I was trying to describe was a detail related to this
> scenario - that we may need to allow an employee to mark any
> of their own Contact fields as a field which they would allow
> to be published internally, externally, niether or both. We
> could create yet more fields (via schema extension) to hold
> this information but I just wanted to check if there wasn't
> already a method in place related to capturing metadata about
> a field - in this case the fields visibility within different
> web domains.
>
> Others may wish to comment or correct; here are some
> initial thoughts regarding your requirement:
>
> The Contact schema - and to my knowledge, schemas for
> objects and procedural entities more generally - currently
> does not / do not expose any metadata on a per-field basis,
> such as the 'permission to publish this field
> [internally|externally]' flag you describe.
> (Having that is a really interesting idea, by the way.)
>
> If you add fields that you don't wish to have automatically
> published, to an extension schema for Contacts, those fields
> won't automatically appear in the web UI in a CollectionSpace
> system. (To enable those to show up in the UI, you'd also
> need to make changes in the App and UI layers; if you don't,
> those fields will appear only in services calls.)
>
> However, values in those fields will be indexed, and the
> records containing a particular value will be returned from a
> keyword search on that value, even if the fields themselves
> will not be displayed in summary listings of search results,
> or in full records.
>
> In addition, as noted above, those extension fields will
> still be retrievable via direct calls to the Person or
> Organization service, to retrieve Contact record(s), if any,
> for a particular person or organization. At best, placing
> the fields more likely to be non-public in an extension
> schema is a form of "security through obscurity."
>
> Thinking out loud - this is untested, and hence may not
> work, but ... you might restrict access to the resource URL
> paths that allow access to Contact records (e.g.
> .../Persons/{person ID}/Contacts) only to a particular broad
> role, such as a ROLE_MUSEUM_STAFF role, as well as to any
> applicable administrator-related roles. Presumably, that
> would permit only logged in users with one or more of those
> roles assigned to their accounts to access Contact information.
>
> You could then set up an account for a publishing script or
> program, perhaps giving it a different role, such as
> ROLE_CONTACT_INFO_PUBLISHER, and give it read-only access to
> the Contact URL resource paths. That script or program would
> then contain its own, configurable or hard-coded, logic for
> determining what fields should be published on the web,
> internally or externally to your institution.
>
> There is a functionality requirement, post release 1.0, to
> facilitate more granular access controls, extending to the record
> (resource) level and probably ultimately, to the field
> (attribute) level. That might at least indirectly facilitate
> the behavior you're describing.
>
> Aron
>
>
>
> >
> > /Chris
> >
> > -----Oprindelig meddelelse-----
> > Fra: aronroberts@gmail.com [mailto:aronroberts@gmail.com]
> På vegne af
> > Aron Roberts
> > Sendt: 23. juni 2010 16:14
> > Til: Christopher Pott
> > Cc: talk@lists.collectionspace.org
> > Emne: Re: [Talk] employee data in CollectionSpace
> >
> > On Wed, Jun 23, 2010 at 4:38 AM, Christopher Pott
> > <Christopher.Pott@smk.dk> wrote:
> >> Do you have any further words of comfort about the
> following points?...
> >>
> >> * the ability to add new fields (CV, conferences attended,
> qualifications etc.) which I hope we can accomplish via
> schema extensions either to the Contact or Person schemas.
> >
> > Contact records are amenable to schema extension.
> >
> >> * the ability to mark individual fields for internet or intranet
> >> publishing
> >
> > You can let us know if this response might meet your needs
> for this:
> > through the Person service, you can programmatically
> retrieve Person
> > records and their associated Contact record(s), and extract
> data from
> > selected Contact record fields for re-publishing. As one of many
> > options, a web application that generates dynamic pages -
> using PHP,
> > ColdFusion, JSP, ASP, etc. - could presumably make these calls
> > directly to the CollectionSpace services layer.
> >
> >> * support for images (presumeably supported via media snapshot
> >> relationship?)
> >
> > Interesting. Any record can be related to any other in
> > CollectionSpace through relationship / relations records, and Media
> > records are coming in 0.9, so as one option, it might be
> possible in
> > this way to relate, say, a Media record referring to a portrait
> > photograph to a Person record or a Media record referring to a
> > photograph of a group at a conference to multiple depicted Peron
> > records.
> >
> >> I'm unclear on whether it's preferable to organise Persons
> via internal fields as Angela suggested, or by relating
> Person records within a hierarchy of Organisations (if I've
> understood correctly this is also a possibility).
> >
> > Perhaps others might wish to comment on this ...
> >
> >> Encryption would be necessary for some of our confidential
> employee data used by our Administration department. However,
> we don't have immediate plans to migrate this to CollectionSpace.
> >>
> >> I'd like to soon use a local deployment of CollectionSpace
> for trying this out. ie. serving Person data to an intranet
> site from which we can implement the ability, via web
> services, to update/edit employee details (for test use
> only). Should 0.8 be able to handle this?
> >
> > Yes, with the caveat that the Contact record schema for 0.8 is
> > rudimentary. Nonetheless, any mechanism you create now for
> retrieving
> > / editing employee details has a high likelihood - schema changes
> > notwithstanding - of working 'as is', or with only minor
> modification,
> > when accessing future releases as well.
> >
> > Aron
> >
> >>
> >> /Chris
> >>
> >> Developer, Corpus Project
> >> Statens Museum for Kunst (National Gallery of Denmark)
> >>
> >> -----Oprindelig meddelelse-----
> >> Fra: aronroberts@gmail.com [mailto:aronroberts@gmail.com]
> På vegne af
> >> Aron Roberts
> >> Sendt: 22. juni 2010 18:53
> >> Til: Christopher Pott
> >> Cc: talk@lists.collectionspace.org
> >> Emne: Re: [Talk] employee data in CollectionSpace
> >>
> >> Chris wrote:
> >>> We have a requirement for storage of some basic data
> relating to all
> >> museum employees with the possibility to make (some) of
> this data (eg.
> >> phone number, name, department etc.) available to a web site (and
> >> probably some other applications) via a web service.
> >>
> >>> Would it be appropriate to store this data within
> CollectionSpace as
> >> Person Name Authority records?
> >>
> >> A followup to the two very interesting messages so far in
> this thread:
> >> - Angela's comment on the use of the "Person's occupation" and
> >> "Person's group" fields.
> >> - Patrick's preview of future functionality around tagging and
> >> filtering of person authority records, and his comment on securing
> >> personally identifiable information (e.g. identification
> of a person
> >> as a "donor").
> >>
> >> Yes, it can be appropriate to store basic contact and affiliation
> >> information for museum employees in CollectionSpace.
> >>
> >> In the CollectionSpace services layer, there is today a *very*
> >> rudimentary Contact record, at least a placeholder for future
> >> functionality. There is a many to one relationship
> between Contacts
> >> and Person (and Organization) records:
> >>
> >> PersonAuthority ==> 0...n Persons
> >> |__ each Person ==> 0..n Contacts
> >>
> >> OrganizationAuthority => 0...n Organizations
> >> |__ each Organization ==> 0...n Contacts
> >>
> >> These RESTful API documents have been recently updated to
> describe
> >> how you can add Contacts to Persons and Organizations, via
> the Person
> >> and Organization services:
> >>
> >>
> http://wiki.collectionspace.org/display/collectionspace/Person+Servic
> >>
> e+REST+APIs+-+Release+v0.8#PersonServiceRESTAPIs-Releasev0.8-ContactC
> >> RUDLservices
> >>
> >>
> http://wiki.collectionspace.org/display/collectionspace/Organization+
> >>
> Service+REST+APIs+-+Release+v0.8#OrganizationServiceRESTAPIs-Releasev
> >> 0.8-ContactCRUDLservices
> >>
> >> There will be full-stack support for adding Contacts
> through the UI
> >> in a future release. The current wireframes / designs for this:
> >>
> >>
> >>
> http://wiki.collectionspace.org/display/collectionspace/Wireframes+-+
> >> Name+Authority
> >>
> >> The current Contact schema looks like this:
> >>
> >> In 0.8:
> >>
> >>
> http://wiki.collectionspace.org/display/collectionspace/Name+Authorit
> >> y+Schema+-+Limited+for+Release+0.8
> >> (see the "Contact Information" subhead)
> >>
> >> For post-1.0 implementation:
> >>
> >>
> http://wiki.collectionspace.org/display/collectionspace/Name+Authorit
> >> y+Schema#NameAuthoritySchema-ContactInformation
> >>
> >> There have also been some ambitious suggestions to revise the
> >> 'post-1.0' Contact schema above, from modestly to
> radically, to make
> >> it even more flexible for today's mix of physical and electronic
> >> address types. There is a JIRA issue for this, which includes a
> >> summary description and pointer to a December 2009
> discussion on this
> >> topic with Michael Black of PAHMA and several of our Museum
> >> Informatics folks:
> >>
> >> "Revise the Contact info schema"
> >> http://issues.collectionspace.org/browse/CSPACE-836
> >>
> >> We very much invite your - ongoing - feedback on the
> Contact record
> >> schema, with respect to meeting SMK's needs.
> >>
> >> Aron
> >>
> >> P.S. It's also my personal hope that we will at some point support
> >> import and export of Contacts in the standard vCard
> format, although
> >> this might not be on the 1.0/2.0 roadmap.
> >>
> >
>
> _______________________________________________
> Talk mailing list
> Talk@lists.collectionspace.org
> http://lists.collectionspace.org/mailman/listinfo/talk_lists.c
> ollectionspace.org
>
