F, G, 3
R. David Lankes
The following questions and answers about Scapes development are derived from a consideration of a proposal before the MacArthur Foundation. There are two answers to each question. The first is the quick answer, followed by a more in-depth response that contains more technical detail. It should be noted that these questions and answers, although useful generally, were focused on a single development effort for Scapes.
Who do you see as your primary audience for Scapes?
Quick response: The initial audience for Scapes1 will be library learners—those individuals using library services for formal (e.g., K-12 and college students) and informal education (e.g., members of the general public engaged in research).
More Detail: This population is chosen for a few reasons:
• The library community is a coherent and easily engaged partner in the process. Initial discussions of the Scapes concept within this community have generated enthusiasm, and it is believed that libraries will be willing to provide input, testing, and resources into all phases of development. Further, libraries have experience in evaluating software.
• Libraries have a known need for this type of software. Libraries know they need better systems to engage users in their learning processes. There is wide discontent with current catalogs and virtual reference software. Scapes can help fill these needs.
• Libraries represent a diverse user population. Although the library community is coherent (it shares an education base, it has a lot of professional structures such as conferences and associations), their reach is diverse. Libraries can test Scapes in populations of students, government workers, lawyers, scholars, and more.
• Libraries have resources that can seed initial user-generated scapes. Libraries not only hold a large and diverse set of materials, they have well-structured metadata for these collections that will make inclusion in Scapes relatively easy.
For these reasons, libraries are seen as an ideal target audience and initial set of partners, but that does not mean that the utility of Scapes is limited to libraries. Once the initial infrastructure is in place, Scapes is seen as general-purpose software that is functionality useful in any knowledge representation endeavor.
Some examples might be useful. It should be noted that the illustrations are just simple ideas—sketches really. The final interface will be determined by the specification and implementation processes.
Riley is doing a report on global warming. In his school library, he searches the catalog for books on the topic. He finds a few promising titles and adds them to a new scape right through the catalog’s web interface. He then checks out the books. At home, after reading the books, he opens his web browser and brings up the scape he started at school (he also has scapes for personal projects and other classes). Right now it is little more than a scattered collection of “nodes,” each representing the books he checked out.
Riley now deletes a text that wasn’t relevant and begins to sort the remaining books. He puts all the books on weather effects into one pile. He draws a line from that pile to another book that refutes global warming and labels the line as such. Now he begins searching his library’s online databases through the web-based Scapes interface for articles on the topic. As he finds relevant articles, he drags them into the scape he is working on and connects them with links such as “Global Warming in Politics” and “The Science of Global Warming.” He ends up with a Scape that looks like the one found in figure 204.
At this point, Riley could simply add his teacher to the list of those authorized to see his Scape and submit it as his assignment; however, his teacher wants a written report. Riley exports the Scape as an outline. The links become major headers in the report, and each node (book, article, etc.) is listed as a citation. He opens the outline in his word processor and begins to write.
The use of a tool like Scapes in K–12 education is not completely without precedent. Scapes is similar to mind mapping already in wide use in K–12 education. There are, however, some key differences. These differences range from the model of representation—mind or concept mapping requires a “root node” from which all ideas must stream—to the technical—most mind mapping applications do not work with computationally useful nodes, rather focusing on visual maps.
Sue is a college professor preparing a course on global warming to be offered during the next semester. The normal procedure would be to write a syllabus with a course introduction and list of readings, put the readings on reserve with the college library, and upload additional materials in an online course management system like Blackboard. This setup already requires students to go to three separate sources for course information.
Instead, Sue creates a Scape for the course, linking in her content, as well as readings on reserve at the library and on the web. This Scape is not a simple list of readings but a connected system that shows how the readings and course content are related. Also, since the Scape will be made available to Sue’s students, it is interactive. The students can connect the course Scape to their own Scape with assignments, discussions, and reactions. Sue can also use the chat functionality of the Scapes software to work with students remotely.
So the initial Scape might look like the screenshot in figure 205 from an early mockup.
One of Sue’s students can then connect his or her own Scape (using the previous K–12 example) to the class scape found in figure 206.
What’s more, all of these scapes can be made public2 within the college to represent what the college community knows and its approach to a given topic. Now anyone who finds Sue’s course syllabus can also see examples of student work (if the students give permission). This would allow for better program accreditation and evaluation.
Syracuse, like many urban centers, has a youth violence issue. The mayor has task forces, community groups are involved, and the University wants to help. One of the first steps to combating any problem is understanding what it is. When combating a problem requires multiple groups to be involved, a shared understanding of the problem is essential.
The public library creates a scape of the youth violence issue. The librarians pre-populate it with articles and books that might be helpful. Experts are asked to contribute to the scape, and community groups are asked to join in mapping the issue and possible solutions. Governmental agencies add information on existing programs. Community foundations add the outcome of their funded work, as well as information on possible resources available to combat youth violence. Where disagreement occurs, new scapes are created to represent divergent views. Over time, these differences are discussed, and most of these alternatives are incorporated into a common view.
As a plan emerges, it is tied back to the literature, best practices, community agencies, and planning documents. Videos of town hall meetings are added to the scape to provide a crucial memory for the long-term plan. As new services are created, tried, and evaluated, they too are pointed to from within the community scape.
This could have all been done with a wiki of course. However, a wiki would not allow the visual representation, or, more important, the intelligent use of objects such as materials, ideas, people, and organizations. Because this information is within a scape, other communities tackling the youth violence issue can reuse it. Agency names and contact information can easily be changed, with Syracuse acting as a template for other urban centers. Other tools can also be used with the scape, for example, placing agencies and resources on a map or exporting portions of the scape for grant applications or reports.
The scape on youth violence can also be linked into other community- wide efforts in economic development, beautification, education, transportation, and so on. Although this can be done with today’s web-based tools, the links are one way, as opposed to bi-directional, and would require a multitude of interfaces and systems. Scapes can act as not only a high-level view of a problem but a sort of glue to a vast variety of resources.
Can you expand on how people would use/access Scapes? We’re having trouble understanding how this would be implemented.
Quick Answer: The initial deliverable will be a website where users can log in and create their Scapes. This website will present users with a view of (1) all the public Scapes being created, (2) the Scapes that the user is working on (individually, as part of a group, or simply public Scapes the user contribute to), and (3) finally the actual interface for building and editing Scapes. This can be seen in figure 207.
This centralized site will also allow organizations to integrate Scapes’ functionality in their own sites like they can now include maps from Google and videos from YouTube. For example, a library might include a link to the Scapes site right in its catalog. A user clicking on the link would be taken to the Scapes site and shown a set of all the scapes containing the object selected in the catalog (see figure 208).
Once a user creates a scape, he or she can embed an interactive version of it in his or her own site with a simple cut and paste (just like YouTube). With this embedding capability, just about anywhere a user can cut and paste HTML code, he or she can include a fully interactive version of the scape. For instance, a user could paste it into a blog entry (see figure 209).
So the community group from the previous example could include its joint scape on its team’s webpage, or MacArthur could create a scape of all its grants and grantees in a given area (say on credibility) and include it in a listing of the grants.
The Scapes server software will also be offered as a download so that anyone can download and create his or her own scapes site (or integrate scapes into his or her own site). Like the web, which creates a set of connected pages on different sites, the Scapes specification and software will enable easy linking between sites. This arrangement will allow organizations concerned about security or reliability to set up internal Scapes systems.
A good analogy would be Wikipedia. Users create accounts and contribute to the Wikipedia site, but anyone can download the software used to build and maintain Wikipedia, called MediaWiki.3 The Scapes specification can also be used so that people could write their own software that can create interconnected scapes. Thus, one might imagine a Scapes desktop system that would allow users to create scapes when disconnected from the Internet, say on a plane.
Scape implementation consists of really four parts: a specification, a reference server implementation, a reference user interface, and a facilitating infrastructure. Each is explained below.
When the web was initially developed, it was little more than a multipage document of specifications. These specifications outlined the basics of how to mark up documents (HTML) and a protocol for sending data across the Internet (the HyperText Transfer Protocol [HTTP]). It was this specification developed by Tim Berners-Lee that was adopted by the National Center for Supercomputing Applications (NCSA) and used to create Mosaic and the first web server.
Today, it is the specifications that underlie thousands of different web servers (with Apache and Microsoft’s Internet Information Server being the most widely deployed) and the various web browsers (Internet Explorer, Chrome, FireFox, Farari, Opera, etc.). It is the web specification that enables Google and MacFound.org. It is the specification that will ultimately dictate the success and shape of Scapes. The Scapes specification will need to define the file format of a Scape. It is currently assumed that this will involve RDF and an XML application. Think of this as the file format of a Scape that could be copied onto a hard drive and e-mailed around. This format will have to accommodate node descriptions, bidirectional linking (so both an object pointing and being pointed to are aware of the link—this allows for the easy identification of dead or altered links as well as enhanced search).
The specification will also have to define minimal interactions with Scapes such as adding a node, adding a link, describing a link, deleting nodes, and so on. The idea is to, like HTML, keep the specifications simple and allow for rich interactions through combining interactions.
Perhaps the most important part of the specification will be in how Scapes work in a networked environment. This part of the specification will have to link up the different anticipated Scapes servers together. The initial thought (described more fully under infrastructure) is a central registry system. Here the different Scapes servers would communicate what Scapes are available and where to find them. The network part of the specification will have to handle questions of unique identifiers for Scapes and nodes within a Scape. This portion of the specification is also, frankly, where much of the lessons learned about the deficiencies of the web standards can be addressed in terms of searching across Scapes and dead links.
Reference Server Implementation
However good a specification is, without real software and real examples, it will go nowhere. From experience with many projects such as AskERIC, the Gateway to Educational Materials, and the Virtual Reference Desk, the team behind Scapes has learned some valuable lessons that will be brought to Scapes. The first is the need for real software that is functional from the start. It is much harder to convince anyone else to implement specifications without having done it yourself. There is a need for examples. What’s more, there is no sense in low-balling the example. That is to say, the example should strive to be the best in class. This way if there are initially few others building servers, the one built by the project is more than adequate for satisfying user needs. Also, the first mover in a given space on the web tends to gain a large user base, so you want the majority of users using the best software.
For this reason, the reference server implementation will strive to be the best central system for creating Scapes. It will need to provide for user accounts (including sophisticated identity management as discussed in question 3), rich interactions, embedding of Scapes within other systems and pages (as discussed in the “Quick Answer”), powerful searching across Scapes, and easy expansion (via APIs as discussed in question 4). The server is anticipated to be a LAMP implementation (LAMP is short for Linux, Apache, MySQL, and PHP and describes a widely available server environment so that people can easily implement Scapes on their own servers).
Reference User Interface
The user interface for Scapes will consist of the construction space of the Scapes (adding, linking, and describing nodes), as well as a means of managing multiple Scapes by a single user and millions of Scapes for the entire web community. In essence, all of the diagrams used in this addendum are simplified initial guesses at what the user interface will look like. It is also assumed that others using the Scapes specification can create a whole raft of new user interfaces including interfaces for mobile phones, differing operating systems, and more. Infrastructure
To fully realize the potential of Scapes, there must be not only several implementations but a way of tying an active development and implementation community together. To maximize the diffusion of Scapes, there must be infrastructure to keep the differing scapes connected. As alluded to under specifications there will need to be some technical infrastructure in place to stitch together Scapes. This includes a registry of Scapes implementations, a system to assign unique IDs to Scapes and their objects, and a sort of interchange for linking. This link interchange will monitor the objects being linked across all Scapes and notify users (and servers) if either end of a link has changed. This will allow for services like leak deletion, creating cached version of objects to maintain the integrity of Scapes, and search services.
All of these parts are represented in figure 210 with the deliverables of this grant outlined in the dotted line.
Other infrastructure will not be technical. This will include a clearinghouse on Scapes development and implementations, an ongoing body to discuss extensions and alterations to the Scapes specification, a directory of Scape extensions, and other ways of tracking a community engaged with Scapes.
All of this detail may seem burdensome or grandiose. The philosophy is to plan for success but guarantee initial utility. That is to say, build a tool that can be used right away. If a community of developers and other Scapes implementations do not emerge, the central site will still have great functionality. If the community does develop, the growth can be managed.
Could there be a “public Scapes”—one that you share with others—and a “private Scapes”—one that you use only to organize your own research/ work/relationships?
Quick Answer: The short answer is yes. Scapes files can be private, shared with a group, or public. Likewise, a Scape can be shared in full or read-only.
More Detail: To do this, the Scapes specification will have to include a common way of handling “identity management.” Every Scape will have to have an identity or identities associated with it. This will allow functionality such as notifying Scapes creators of changes to items and other Scapes they might have pointed to (thus avoiding the dead link problem or pointing to outdated URL’s in the current open web).
It is worth noting that “identity” is not the same as “person.” Identities may be as simple as a username or an e-mail address. However, as they get more complex, they can allow for greater access to resources. For example, if a Scape author provides a university ID, he or she can get the full text of articles in a Scape, whereas an anonymous user may simply receive the bibliographic information.
Are there challenges around interoperability and content access (some people have access to certain databases and others do not, how would Scapes deal with this)?
Quick Answer: Much of the interoperability challenges are alleviated initially by working with links to objects, as opposed to manipulating the objects itself (i.e., linking to book records, not editing the records or creating them). This is much like how a user organizes files and folders on his or her computer. The software creating the folders and letting the user drag files around does not have to open and/or edit these files, just know their locations and what piece of software to use to actually open and work with the file.
More Detail: There are always interoperability challenges to face in terms of software systems. The initial plan to address them consists of four approaches.
1. High-Level Pointers
Scapes, like the web, are based on a pointer system. It connects objects with contextual links creating a set of relationships. As such, it does not have to be able to manipulate the related items (documents) directly. Think of how you organize your files on your computer. File Explorer in Windows or the Finder in the Mac Operating System needs to know some basic information about the file (its size and its type) and its location. It does not need to edit PDF files, just know that they are PDF files and where they are. It doesn’t need to understand all the objects it encounters, just link to them. Scapes are the same way. As long as they know an object’s location and some basic details, they do not need to get bogged down in all the intricacies of the file formats and features. What they do need to be able to do is read and manipulate metadata (descriptive information about the files). Also, as the product matures, it can add greater item-level functionality (just as in operating systems that have evolved to provide previews of file contents or quick printing).
2. Adherence to Metadata Standards
What Scapes will need to do is intelligently read and manipulate a variety of object metadata. The most obvious is the MARC standard to make incorporating library objects easy. They will also need to understand Dublin Core and HTML metatags—widely used metadata standards. This basic functionality will allow Scapes to take advantage of existing metadata in objects today. However, most of the objects that Scapes will encounter will have no metadata. This means the user will be adding metadata as he or she links objects together but in a different way from today’s object-centric approach to describing digital objects.
A normal approach to metadata is to use some separate editing program to describe an object—entering fields like title, author, and so on. This approach can take time, and the person describing the object has to anticipate all the potential uses of that object. Many people don’t realize this, but programs like Microsoft Word have this capability built in. Figure 211 is the screen that Word brings up when editing a file’s properties.
Figure 212 is the same functionality implemented in Adobe Acrobat. The reason that people don’t realize these screens exist is because it is an often unused capability. There are many reasons for this, but this is territory well covered in the original proposal. The point of this response is that if someone takes the time to enter these data, Scapes will use it. If not, Scapes will create metadata from the linking between objects. This is more useful because it is all about context.
3. Adherence to Web Standards
The area of interoperability on the web has come a long way in the past five years. There are several widely available and followed standards that will aid in tying objects together in Scapes. The first is the suite of Semantic web standards such as the Resource Description Framework (RDF) and the extensible Markup Language (XML). These two standards provide a clear way of linking together a disparate set of resources without a great deal of customization. XML will allow records to be read out of proprietary databases and library catalogs, for example. RDF is a way of describing relationships among objects, terms, and even people. Open-source RDF tools will allow for rapid development of Scapes, as well as the reuse of Scapes data in other applications.
4. Building an Open Platform for Expansion
The last approach to interoperability will be the extensive use of good Web 2.0 practices. That is, making it easy for people to add new functionality to Scapes and to include Scapes functionality into their own applications. The primary mechanism for this interoperability approach is the use of well-documented and web-accessible Application Programming Interfaces (APIs). An API is little more than a URL where another program (or web page) can send a request. For example, Google Maps has an API so that, with the use of a single piece of cut-and-paste HTML code, you can include a map on your web page. With a simple piece of HTML, you can also include a book cover from Amazon, a song title from Apple’s iTunes, book information from OCLC, and more. It is the API that will allow people to embed a web version of Scapes in whatever page they want.
APIs will also be used to handle issues of authentication into proprietary databases and access into for-fee resources. This is not an approach unique to Scapes. This will build on efforts throughout the academic and library world built up over the past decade—technologies such as OpenURL and Z39.50, for example. APIs will also allow users to embed different search engines directly into Scapes such as Google or the proposed Reference Extract product.
In many cases, the real story can be hidden behind an alphabet soup of standards. The best way to show how interoperability can be achieved with existing technologies is to show an example.
The Ann Arbor District Library’s Catalog, found at http://www. aadl.org/catalog, might look like a standard catalog application, but it is not. It is actually a piece of open source software called Drupal. Drupal sits between the user and the actual catalog. When the user searches for a book, Drupal sends the request via an API to the catalog (a proprietary piece of software). The results of the search are then processed by Drupal and presented to the user with additional features such as tags, user annotations, full-text page scans from Google Books, and other reviews. These additional functionalities come from all over the web but are presented seamlessly to the user using APIs.
Figure 213 shows (1) the listing the user sees from his or her search—it is information from the library catalog but presented to the user by Drupal that also adds links to (2) a program the Ann Arbor librarians wrote to simulate a physical card in a card catalog, (3) a link that takes you directly to the full text of the book (if available) in Google Book Search, (4) user-supplied annotations produced by Blackwell’s Book Services, and (5) user-supplied tags and comments stored by Drupal.
If you are having a hard time following my diagrams, all you need to know is that at least five different systems are being utilized for this one book, and the user does not have to know. What’s more, the five different services don’t have to know anything about the other applications (in other words, Google has no idea that the Ann Arbor Library is pointing to its books). It would be a simple matter for the library to add a link to any Scapes that included this book, for example.
I hope these responses were clarifying. If not, please let me know, and I can try again. What I hope is that the core of the Scapes idea is not lost in the important details. Yes, there are many challenges to developing Scapes, but there are huge pieces of existing software and interoperability standards already available on which to build. As with any new software project, there are sure to be challenges and unanticipated problems. However, the core idea that we need systems that allow us to represent knowledge, not things, remains. The true mission of Scapes is not to demonstrate the power of APIs or the intricacies of metadata. The true mission is to unlock the knowledge present in our communities. The mission is to build tools that can begin to capture the conversations and contexts of people. The mission is to break from the strangle hold of things and objects and move to knowing and action. These may seem like grand missions, but that is the point. The web has shown us the emergence of social knowledge. Wikipedia, Google, Amazon, and more thrive in a world of connected ideas. The web did not create the notion of linking; it simply made the links evident. In the same way, Scapes does not seek to invent or change how people know; they simply make it easier to share that knowing. The Scapes concept is a result of theory, practice, and hardwon experience.
1. Throughout this document “Scapes” with a capital S is used to refer to as the software product; “scapes” with a small s is referred to as a document types (so Scapes produces scapes).
2. See question 3 for more on public and private scapes.
Lankes, R. D. (2008, January 12). Scapes. Retrieved from http://quartz.syr.edu/rdlankes/blog/?p=459
Lankes, R. D. (2009). New concepts in digital reference. Synthesis Lectures on Information Concepts, Retrieval, and Services, 1(1). doi: 10.2200/S00166ED1V01Y200812ICR001.