[CODE4LIB] linked data recipe
I believe participating in the Semantic Web and providing content via the principles of linked data is not rocket surgery, especially for cultural heritage institutions -- libraries, archives, and museums. Here is a simple recipe for their participation: 1. use existing metadata standards (MARC, EAD, etc.) to describe collections 2. use any number of existing tools to convert the metadata to HTML, and save the HTML on a Web server 3. use any number of existing tools to convert the metadata to RDF/XML (or some other serialization of RDF), and save the RDF/XML on a Web server 4. rest, congratulate yourself, and share your experience with others in your domain 5. after the first time though, go back to Step #1, but this time work with other people inside your domain making sure you use as many of the same URIs as possible 6. after the second time through, go back to Step #1, but this time supplement access to your linked data with a triple store, thus supporting search 7. after the third time through, go back to Step #1, but this time use any number of existing tools to expose the content in your other information systems (relational databases, OAI-PMH data repositories, etc.) 8. for dessert, cogitate ways to exploit the linked data in your domain to discover new and additional relationships between URIs, and thus make the Semantic Web more of a reality What do you think? I am in the process of writing a guidebook on the topic of linked data and archives. In the guidebook I will elaborate on this recipe and provide instructions for its implementation. [1] [1] guidebook - http://sites.tufts.edu/liam/ -- Eric Lease Morgan University of Notre Dame
Re: [CODE4LIB] linked data recipe
It's a great start Eric. It helps me think that I can do it. Looking forward to more. Brian Zelip UIUC On Tue, Nov 19, 2013 at 7:04 AM, Eric Lease Morgan emor...@nd.edu wrote: I believe participating in the Semantic Web and providing content via the principles of linked data is not rocket surgery, especially for cultural heritage institutions -- libraries, archives, and museums. Here is a simple recipe for their participation: 1. use existing metadata standards (MARC, EAD, etc.) to describe collections 2. use any number of existing tools to convert the metadata to HTML, and save the HTML on a Web server 3. use any number of existing tools to convert the metadata to RDF/XML (or some other serialization of RDF), and save the RDF/XML on a Web server 4. rest, congratulate yourself, and share your experience with others in your domain 5. after the first time though, go back to Step #1, but this time work with other people inside your domain making sure you use as many of the same URIs as possible 6. after the second time through, go back to Step #1, but this time supplement access to your linked data with a triple store, thus supporting search 7. after the third time through, go back to Step #1, but this time use any number of existing tools to expose the content in your other information systems (relational databases, OAI-PMH data repositories, etc.) 8. for dessert, cogitate ways to exploit the linked data in your domain to discover new and additional relationships between URIs, and thus make the Semantic Web more of a reality What do you think? I am in the process of writing a guidebook on the topic of linked data and archives. In the guidebook I will elaborate on this recipe and provide instructions for its implementation. [1] [1] guidebook - http://sites.tufts.edu/liam/ -- Eric Lease Morgan University of Notre Dame
Re: [CODE4LIB] linked data recipe
Hi Eric, while I also think this is not rocket surgery, I'd like to point out that trial (and potentially error) as suggested by your go back to step #1 instructions is not a good solution to coming up with URIs. I think once published - i.e. put on a webserver - you should be able to keep the URIs in your RDF persistent. Otherwise you are polluting the Semantic Web with dead links and make it hard for aggregators to find out whether the data they harvested is still valid. So while iterative approaches are pragmatic and often work out well, for the particular issue of coming up with URIs I'd recommend spending as much thought before publishing as you can spend. best robert On Tue, Nov 19, 2013 at 2:04 PM, Eric Lease Morgan emor...@nd.edu wrote: I believe participating in the Semantic Web and providing content via the principles of linked data is not rocket surgery, especially for cultural heritage institutions -- libraries, archives, and museums. Here is a simple recipe for their participation: 1. use existing metadata standards (MARC, EAD, etc.) to describe collections 2. use any number of existing tools to convert the metadata to HTML, and save the HTML on a Web server 3. use any number of existing tools to convert the metadata to RDF/XML (or some other serialization of RDF), and save the RDF/XML on a Web server 4. rest, congratulate yourself, and share your experience with others in your domain 5. after the first time though, go back to Step #1, but this time work with other people inside your domain making sure you use as many of the same URIs as possible 6. after the second time through, go back to Step #1, but this time supplement access to your linked data with a triple store, thus supporting search 7. after the third time through, go back to Step #1, but this time use any number of existing tools to expose the content in your other information systems (relational databases, OAI-PMH data repositories, etc.) 8. for dessert, cogitate ways to exploit the linked data in your domain to discover new and additional relationships between URIs, and thus make the Semantic Web more of a reality What do you think? I am in the process of writing a guidebook on the topic of linked data and archives. In the guidebook I will elaborate on this recipe and provide instructions for its implementation. [1] [1] guidebook - http://sites.tufts.edu/liam/ -- Eric Lease Morgan University of Notre Dame
[CODE4LIB] ALA's Carroll Preston Baber Research Grant--Call for Proposals
*Carroll Preston Baber research grant call for proposals* Do you have a project that is just waiting for the right funding? Are you thinking about ways that libraries can improve services to users? The American Library Association (ALA) gives an annual grant for those conducting research that will lead to the improvement of services to users. The Carroll Preston Baber Research Grant is given to one or more librarians or library educators who will conduct innovative research that could lead to an improvement in services to any specified group of people. The grant, up to $3,000, will be given to a proposed project that aims to answer a question of vital importance to the library community that is national in scope. Among the review panel criteria are: - The research problem is clearly defined, with a specific question or questions that can be answered by collecting data. The applicant(s) clearly describe a strategy for data collection whose methods are appropriate to the research question(s). A review of the literature, methodologies, etc. is not considered research (e.g., methodology review rather than application of a methodology) for purposes of the award, except where the literature review is the primary method of collecting data. - The research question focuses on benefits to library users and should be applied and have practical value as opposed to theoretical. - The applicant(s) demonstrate ability to undertake and successfully complete the project. The application provides evidence that sufficient time and resources have been allocated to the effort. Appropriate institutional commitment to the project has been secured. Any ALA member may apply, and the Jury would welcome projects that involve both a practicing librarian and a researcher. Deadline is *January 8, 2014*. Check out this web site to find procedures and an application form: http://www.ala.org/ala/aboutala/offices/ors/orsawards/baberresearchgrant/babercarroll.cfm See the section on *How to Apply*. Also see related documents linked near the bottom of the page for: Schedule and Procedures http://www.ala.org/offices/ors/orsawards/baberresearchgrant/schedandprocedures Proposal Requirements and Application Cover Sheet: http://www.ala.org/offices/ors/orsawards/baberresearchgrant/requirements Full press release: http://www.ala.org/news/press-releases/2013/11/baber-research-grant-proposals-due-january-8 Questions? Contact: Mary Pagliero Popp at p...@indiana.edu. -- *Mary* *--* *Mary Pagliero Popp, Chair, Baber Award Jury, American Library Association*
Re: [CODE4LIB] linked data recipe
Eric, I think this skips a step - which is the design step in which you create a domain model that uses linked data as its basis. RDF is not a serialization; it actually may require you to re-think the basic structure of your metadata. The reason for that is that it provides capabilities that record-based data models do not. Rather than starting with current metadata, you need to take a step back and ask: what does my information world look like as linked data? I repeat: RDF is NOT A SERIALIZATION. kc On 11/19/13 5:04 AM, Eric Lease Morgan wrote: I believe participating in the Semantic Web and providing content via the principles of linked data is not rocket surgery, especially for cultural heritage institutions -- libraries, archives, and museums. Here is a simple recipe for their participation: 1. use existing metadata standards (MARC, EAD, etc.) to describe collections 2. use any number of existing tools to convert the metadata to HTML, and save the HTML on a Web server 3. use any number of existing tools to convert the metadata to RDF/XML (or some other serialization of RDF), and save the RDF/XML on a Web server 4. rest, congratulate yourself, and share your experience with others in your domain 5. after the first time though, go back to Step #1, but this time work with other people inside your domain making sure you use as many of the same URIs as possible 6. after the second time through, go back to Step #1, but this time supplement access to your linked data with a triple store, thus supporting search 7. after the third time through, go back to Step #1, but this time use any number of existing tools to expose the content in your other information systems (relational databases, OAI-PMH data repositories, etc.) 8. for dessert, cogitate ways to exploit the linked data in your domain to discover new and additional relationships between URIs, and thus make the Semantic Web more of a reality What do you think? I am in the process of writing a guidebook on the topic of linked data and archives. In the guidebook I will elaborate on this recipe and provide instructions for its implementation. [1] [1] guidebook - http://sites.tufts.edu/liam/ -- Eric Lease Morgan University of Notre Dame -- Karen Coyle kco...@kcoyle.net http://kcoyle.net m: 1-510-435-8234 skype: kcoylenet
Re: [CODE4LIB] linked data recipe
I think you’ve hit the nail on the head here, Karen. I would just add, or maybe reassure, that this does not necessarily require rethinking your existing metadata but how to translate that existing metadata into a linked data environment. Though this might seem like a pain, in many cases it will actually inspire you to go back and improve/increase the value of that existing metadata. This is definitely looking awesome, Eric! Aaron On Nov 19, 2013, at 9:41 AM, Karen Coyle li...@kcoyle.net wrote: Eric, I think this skips a step - which is the design step in which you create a domain model that uses linked data as its basis. RDF is not a serialization; it actually may require you to re-think the basic structure of your metadata. The reason for that is that it provides capabilities that record-based data models do not. Rather than starting with current metadata, you need to take a step back and ask: what does my information world look like as linked data? I repeat: RDF is NOT A SERIALIZATION. kc On 11/19/13 5:04 AM, Eric Lease Morgan wrote: I believe participating in the Semantic Web and providing content via the principles of linked data is not rocket surgery, especially for cultural heritage institutions -- libraries, archives, and museums. Here is a simple recipe for their participation: 1. use existing metadata standards (MARC, EAD, etc.) to describe collections 2. use any number of existing tools to convert the metadata to HTML, and save the HTML on a Web server 3. use any number of existing tools to convert the metadata to RDF/XML (or some other serialization of RDF), and save the RDF/XML on a Web server 4. rest, congratulate yourself, and share your experience with others in your domain 5. after the first time though, go back to Step #1, but this time work with other people inside your domain making sure you use as many of the same URIs as possible 6. after the second time through, go back to Step #1, but this time supplement access to your linked data with a triple store, thus supporting search 7. after the third time through, go back to Step #1, but this time use any number of existing tools to expose the content in your other information systems (relational databases, OAI-PMH data repositories, etc.) 8. for dessert, cogitate ways to exploit the linked data in your domain to discover new and additional relationships between URIs, and thus make the Semantic Web more of a reality What do you think? I am in the process of writing a guidebook on the topic of linked data and archives. In the guidebook I will elaborate on this recipe and provide instructions for its implementation. [1] [1] guidebook - http://sites.tufts.edu/liam/ -- Eric Lease Morgan University of Notre Dame -- Karen Coyle kco...@kcoyle.net http://kcoyle.net m: 1-510-435-8234 skype: kcoylenet
Re: [CODE4LIB] linked data recipe
I'm not sure that I agree that RDF is not a serialization. It really depends on the context of the system and intended use of the linked data. For example, TEI is designed with a specific purpose which cannot be replicated in RDF (at least, not very easily at all), but deriving RDF from highly-linked TEI to put into an endpoint can open doors to queries which are otherwise impossible to make on the data. This certainly requires some rethinking of the way texts interact. But perhaps it may be best to say that RDF *can* (but not necessarily) be a derivation, rather than serialization, of some larger, more complex canonical data model. Ethan On Tue, Nov 19, 2013 at 9:54 AM, Aaron Rubinstein arubi...@library.umass.edu wrote: I think you’ve hit the nail on the head here, Karen. I would just add, or maybe reassure, that this does not necessarily require rethinking your existing metadata but how to translate that existing metadata into a linked data environment. Though this might seem like a pain, in many cases it will actually inspire you to go back and improve/increase the value of that existing metadata. This is definitely looking awesome, Eric! Aaron On Nov 19, 2013, at 9:41 AM, Karen Coyle li...@kcoyle.net wrote: Eric, I think this skips a step - which is the design step in which you create a domain model that uses linked data as its basis. RDF is not a serialization; it actually may require you to re-think the basic structure of your metadata. The reason for that is that it provides capabilities that record-based data models do not. Rather than starting with current metadata, you need to take a step back and ask: what does my information world look like as linked data? I repeat: RDF is NOT A SERIALIZATION. kc On 11/19/13 5:04 AM, Eric Lease Morgan wrote: I believe participating in the Semantic Web and providing content via the principles of linked data is not rocket surgery, especially for cultural heritage institutions -- libraries, archives, and museums. Here is a simple recipe for their participation: 1. use existing metadata standards (MARC, EAD, etc.) to describe collections 2. use any number of existing tools to convert the metadata to HTML, and save the HTML on a Web server 3. use any number of existing tools to convert the metadata to RDF/XML (or some other serialization of RDF), and save the RDF/XML on a Web server 4. rest, congratulate yourself, and share your experience with others in your domain 5. after the first time though, go back to Step #1, but this time work with other people inside your domain making sure you use as many of the same URIs as possible 6. after the second time through, go back to Step #1, but this time supplement access to your linked data with a triple store, thus supporting search 7. after the third time through, go back to Step #1, but this time use any number of existing tools to expose the content in your other information systems (relational databases, OAI-PMH data repositories, etc.) 8. for dessert, cogitate ways to exploit the linked data in your domain to discover new and additional relationships between URIs, and thus make the Semantic Web more of a reality What do you think? I am in the process of writing a guidebook on the topic of linked data and archives. In the guidebook I will elaborate on this recipe and provide instructions for its implementation. [1] [1] guidebook - http://sites.tufts.edu/liam/ -- Eric Lease Morgan University of Notre Dame -- Karen Coyle kco...@kcoyle.net http://kcoyle.net m: 1-510-435-8234 skype: kcoylenet
Re: [CODE4LIB] linked data recipe
That's still not a serialization. It's just a similar data model. Pretty huge difference. -Ross. On Tue, Nov 19, 2013 at 10:31 AM, Ethan Gruber ewg4x...@gmail.com wrote: I'm not sure that I agree that RDF is not a serialization. It really depends on the context of the system and intended use of the linked data. For example, TEI is designed with a specific purpose which cannot be replicated in RDF (at least, not very easily at all), but deriving RDF from highly-linked TEI to put into an endpoint can open doors to queries which are otherwise impossible to make on the data. This certainly requires some rethinking of the way texts interact. But perhaps it may be best to say that RDF *can* (but not necessarily) be a derivation, rather than serialization, of some larger, more complex canonical data model. Ethan On Tue, Nov 19, 2013 at 9:54 AM, Aaron Rubinstein arubi...@library.umass.edu wrote: I think you’ve hit the nail on the head here, Karen. I would just add, or maybe reassure, that this does not necessarily require rethinking your existing metadata but how to translate that existing metadata into a linked data environment. Though this might seem like a pain, in many cases it will actually inspire you to go back and improve/increase the value of that existing metadata. This is definitely looking awesome, Eric! Aaron On Nov 19, 2013, at 9:41 AM, Karen Coyle li...@kcoyle.net wrote: Eric, I think this skips a step - which is the design step in which you create a domain model that uses linked data as its basis. RDF is not a serialization; it actually may require you to re-think the basic structure of your metadata. The reason for that is that it provides capabilities that record-based data models do not. Rather than starting with current metadata, you need to take a step back and ask: what does my information world look like as linked data? I repeat: RDF is NOT A SERIALIZATION. kc On 11/19/13 5:04 AM, Eric Lease Morgan wrote: I believe participating in the Semantic Web and providing content via the principles of linked data is not rocket surgery, especially for cultural heritage institutions -- libraries, archives, and museums. Here is a simple recipe for their participation: 1. use existing metadata standards (MARC, EAD, etc.) to describe collections 2. use any number of existing tools to convert the metadata to HTML, and save the HTML on a Web server 3. use any number of existing tools to convert the metadata to RDF/XML (or some other serialization of RDF), and save the RDF/XML on a Web server 4. rest, congratulate yourself, and share your experience with others in your domain 5. after the first time though, go back to Step #1, but this time work with other people inside your domain making sure you use as many of the same URIs as possible 6. after the second time through, go back to Step #1, but this time supplement access to your linked data with a triple store, thus supporting search 7. after the third time through, go back to Step #1, but this time use any number of existing tools to expose the content in your other information systems (relational databases, OAI-PMH data repositories, etc.) 8. for dessert, cogitate ways to exploit the linked data in your domain to discover new and additional relationships between URIs, and thus make the Semantic Web more of a reality What do you think? I am in the process of writing a guidebook on the topic of linked data and archives. In the guidebook I will elaborate on this recipe and provide instructions for its implementation. [1] [1] guidebook - http://sites.tufts.edu/liam/ -- Eric Lease Morgan University of Notre Dame -- Karen Coyle kco...@kcoyle.net http://kcoyle.net m: 1-510-435-8234 skype: kcoylenet
Re: [CODE4LIB] linked data recipe
I see that serialization has a different definition in computer science than I thought it did. On Tue, Nov 19, 2013 at 10:36 AM, Ross Singer rossfsin...@gmail.com wrote: That's still not a serialization. It's just a similar data model. Pretty huge difference. -Ross. On Tue, Nov 19, 2013 at 10:31 AM, Ethan Gruber ewg4x...@gmail.com wrote: I'm not sure that I agree that RDF is not a serialization. It really depends on the context of the system and intended use of the linked data. For example, TEI is designed with a specific purpose which cannot be replicated in RDF (at least, not very easily at all), but deriving RDF from highly-linked TEI to put into an endpoint can open doors to queries which are otherwise impossible to make on the data. This certainly requires some rethinking of the way texts interact. But perhaps it may be best to say that RDF *can* (but not necessarily) be a derivation, rather than serialization, of some larger, more complex canonical data model. Ethan On Tue, Nov 19, 2013 at 9:54 AM, Aaron Rubinstein arubi...@library.umass.edu wrote: I think you’ve hit the nail on the head here, Karen. I would just add, or maybe reassure, that this does not necessarily require rethinking your existing metadata but how to translate that existing metadata into a linked data environment. Though this might seem like a pain, in many cases it will actually inspire you to go back and improve/increase the value of that existing metadata. This is definitely looking awesome, Eric! Aaron On Nov 19, 2013, at 9:41 AM, Karen Coyle li...@kcoyle.net wrote: Eric, I think this skips a step - which is the design step in which you create a domain model that uses linked data as its basis. RDF is not a serialization; it actually may require you to re-think the basic structure of your metadata. The reason for that is that it provides capabilities that record-based data models do not. Rather than starting with current metadata, you need to take a step back and ask: what does my information world look like as linked data? I repeat: RDF is NOT A SERIALIZATION. kc On 11/19/13 5:04 AM, Eric Lease Morgan wrote: I believe participating in the Semantic Web and providing content via the principles of linked data is not rocket surgery, especially for cultural heritage institutions -- libraries, archives, and museums. Here is a simple recipe for their participation: 1. use existing metadata standards (MARC, EAD, etc.) to describe collections 2. use any number of existing tools to convert the metadata to HTML, and save the HTML on a Web server 3. use any number of existing tools to convert the metadata to RDF/XML (or some other serialization of RDF), and save the RDF/XML on a Web server 4. rest, congratulate yourself, and share your experience with others in your domain 5. after the first time though, go back to Step #1, but this time work with other people inside your domain making sure you use as many of the same URIs as possible 6. after the second time through, go back to Step #1, but this time supplement access to your linked data with a triple store, thus supporting search 7. after the third time through, go back to Step #1, but this time use any number of existing tools to expose the content in your other information systems (relational databases, OAI-PMH data repositories, etc.) 8. for dessert, cogitate ways to exploit the linked data in your domain to discover new and additional relationships between URIs, and thus make the Semantic Web more of a reality What do you think? I am in the process of writing a guidebook on the topic of linked data and archives. In the guidebook I will elaborate on this recipe and provide instructions for its implementation. [1] [1] guidebook - http://sites.tufts.edu/liam/ -- Eric Lease Morgan University of Notre Dame -- Karen Coyle kco...@kcoyle.net http://kcoyle.net m: 1-510-435-8234 skype: kcoylenet
Re: [CODE4LIB] linked data recipe
On Nov 19, 2013, at 8:48 AM, Robert Forkel xrotw...@googlemail.com wrote: while I also think this is not rocket surgery, I'd like to point out that trial (and potentially error) as suggested by your go back to step #1 instructions is not a good solution to coming up with URIs. I think once published - i.e. put on a webserver - you should be able to keep the URIs in your RDF persistent. Otherwise you are polluting the Semantic Web with dead links and make it hard for aggregators to find out whether the data they harvested is still valid. So while iterative approaches are pragmatic and often work out well, for the particular issue of coming up with URIs I'd recommend spending as much thought before publishing as you can spend. Intellectually, I completely understand. Practically, I still advocate putting publishing the linked data as soon as possible. Knowledge is refined over time. The data being published is not incorrect nor invalid, just not as good as it could be. Data aggregators will refresh their stores and old information will go to Big Byte Heaven”. It is just like a library collection. The “best” books are collected. The good ones get used. The old ones get weeded or relegated to off-site storage. What remains is a current perception of truth. Building library collections is a process that is never done nor never perfect. Linked data is a literal reflection of library collections, therefore linked data is never done nor never perfect either. URIs will break. Books will be removed from the collection. URIs will go stale. The process of providing linked data is a lot like painting a painting. The painting is painted as a whole, from start to finish. One does not get one corner of the canvass perfect and move on from there. An idea is articulated. An outlined is drawn. The outline is refined, and the painting gradually comes to life. Many times paintings are never finished but worked, reworked, and worked some more. If the profession looks to make perfect its list of URIs, then it will never leave the starting gate. I know that is not being advocated, but since one can not measure the timeless validity of a URI, I advocate that the current URIs are good enough. There is an understanding of a commitment to updating them and refining them in the future. — Eric Morgan
Re: [CODE4LIB] linked data recipe
On Nov 19, 2013, at 9:41 AM, Karen Coyle li...@kcoyle.net wrote: Eric, I think this skips a step - which is the design step in which you create a domain model that uses linked data as its basis. RDF is not a serialization; it actually may require you to re-think the basic structure of your metadata. The reason for that is that it provides capabilities that record-based data models do not. Rather than starting with current metadata, you need to take a step back and ask: what does my information world look like as linked data? I respectfully disagree. I do not think it necessary to create a domain model ahead of time; I do not think it is necessary for us to re-think our metadata structures. There already exists tools enabling us — cultural heritage institutions — to manifest our metadata as RDF. The manifestations may not be perfect, but “we need to learn to walk before we run” and the metadata structures we have right now will work for right now. As we mature we can refine our processes. I do not advocate “stepping back and asking”. I advocate looking forward and doing. —Eric Morgan
Re: [CODE4LIB] linked data recipe
I don't know what your definition of serialization is, but I don't know of any where data model and formatted output of a data model are synonymous. RDF is a data model *not* a serialization. -Ross. On Tue, Nov 19, 2013 at 10:45 AM, Ethan Gruber ewg4x...@gmail.com wrote: I see that serialization has a different definition in computer science than I thought it did. On Tue, Nov 19, 2013 at 10:36 AM, Ross Singer rossfsin...@gmail.com wrote: That's still not a serialization. It's just a similar data model. Pretty huge difference. -Ross. On Tue, Nov 19, 2013 at 10:31 AM, Ethan Gruber ewg4x...@gmail.com wrote: I'm not sure that I agree that RDF is not a serialization. It really depends on the context of the system and intended use of the linked data. For example, TEI is designed with a specific purpose which cannot be replicated in RDF (at least, not very easily at all), but deriving RDF from highly-linked TEI to put into an endpoint can open doors to queries which are otherwise impossible to make on the data. This certainly requires some rethinking of the way texts interact. But perhaps it may be best to say that RDF *can* (but not necessarily) be a derivation, rather than serialization, of some larger, more complex canonical data model. Ethan On Tue, Nov 19, 2013 at 9:54 AM, Aaron Rubinstein arubi...@library.umass.edu wrote: I think you’ve hit the nail on the head here, Karen. I would just add, or maybe reassure, that this does not necessarily require rethinking your existing metadata but how to translate that existing metadata into a linked data environment. Though this might seem like a pain, in many cases it will actually inspire you to go back and improve/increase the value of that existing metadata. This is definitely looking awesome, Eric! Aaron On Nov 19, 2013, at 9:41 AM, Karen Coyle li...@kcoyle.net wrote: Eric, I think this skips a step - which is the design step in which you create a domain model that uses linked data as its basis. RDF is not a serialization; it actually may require you to re-think the basic structure of your metadata. The reason for that is that it provides capabilities that record-based data models do not. Rather than starting with current metadata, you need to take a step back and ask: what does my information world look like as linked data? I repeat: RDF is NOT A SERIALIZATION. kc On 11/19/13 5:04 AM, Eric Lease Morgan wrote: I believe participating in the Semantic Web and providing content via the principles of linked data is not rocket surgery, especially for cultural heritage institutions -- libraries, archives, and museums. Here is a simple recipe for their participation: 1. use existing metadata standards (MARC, EAD, etc.) to describe collections 2. use any number of existing tools to convert the metadata to HTML, and save the HTML on a Web server 3. use any number of existing tools to convert the metadata to RDF/XML (or some other serialization of RDF), and save the RDF/XML on a Web server 4. rest, congratulate yourself, and share your experience with others in your domain 5. after the first time though, go back to Step #1, but this time work with other people inside your domain making sure you use as many of the same URIs as possible 6. after the second time through, go back to Step #1, but this time supplement access to your linked data with a triple store, thus supporting search 7. after the third time through, go back to Step #1, but this time use any number of existing tools to expose the content in your other information systems (relational databases, OAI-PMH data repositories, etc.) 8. for dessert, cogitate ways to exploit the linked data in your domain to discover new and additional relationships between URIs, and thus make the Semantic Web more of a reality What do you think? I am in the process of writing a guidebook on the topic of linked data and archives. In the guidebook I will elaborate on this recipe and provide instructions for its implementation. [1] [1] guidebook - http://sites.tufts.edu/liam/ -- Eric Lease Morgan University of Notre Dame -- Karen Coyle kco...@kcoyle.net http://kcoyle.net m: 1-510-435-8234 skype: kcoylenet
Re: [CODE4LIB] linked data recipe
yo, i get it On Tue, Nov 19, 2013 at 10:54 AM, Ross Singer rossfsin...@gmail.com wrote: I don't know what your definition of serialization is, but I don't know of any where data model and formatted output of a data model are synonymous. RDF is a data model *not* a serialization. -Ross. On Tue, Nov 19, 2013 at 10:45 AM, Ethan Gruber ewg4x...@gmail.com wrote: I see that serialization has a different definition in computer science than I thought it did. On Tue, Nov 19, 2013 at 10:36 AM, Ross Singer rossfsin...@gmail.com wrote: That's still not a serialization. It's just a similar data model. Pretty huge difference. -Ross. On Tue, Nov 19, 2013 at 10:31 AM, Ethan Gruber ewg4x...@gmail.com wrote: I'm not sure that I agree that RDF is not a serialization. It really depends on the context of the system and intended use of the linked data. For example, TEI is designed with a specific purpose which cannot be replicated in RDF (at least, not very easily at all), but deriving RDF from highly-linked TEI to put into an endpoint can open doors to queries which are otherwise impossible to make on the data. This certainly requires some rethinking of the way texts interact. But perhaps it may be best to say that RDF *can* (but not necessarily) be a derivation, rather than serialization, of some larger, more complex canonical data model. Ethan On Tue, Nov 19, 2013 at 9:54 AM, Aaron Rubinstein arubi...@library.umass.edu wrote: I think you’ve hit the nail on the head here, Karen. I would just add, or maybe reassure, that this does not necessarily require rethinking your existing metadata but how to translate that existing metadata into a linked data environment. Though this might seem like a pain, in many cases it will actually inspire you to go back and improve/increase the value of that existing metadata. This is definitely looking awesome, Eric! Aaron On Nov 19, 2013, at 9:41 AM, Karen Coyle li...@kcoyle.net wrote: Eric, I think this skips a step - which is the design step in which you create a domain model that uses linked data as its basis. RDF is not a serialization; it actually may require you to re-think the basic structure of your metadata. The reason for that is that it provides capabilities that record-based data models do not. Rather than starting with current metadata, you need to take a step back and ask: what does my information world look like as linked data? I repeat: RDF is NOT A SERIALIZATION. kc On 11/19/13 5:04 AM, Eric Lease Morgan wrote: I believe participating in the Semantic Web and providing content via the principles of linked data is not rocket surgery, especially for cultural heritage institutions -- libraries, archives, and museums. Here is a simple recipe for their participation: 1. use existing metadata standards (MARC, EAD, etc.) to describe collections 2. use any number of existing tools to convert the metadata to HTML, and save the HTML on a Web server 3. use any number of existing tools to convert the metadata to RDF/XML (or some other serialization of RDF), and save the RDF/XML on a Web server 4. rest, congratulate yourself, and share your experience with others in your domain 5. after the first time though, go back to Step #1, but this time work with other people inside your domain making sure you use as many of the same URIs as possible 6. after the second time through, go back to Step #1, but this time supplement access to your linked data with a triple store, thus supporting search 7. after the third time through, go back to Step #1, but this time use any number of existing tools to expose the content in your other information systems (relational databases, OAI-PMH data repositories, etc.) 8. for dessert, cogitate ways to exploit the linked data in your domain to discover new and additional relationships between URIs, and thus make the Semantic Web more of a reality What do you think? I am in the process of writing a guidebook on the topic of linked data and archives. In the guidebook I will elaborate on this recipe and provide instructions for its implementation. [1] [1] guidebook - http://sites.tufts.edu/liam/ -- Eric Lease Morgan University of Notre Dame -- Karen Coyle kco...@kcoyle.net http://kcoyle.net m: 1-510-435-8234 skype: kcoylenet
Re: [CODE4LIB] linked data recipe
Eric, if you want to leap into the linked data world in the fastest, easiest way possible, then I suggest looking at microdata markup, e.g. schema.org.[1] Schema.org does not require you to transform your data at all: it only requires mark-up of your online displays. This makes sense because as long as your data is in local databases, it's not visible to the linked data universe anyway; so why not take the easy way out and just add linked data to your public online displays? This doesn't require a transformation of your entire record (some of which may not be suitable as linked data in any case), only those things that are likely to link usefully. This latter generally means things for which you have an identifier. And you make no changes to your database, only to display. OCLC is already producing this markup in WorldCat records [2]-- not perfectly, of course, lots of warts, but it is a first step. However, it is a first step that makes more sense to me than *transforming* or *cross-walking* current metadata. It also, I believe, will help us understand what bits of our current metadata will make the transition to linked data, and what bits should remain as accessible documents that users can reach through linked data. kc [1] http://schema.org, and look at the work going on to add bibliographic properties at http://www.w3.org/community/schemabibex/wiki/Main_Page [2] look at the linked data section of any WorldCat page for a single item, such ashttp://www.worldcat.org/title/selection-of-early-statistical-papers-of-j-neyman/oclc/527725referer=brief_results On 11/19/13 7:54 AM, Eric Lease Morgan wrote: On Nov 19, 2013, at 9:41 AM, Karen Coyle li...@kcoyle.net wrote: Eric, I think this skips a step - which is the design step in which you create a domain model that uses linked data as its basis. RDF is not a serialization; it actually may require you to re-think the basic structure of your metadata. The reason for that is that it provides capabilities that record-based data models do not. Rather than starting with current metadata, you need to take a step back and ask: what does my information world look like as linked data? I respectfully disagree. I do not think it necessary to create a domain model ahead of time; I do not think it is necessary for us to re-think our metadata structures. There already exists tools enabling us — cultural heritage institutions — to manifest our metadata as RDF. The manifestations may not be perfect, but “we need to learn to walk before we run” and the metadata structures we have right now will work for right now. As we mature we can refine our processes. I do not advocate “stepping back and asking”. I advocate looking forward and doing. —Eric Morgan -- Karen Coyle kco...@kcoyle.net http://kcoyle.net m: 1-510-435-8234 skype: kcoylenet
Re: [CODE4LIB] linked data recipe
Hasn't the pendulum swung back toward RDFa Lite ( http://www.w3.org/TR/rdfa-lite/) recently? They are fairly equivalent, but I'm not sure about all the politics involved. On Tue, Nov 19, 2013 at 11:09 AM, Karen Coyle li...@kcoyle.net wrote: Eric, if you want to leap into the linked data world in the fastest, easiest way possible, then I suggest looking at microdata markup, e.g. schema.org.[1] Schema.org does not require you to transform your data at all: it only requires mark-up of your online displays. This makes sense because as long as your data is in local databases, it's not visible to the linked data universe anyway; so why not take the easy way out and just add linked data to your public online displays? This doesn't require a transformation of your entire record (some of which may not be suitable as linked data in any case), only those things that are likely to link usefully. This latter generally means things for which you have an identifier. And you make no changes to your database, only to display. OCLC is already producing this markup in WorldCat records [2]-- not perfectly, of course, lots of warts, but it is a first step. However, it is a first step that makes more sense to me than *transforming* or *cross-walking* current metadata. It also, I believe, will help us understand what bits of our current metadata will make the transition to linked data, and what bits should remain as accessible documents that users can reach through linked data. kc [1] http://schema.org, and look at the work going on to add bibliographic properties at http://www.w3.org/community/schemabibex/wiki/Main_Page [2] look at the linked data section of any WorldCat page for a single item, such ashttp://www.worldcat.org/title/selection-of-early- statistical-papers-of-j-neyman/oclc/527725referer=brief_results On 11/19/13 7:54 AM, Eric Lease Morgan wrote: On Nov 19, 2013, at 9:41 AM, Karen Coyle li...@kcoyle.net wrote: Eric, I think this skips a step - which is the design step in which you create a domain model that uses linked data as its basis. RDF is not a serialization; it actually may require you to re-think the basic structure of your metadata. The reason for that is that it provides capabilities that record-based data models do not. Rather than starting with current metadata, you need to take a step back and ask: what does my information world look like as linked data? I respectfully disagree. I do not think it necessary to create a domain model ahead of time; I do not think it is necessary for us to re-think our metadata structures. There already exists tools enabling us — cultural heritage institutions — to manifest our metadata as RDF. The manifestations may not be perfect, but “we need to learn to walk before we run” and the metadata structures we have right now will work for right now. As we mature we can refine our processes. I do not advocate “stepping back and asking”. I advocate looking forward and doing. —Eric Morgan -- Karen Coyle kco...@kcoyle.net http://kcoyle.net m: 1-510-435-8234 skype: kcoylenet
Re: [CODE4LIB] linked data recipe
On Nov 19, 2013, at 9:54 AM, Aaron Rubinstein arubi...@library.umass.edu wrote: I think you’ve hit the nail on the head here, Karen. I would just add, or maybe reassure, that this does not necessarily require rethinking your existing metadata but how to translate that ^ existing metadata into a linked data environment. Though this might seem like a pain, in many cases it will actually inspire you to go back and improve/increase the value of that existing metadata... There are tools allowing people to translate existing metadata into a linked data environment, and for right now, I advocate that they are good enough. I will provide simplistic examples. For people who maintain MARC records: 1. convert the MARC records to MARCXML with the MARCXML Toolkit [1] 2. convert the MARCXML to RDF/XML in the manner of BIBFRAME’s transformation service [2] 3. save the resulting RDF/XML on a Web server 4. convert the MARC (or MARCXML) into (valid) HTML 5. save the resulting HTML on a Web server 6. for extra credit, implement a content negotiation service for the HTML and RDF/XML 7. for extra extra credit, implement a SPARQL endpoint for your RDF If one does Steps #1 through #5, then they are doing linked data and participating in the Semantic Web. That is the goal. For people who maintain EAD files: 1. transform the EAD files into RDF/XML with a stylesheet created by the Archives Hub [3] 2. save the resulting RDF/XML on a Web server 3. transform the EAD into HTML, using your favorite EAD to HTML stylesheet [4] 4. save the resulting HTML on a Web server 5. for extra credit, implement a content negotiation service for the HTML and RDF/XML 6. for extra extra credit, implement a SPARQL endpoint for your RDF If one does Steps #1 through #4 of this example, then they are doing linked data and participating in the Semantic Web. That is the goal. In both examples the end result will be a valid linked data implementation. Not complete. Not necessarily as thorough as desired. Not necessarily as accurate as desired. But valid. Such a process will not expose false, incorrect data/information, but rather data/information that is intended to be maintained, improved, and updated on a continual basis. Finally, I want to highlight a distinction between well-formed, valid, and accurate information — linked data. I will use XML as an example. XML can be “well-formed”. This means it is syntactically correct. Specific characters are represented by entities. Elements are correctly opened and closed. The whole structure has a single root. Etc. The next level up is “valid”. Valid XML is XML that conforms to a DTD or schema; it is semantically correct. It means that required elements exist, and are presented in a particular order. Specific attributes used in elements are denoted. And in the case of schemas, values in elements and attributes take on particular shapes beyond simple character data. Finally XML can be “accurate” (my term). This means the assertions in the XML are true. For example, there is nothing stopping me from putting the title of a work in an author element. How is the computer expected to know the difference? It can’t. Alternatively, the title could be presente! d as “Thee Adventrs Av Tom Sawher”, when the more accurate title may be “The Adventures of Tom Sawyer”. Well-formedness and validity is the domain of computers. Accuracy is the domain of humans. In the world of linked data, you are not participating if your published data is not “well-formed”. (Go back to start.) You are participating if it is “valid”. But you are really doing really well if the data is “accurate”. Let’s not make this more difficult than it really is. [1] MARCXML Toolkit - linked at http://www.loc.gov/standards/marcxml/ [2] BIBFRAME’s transformation service - http://bibframe.org/tools/transform/start [3] Archives Hub stylesheet - http://data.archiveshub.ac.uk/xslt/ead2rdf.xsl [4] EAD to HTML - for example, http://www.catholicresearch.net/data/ead/ead2html.xsl — Eric Morgan
Re: [CODE4LIB] linked data recipe
On Nov 19, 2013, at 11:09 AM, Karen Coyle li...@kcoyle.net wrote: Eric, if you want to leap into the linked data world in the fastest, easiest way possible, then I suggest looking at microdata markup, e.g. schema.org. [1] … [1] http://schema.org I don’t advocate this as the fastest, easiest way possible because it forces RDF “aggregators” to parse HTML, and thus passes a level of complexity down the processing chain. Expose RDF as RDF, not embedded in another format. I do advocate the inclusion of schema.org mark-up, RDFa, etc. into HTML but rather as a level of refinement. —Eric Morgan
[CODE4LIB] Job: Business Analyst at Harvard University
Business Analyst Harvard University Cambridge, MA The Business Analyst will support leadership of the Harvard Library by identifying operational data needs, mining information systems, and providing analysis to inform business performance assessment and decisions. Reporting to the Director, Financial Planning and Analysis, the Business Analyst will: * Maintain and develop the library's information and organizational performance systems * Provide reporting and supporting assessment advice and analysis to inform strategic decisions * Enhance the library's information and assessment systems and ability to collect and report useful data * Support librarians in finding and using data in their daily work This role will collaborate with staff across a wide range of functions and disciplines in order to better coordinate the collection and creation of data as it relates to the performance goals of the Harvard Library. **Duties and Responsibilities:** The Business Analyst works closely with the Harvard Library leadership and with librarians across the broader library system. Specific components of the role include: _Maintain and develop the library's information and organizational performance systems_ * In consultation with Harvard Library leadership, design, develop and maintain systems to measure library progress as it relates to library strategic initiatives and operational efficiency * Improve methods used to measure key metrics * Develop and monitor annual baselines for key metrics and monitor progress * Lead the preparation of organizational performance updates and associated reporting * Communicate and explain findings to library senior leadership _Provide reporting and supporting assessment advice and analysis to inform strategic decisions_ * Work collaboratively with Harvard Library leadership to discover information needs and to identify, prioritize, design and implement new reporting tools and solutions * Analyze information (e.g., bibliographic, financial, usage) in support of evolving needs * Provide consultation and technical assistance to Harvard Library leadership with use and interpretation of data * Respond to requests for data and/or reports on a variety of issues related to the library collections reporting and statistics, including ad hoc analyses and special requests * Lead in data collection and aggregation across partnerships with other institutions (including Borrow Direct Partners) to aggregate data and business intelligence to help improve and expand alliances * Lead the data collection efforts for national surveys (ARL statistics) and the preparation of data for annual HL reports _Enhance the Library's assessment systems and ability to collect and report useful data_ * Develop structures for collecting, storing and presenting or sharing data in consultation with appropriate IT and Library colleagues * Design, develop, troubleshoot, document, and analyze reports for Harvard Library * Maintain internal sites to house data, distribute reports, associated documentation and explanatory materials * Provide consultation to Harvard Library leadership on developing assessment surveys and user studies _Support librarians in finding and using data in their daily work_ * Facilitate data-driven decision making throughout the Harvard Library by committing to make data as accessible and transparent as possible; teaching/mentoring librarians how to access, query, manipulate, and visualize data * Develop reporting mechanisms to enable managers and staff to run and analyze data in support of data driven decision making **Basic Qualifications** * Bachelor's degree or equivalent education or work experience required * Seven plus years of experience working in IT, business intelligence, library assessment, financial or statistical analysis, financial reporting and/or libraries * Strong knowledge of Excel and of database tools (e.g., Microsoft Access) **Additional Qualifications** * MLS, MBA, and/or advanced degree in statistics, information sciences, or engineering * Experience building reports and queries with Business Intelligence/Analytics tools (Cognos BI, Microsoft) * Working knowledge of libraries, both within Harvard and more general industry trends * Knowledge of Integrated Library Systems, such as Aleph * Knowledge of statistical software packages (e.g. SPSS, R, STATA) * Knowledge of database tools such as Quickbase and content management systems * Proven ability to deliver quality analysis in a fast-paced environment * Excellent analytic, written and verbal communication skills * Ability to process and distill complex information, present complicated information in easily comprehensible formats * Ability to work in ambiguous environment: to define objectives, set tasks, build relationships, and achieve outcomes * Exceptional numeric skills: able to use
[CODE4LIB] Job: Metadata Integration and Delivery Specialist at University of Virginia Library
Metadata Integration and Delivery Specialist University of Virginia Library Charlottesville, VA The University of Virginia Library seeks a Metadata Integration and Delivery Specialist for Metadata Management Services. The University of Virginia Library is place of infinite possibility! We are looking for high energy, innovative professionals with integrity and a strong work ethic. We seek individuals who are not afraid of taking risk and have the proven ability and/or potential to get positive results, manage change, and collaborate with others effectively. We want creative professionals who possess a keen and deep understanding of what it takes to continuously improve and maintain a major academic research library. Metadata Management Services facilitates access to library managed content, participates in partnerships to share expertise and provide innovation in data management, and engages fully in the mission of the University of Virginia. Reporting to the Metadata Librarian, the Metadata Integration and Delivery Specialist supports that mission by collaborating with colleagues within and outside of the department and Library to determine and document best practices and workflows for non-MARC metadata creation. This position is charged with finding creative, collaborative and sustainable solutions for providing and managing metadata for a variety of physical and digital resources. This position will also have responsibility for describing resources in a variety of formats, following local and national standards. The employee in this position is encouraged to be current with the community of practice for non-MARC metadata and stay abreast of developments within the broader field of information organization. Qualifications Required: Bachelor's degree. Experience with library metadata standards and application, and demonstrated ability to work independently and collaboratively across groups to achieve objectives. Demonstrated ability to create metadata according to established rules and standards. Ability to communicate effectively orally and in writing. Excellent interpersonal skills. Preferred: Master of Science in Library Science or related field. To Apply: Complete a Candidate Profile, attach a cover letter, cv, and contact information for three professional references through Jobs@UVA (Posting #0613248). For assistance with this process contact Charlotte Albright (cd...@virginia.edu), Library Human Resources Generalist at (434) 243-3509. Review of applications will begin December 6, 2013. The University of Virginia is an affirmative action/equal opportunity employer committed to diversity, equity, and inclusiveness. Brought to you by code4lib jobs: http://jobs.code4lib.org/job/10761/
Re: [CODE4LIB] linked data recipe
+1 for schema.org as one of the first steps. COinS are another useful simple mark-up if the data is already there. I'm looking forward to the book. Sincerely, David Bigwood Lunar and Planetary Institute -Original Message- From: Code for Libraries [mailto:CODE4LIB@LISTSERV.ND.EDU] On Behalf Of Karen Coyle Sent: Tuesday, November 19, 2013 10:10 AM To: CODE4LIB@LISTSERV.ND.EDU Subject: Re: [CODE4LIB] linked data recipe Eric, if you want to leap into the linked data world in the fastest, easiest way possible, then I suggest looking at microdata markup, e.g. schema.org.[1] Schema.org does not require you to transform your data at all: it only requires mark-up of your online displays. This makes sense because as long as your data is in local databases, it's not visible to the linked data universe anyway; so why not take the easy way out and just add linked data to your public online displays? This doesn't require a transformation of your entire record (some of which may not be suitable as linked data in any case), only those things that are likely to link usefully. This latter generally means things for which you have an identifier. And you make no changes to your database, only to display. OCLC is already producing this markup in WorldCat records [2]-- not perfectly, of course, lots of warts, but it is a first step. However, it is a first step that makes more sense to me than *transforming* or *cross-walking* current metadata. It also, I believe, will help us understand what bits of our current metadata will make the transition to linked data, and what bits should remain as accessible documents that users can reach through linked data. kc [1] http://schema.org, and look at the work going on to add bibliographic properties at http://www.w3.org/community/schemabibex/wiki/Main_Page [2] look at the linked data section of any WorldCat page for a single item, such ashttp://www.worldcat.org/title/selection-of-early-statistical-papers-of-j-neyman/oclc/527725referer=brief_results
[CODE4LIB] Job: Associate Developer (Ruby on Rails) at WGBH Educational Foundation
Associate Developer (Ruby on Rails) WGBH Educational Foundation Boston **Position Title:** Associate Developer (Ruby on Rails) **Position Type:** Project Contract 12/02/13 to 12/31/14+ **Company:** WGBH Educational Foundation **Department:** Media Library Archives **Department Overview:** WGBH produces the best and most well-known television, radio and online programs for public media. The WGBH Media Library and Archives preserves and helps re-purpose WGBH creations into the future. The MLA establishes the policies and procedures for the access, acquisition, intellectual control, and preservation of WGBH's physical media and digital production and administrative assets. The MLA also offers production organization of archival materials from projects start up to shut down, research services, rights clearances, and licenses WGBH stock footage. **Position Overview:** The WGBH Media Library and Archives system will be based on the Hydra Project technology stack, which includes Ruby on Rails, Blacklight, Apache Solr, and the Fedora Commons repository. Working closely with the Media Library and Archive's Director, Project Manager, Developer and Systems Analyst, as well as a WGBH Interactive Designer, the web developer will continue to develop the Open Vault website: http://openvault.wgbh.org and ongoing work to improve the digital asset management system. **Ideal candidates should be:** • comfortable working in teams of 2 to 6 • able to communicate clearly and respectfully to all team members, both technical and non-technical • willing to explore new technologies **Duties** will depend on individual strengths, but may include any of: • general Rails development • streaming video integration and presentation • organizing and writing documentation • usage stats and analytics • DevOps and deployment • performance stats, analysis and optimization **Required skills** for all tasks include having working knowledge of: • Ruby = 1.9.3 • Rails = 3.2.0, common conventions, patterns, and best practices, TDD with Rspec and Capybara (or equivalent) • Github • CSS3 + HTML5 • XML basics • working from command line (OS X or Linux) **Other skills** that will come in handy for other project tasks include having a experience with: • SCSS • jQuery • Twitter Bootstrap • building REST apis • Rails gem patterns • HTML 5 video and various javascript players • Rails deployment w/ Capistrano • SQL basics • Fedora Commons repository • working with XML, e.g. translating using XSL, parsing with Nokogiri, Education Requirements: Bachelor's Degree in Computer Science required. **Compensation:** Compensation for this position will be determined by the skills, background, education and availability of the candidate for the Contract period. **Applying for the Position:** Candidates should apply at www.wgbh.org/careers. Reference Job REQ# P-1075 **Further questions** can be addressed to Dani Baptista (dani_bapti...@wgbh.org). Please put REQ# P-1075 Associate Developer in the subject line. Brought to you by code4lib jobs: http://jobs.code4lib.org/job/10762/
[CODE4LIB] Programmatic retrieval of book series info?
Our circ staff would like to retrospectively add labels to our fiction series so patrons can suss out series information at a glance (which series, numbering). I can pull out the titles, authors, ISBNs, etc. from our catalog easily enough, but I'm wondering how best to approach matching each title with the appropriate series info. GoodReads has an API, for example, but wondering if anyone on the list has already come up with a good method or has suggestions. Many thanks in advance, Cab Vinton, Director Plaistow Public Library Plaistow, NH
[CODE4LIB] ruby-marc api design feedback wanted
ruby-marc users, a question. I am working on some Marc8 to UTF-8 conversion for ruby-marc. Sometimes, what appears to be an illegal byte will appear in the Marc8 input, and it can not be converted to UTF8. The software will support two alternatives when this happens: 1) Raising an exception. 2) Replacing the illegal byte with a replacement char and/or omitting it. I feel like most of the time, users are going to want #2. I know that's what I'm going to want nearly all the time. Yet, still, I am feeling uncertain whether that should be the default. Which should be the default behavior, #1 or #2? If most people most of the time are going to want #2 (is this true?), then should that be the default behavior? Or should #1 still be the default behavior, because by default bad input should raise, not be silently recovered from, even though most people most of the time won't want that, heh. Jonathan
[CODE4LIB] RHEV-M
Is anyone using RHEV-M to manager their Linux virtual server environment? We are interested in talking to someone about their experience. We have found plenty of people to talk to about VMware, but would like to investigate an alternative. Thanks for your help. Lynne
