hydra 6.2.0.rc1 → 6.2.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA1:
-  metadata.gz: 7f0fcaaabe73a7f2626f1cb5be5f6d28705a72c5
-  data.tar.gz: 728c7ef646a4e1cdcb346c1339c6d812b28ccee2
+  metadata.gz: dca5799096f3b249d3855d97f983d82d3682f000
+  data.tar.gz: e0679fded2bc13b82b274bc955ec42c6529f95c6
 SHA512:
-  metadata.gz: 4b1ab43c089521e0798d93693060ff8104f2d2c1863cb4e378c2978146a95b799f6e53c7ce8af0567af8a2ecf5ca88e3ac361c9c045b18b17826a4b33333f32a
-  data.tar.gz: 02404e6f4d9cf0f2bb96b32429a7c420e4560613a34503d48e9cac769f5fa5f80352de64328e80faf3faccdbb39a79750f4034e14c96da16cc6042ba0ffee621
+  metadata.gz: 99e85a8b24e88e1e5d4c5862d09bdea440e642d333b55178919591fb019ea050032a93b5a201f801db386064fef28c0ee04998fd15e6e221d3b277a14c183135
+  data.tar.gz: a2355c729901bd625b5f477d9fc61ddd19e1fa7464d908ddc7b6b37dbe9bc3bc60b4d5acd5285438f1069553f64b5436ae5cdae815b2f5c1e6735ecb2005b5c8

data/.gitignore

@@ -7,7 +7,6 @@ Gemfile.lock
 InstalledFiles
 _yardoc
 coverage
-doc/
 lib/bundler/man
 pkg
 rdoc

data/CONTRIBUTING.md

@@ -105,6 +105,9 @@ You should also add yourself to the `CONTRIBUTORS.md` file in the root of the pr
 * If you are uncertain, bring other contributors into the conversation by creating a comment that includes their @username.
 * If you like the pull request, but want others to chime in, create a +1 comment and tag a user.
 
+## New Developers
+A great way to get new developers involved and to learn the process is to have them go through the Hierarchy of Promises and create a pull request to improve it.
+
 # Additional Resources
 
 * [General GitHub documentation](http://help.github.com/)

data/RELEASE-POLICY.md

@@ -22,3 +22,43 @@ deprecations when the Hydra gem is updated.
 
 The `./script/query-for-deprecation.rb` is a tool to help report what methods
 have had a change in deprecation status.
+
+## Documentation for releases
+
+Our primary location for documentation is the Github wiki associated with this
+project. All pages from the Github wiki should be copied to `doc/` as part of
+a release.
+
+**Steps:**
+
+1. Get the latest version of the wiki. Note that Github wikis are git
+repositories, so you can treat them like any other.
+
+	```
+	# if you haven't yet done so, clone the wiki repo...
+	git clone git@github.com:projecthydra/hydra.wiki.git path/to/hydra.wiki
+
+	# or, if you have already cloned, then get the latest changes...
+	cd path/to/hydra.wiki
+	git pull
+	```
+
+1. Copy the wiki pages to `docs/` directory of `hydra` project.
+
+	```
+	cp -a path/to/hydra.wiki/* path/to/hydra/docs/
+	```
+
+1. Commit the changes.
+
+	```
+	cd path/to/hydra
+	git add docs/.
+	git commit -m "Updates the wiki docs"
+	```
+
+This commit should then be included as part of the pull request for the new
+release. See ["Making Changes"](/CONTRIBUTING.md#making-changes) and
+["Submitting Changes"](/CONTRIBUTING.md#submitting-changes) on the preferred
+way to submit pull requests.
+properly.

data/doc/Configuring-solr-and-fedora.md

@@ -0,0 +1,16 @@
+When you run the hydra generator (e.g. rails generatate hydra:head) the following files will be generated into your project:
+```
+      create  fedora_conf
+      create  fedora_conf/conf/development/fedora.fcfg
+      create  fedora_conf/conf/test/fedora.fcfg
+      create  solr_conf
+      create  solr_conf/conf/schema.xml
+      create  solr_conf/conf/solrconfig.xml
+      create  solr_conf/solr.xml
+```
+
+These files are configuration for the 4.0 version of solr and the 3.6.1 version of fedora. You should check these into your SCM.  If you need to change the configuration you should edit them in this directory and then copy them into your solr/fedora deployment.  If you are using hydra-jetty you can just call `rake jetty:config` to copy them into place.
+
+If you need a configuration suitable for a 3.6.0 version of solr, try these:
+* [[https://github.com/projecthydra/hydra-head/blob/4.1.x/solr_conf/conf/schema.xml]]
+* [[https://github.com/projecthydra/hydra-head/blob/4.1.x/solr_conf/conf/solrconfig.xml]] 

data/doc/Content-Type-Example:-Journal-Article.textile

@@ -0,0 +1,735 @@
+*This tutorial is only known to work with Hydra-Head 4. If you want to take over maintenance of this page, please do so.*
+
+h1. Adding a Content Type to Your Hydra Application:  Journal Article Example
+
+h2. Before You Begin
+
+This document assumes you have read "How to Get Started":https://github.com/projecthydra/hydra-head/wiki/How-to-Get-Started
+
+This document is a work in progress.  We are actively seeking feedback.  If you run into anything that is incorrect or confusing, please email the "hydra-tech":http://groups.google.com/group/hydra-tech mailing list and let us know.
+
+h3. What you will learn from this document
+
+# Understand how Hydra fits into and uses Rails MVC (Model, View, Controller) structures
+# Define an ActiveFedora Model for JournalArticles
+# Define Controller & Views for Creating, Editing, Viewing and Deleting Journal Articles
+# Customize how JournalArticles appear in Blacklight search results
+
+h3. If you get stuck
+
+We maintain a reference copy of the Hydra Head that is described in this Tutorial.  It contains working versions of all the Models, Controllers, Views, and tests that you will be creating.  If you get stuck, take a look at those files for ideas.  We also maintain a Hudson build for this reference copy in order to ensure that all of the tests pass.
+
+The code: http://github.com/projecthydra/hydra-tutorial-application
+The Hudson Build: http://hudson.projecthydra.org/job/hydra-tutorial-app/
+
+
+h2. Hydra and Rails MVC (Model, View, Controller)
+
+In an MVC framework, the Model defines the attributes and behaviors of your various objects, allowing you to persist those objects and retrieve them.  By default, Rails Models uses ActiveRecord to persist & retrieve objects using SQL databases.  With Hydra, we use ActiveFedora to connect with Fedora and Solr instead of a SQL database.  
+
+Controllers handle requests from clients (ie. HTTP requests from a web browser), loading the necessary information and rendering the appropriate responses (ie. HTML pages returned to the browser).  They use your Models to load the information and they use your Views to render the response.  In this way, Controllers are like connectors or coordinators -- they coordinate the flow of activity in your application when it receives requests.
+
+h2. The new Content Type: JournalArticle
+
+In this tutorial, we are creating a new JournalArticle content type.  This will allow us to create Journal Articles in a Fedora Repository, collect custom metadata for them, index them in solr, and display that custom metadata in the user interface.
+
+In order to describe our Fedora objects, we can use whatever metadata schemas suit our needs.  Some metadata schemas currently being used in Hydra Heads include MODS, Dublin Core, EAD, PBcore, EAC-CPF and VRE.  This list continues to grow as people set up Hydra Heads to deal with their own specialized content.
+
+The JournalArticle content type will use MODS (handily available in hydra-head) to track descriptive metadata about Articles.  Some of the metadata is common to many types of content:
+
+* title
+* author (first name, last name, role)
+* abstract
+
+Other metadata fields are more specifically relevant to journal articles, but they still fit into the MODS schema:
+
+* journal title
+* publication date
+* journal volume
+* journal issue
+* start page
+* end page
+
+In addition to the MODS metadata, JournalArticle objects will use Hydra Rights Metadata to track information about licenses, rights, and which people/groups should be able to discover, view, and/or edit each Journal Article.
+
+h2. Define the ActiveFedora Model for JournalArticles
+
+The first thing to do when adding a new content type is to create the ActiveFedora Model.  This model is a Ruby class that uses ActiveFedora to tell the application the structure of your content and its metadata.
+
+The model we create can be used in any application with ActiveFedora and OM (Opinionated Metadata), not just in a Hydra Head.  For example, ActiveFedora models can be used in batch scripts, command line utilities, and robots that perform automated actions on your fedora objects based on information and behaviors stored in their ActiveFedora models.
+
+h3. Where to find the full tutorial on defining ActiveFedora Models
+
+This tutorial will only cover the very basics of defining an ActiveFedora Model and defining OM terminologies for its XML datastreams.  For a complete introduction to those topics, see the  "ActiveFedora Console Tour":http://hudson.projecthydra.org/job/active_fedora/Documentation/file.CONSOLE_GETTING_STARTED.html and the tutorials included in the "OM documentation":http://hudson.projecthydra.org/job/om/Documentation/.
+
+h3. Tests to Define Expected Behaviors
+
+These tests describe how our JournalArticle objects will behave once the Model is fully defined.  We will have to do a few things before these tests pass, but it's important to define your goals before you start coding.
+
+<pre>
+# spec/modules/journal_article_spec.rb
+require 'spec_helper'
+
+describe JournalArticle do
+  
+  before(:each) do
+    # This gives you a test article object that can be used in any of the tests
+    @article = JournalArticle.new
+  end
+  
+  it "should have the specified datastreams" do
+    # Check for descMetadata datastream with MODS in it
+    @article.datastreams.keys.should include("descMetadata")
+    @article.descMetadata.should be_kind_of JournalArticleModsDatastream
+    # Check for rightsMetadata datastream
+    @article.datastreams.keys.should include("rightsMetadata")
+    @article.rightsMetadata.should be_kind_of Hydra::RightsMetadata
+  end
+  
+  it "should have the attributes of a journal article and support update_attributes" do
+    attributes_hash = {
+      "title" => "All the Awesome you can Handle",
+      "abstract" => "Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.",
+      "journal_title" => "The Journal of Cool",
+      "publication_date" => "1967-11-01",
+      "journal_volume" => "3",
+      "journal_issue" => "2",
+      "start_page" => "25",
+      "end_page" => "30",
+    }
+    
+    @article.update_attributes( attributes_hash )
+    
+    # These attributes have been marked "unique" in the call to delegate, which causes the results to be singular
+    @article.title.should == attributes_hash["title"]
+    @article.abstract.should == attributes_hash["abstract"]
+    
+    # These attributes have not been marked "unique" in the call to the delegate, which causes the results to be arrays
+    @article.journal_title.should == [attributes_hash["journal_title"]]
+    @article.publication_date.should == [attributes_hash["publication_date"]]
+    @article.journal_volume.should == [attributes_hash["journal_volume"]]
+    @article.journal_issue.should == [attributes_hash["journal_issue"]]
+    @article.start_page.should == [attributes_hash["start_page"]]
+    @article.end_page.should == [attributes_hash["end_page"]]
+  end
+  
+end
+
+</pre>
+
+h4. Run the tests
+
+The test code should execute but the tests should fail because we haven't written the code yet.
+
+On the command line, run <pre>rake spec</pre>
+
+You should get an error complaining that
+<pre>spec/models/journal_article_spec.rb:3: uninitialized constant JournalArticle (NameError) </pre>
+
+This is because we haven't defined the Model yet. Now let's define the JournalArticle Model, but first we have to define the datastream that will contain its MODS XML descriptive metadata.
+
+If you get an error complaining that <pre>journal_article_spec.rb:2:in `require': no such file to load -- .../spec/spec_helper (LoadError)</pre> that means you need to run.
+
+<pre>
+rails g rspec:install
+</pre>
+
+h3. Defining the Datastreams
+
+A Fedora object is made up of any number of _datastreams_.  Datastreams can have content of any type and each datastream is identified by a _datastream id_ or _dsid_.  The ActiveFedora model tells us which datastreams to expect or create in an object and tells us what kind of content is expected inside each datastream.
+
+For our JournalArticle model, we're particularly interested datastreams with XML content because a JournalArticle object is basically a container for XML metadata.  The actual content of the Article (PDF,text,whatever.) will be stored in a separate Fedora object, a _primitive_, with the RDF isPartOf relationship connecting the JournalArticle (primarily metadata) to its content (any number of primitives with files in them).  For more information about datastreams, primitives, and where the actual content of an object lives, see the Reference links at the end of this tutorial.
+
+h4. descMetadata -- the Descriptive Metadata Datastream
+
+Our MODS xml will go into a datastream with the datastream id of _descMetadata_.  Technically, we could give it any name we want but the Hydra community has come up with some conventions to make things simpler.  One of these conventions is to always put descriptive metadata in a datastream called descMetadata.
+
+As we said above, we want to create MODS metadata that keeps track of title, author (first name/last name/role), publication date, abstract, journal title, journal volume, journal issue, start page and end page.  In order to do this we will use ActiveFedora to define a special type of Ruby object that uses OM to read and modify XML.
+
+Example of the MODS XML we will be creating:
+
+<pre>
+<mods xmlns="http://www.loc.gov/mods/v3" version="3.0"  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.loc.gov/mods/v3
+     http://www.loc.gov/standards/mods/v3/mods-3-0.xsd">
+   <titleInfo>
+       <title>ARTICLE TITLE</title>                                   <!-- title -->
+   </titleInfo>
+   <name type="personal">
+       <namePart type="family">FAMILY NAME</namePart>                 <!-- author last name -->
+       <namePart type="given">GIVEN NAMES</namePart>                  <!-- author first name -->
+       <role> 
+           <roleTerm authority="marcrelator" type="text">Creator</roleTerm> <!-- author role -->
+       </role>
+   </name>
+   <abstract>ABSTRACT</abstract>                                    <!-- abstract -->
+   <relatedItem type="host">
+       <titleInfo>
+           <title>TITLE OF HOST JOURNAL</title>                     <!-- journal title -->
+       </titleInfo>
+       <part>
+           <detail type="volume">
+               <number>2</number>                                   <!-- journal volume -->
+           </detail>
+           <detail type="level">
+               <number>2</number>                                   <!-- journal issue -->
+           </detail>
+           <extent unit="pages">
+               <start>195</start>                                   <!-- start page -->
+               <end>230</end>                                       <!-- end page -->
+           </extent>
+           <date>FEB. 2007</date>                                   <!-- publication date -->
+       </part>
+    </relatedItem>
+</mods>
+</pre>
+
+The constraints of a metadata schema sometimes force us to put information into structures that don't map directly to the vocabulary that we use when talking about that information.  The "title" has ended up in a spot that you might call the "mods titleInfo title" and the "start page" has ended up in a spot that you might call the <pre>"mods host-relatedItem part pages-extent start"</pre> or <pre>"//mods/relatedItem[@type=host]/part/extent[@unit='pages']/start"</pre> ... quite the mouthful, isn't it?  This is where OM comes in.  OM lets us define a Terminology that will allow us to access values in the xml based on our natural vocabulary (title, start page, etc.) while also allowing us to access those same values using the more cumbersome XML-speak when necessary.
+
+h5. Unit tests for the expected behaviors of a JournalArticleModsDatastream 
+
+This test is a bit more fine-grained than you really need, but it lets you see how you can access the information in an XML Datastream with OM.
+
+<pre>
+# spec/datastreams/journal_article_mods_datastream_spec.rb
+require 'spec_helper'
+
+describe JournalArticleModsDatastream do
+  before(:each) do
+    @mods = fixture("article_mods_sample.xml")
+    @ds = JournalArticleModsDatastream.from_xml(@mods)
+  end
+  it "should expose bibliographic info for journal articles with explicit terms and simple proxies" do
+    @ds.mods.title_info.main_title.should == ["SAMPLE ARTICLE TITLE"]
+    @ds.title.should == ["SAMPLE ARTICLE TITLE"]
+    @ds.abstract.should == ["THIS IS AN ABSTRACT"]
+    @ds.journal.title_info.main_title.should == ["SAMPLE HOST JOURNAL TITLE"]   
+    @ds.journal_title.should == ["SAMPLE HOST JOURNAL TITLE"]   
+    @ds.journal.issue.date.should == ["FEB. 2007"]
+    @ds.publication_date.should == ["FEB. 2007"]
+    @ds.journal.issue.volume.number.should == ["2"]
+    @ds.journal_volume.should == ["2"]
+    @ds.journal.issue.level.number.should == ["18"]
+    @ds.journal_issue.should == ["18"]
+    @ds.journal.issue.pages.start.should == ["195"]
+    @ds.start_page.should == ["195"]
+    @ds.journal.issue.pages.end.should == ["230"]
+    @ds.end_page.should == ["230"]
+  end
+
+  
+  it "should expose nested/hierarchical metadata" do
+    @ds.author.first_name.should == ["George","Abraham"]
+    @ds.author.last_name.should == ["Washington", "Lincoln"]
+    @ds.author.role.text.should == ["Creator", "Contributor"]
+    @ds.author(0).first_name.should == ["George"]
+    @ds.author(0).last_name.should == ["Washington"]
+    @ds.author(0).role.text.should == ["Creator"]
+  end
+end
+</pre>
+
+
+You need to add this simple method to your spec helper so that the tests will be able to load xml files from the spec/fixtures directory.
+
+<pre>
+# spec/spec_helper.rb
+...
+Spec::Runner.configure do |config|
+
+  ...
+
+  def fixture(file)
+    File.new(File.join(File.dirname(__FILE__), 'fixtures', file))
+  end
+end
+</pre>
+
+Now download the sample MODS xml from <code>https://raw.github.com/projecthydra/hydra-tutorial-application/master/spec/fixtures/article_mods_sample.xml</code> and save it as <code>spec/fixtures/article_mods_sample.xml</code>
+
+Now run the test to see it fail before we write the code to make it pass.  We know that the journal_article_spec.rb tests are still failing, so instead of using rake spec to run all the tests, we will just run this one spec file from the command line:
+
+<pre>rspec spec/datastreams/journal_article_mods_datastream_spec.rb</pre>
+
+You should see an error that includes a message like this: 
+
+<pre>hydra-tutorial-app/spec/datastreams/journal_article_mods_datastream_spec.rb:3: uninitialized constant JournalArticleModsDatastream (NameError)</pre>
+
+Now we will define the JournalArticleModsDatastream class so the test will pass.
+
+
+
+h5. Coding the descMetadata Datastream model
+
+Here's how we define the datastream class for the descMetadata.  Notice that we use set_terminology which defines its OM Terminology.  
+
+<b><i>Create a new file in app/models/datastreams called journal_article_mods_datastream.rb</i></b> and put this into it (NOTE: you could also save this file as lib/journal_article_mods_datastream.rb and get the same results):
+
+<pre>
+# app/models/datastreams/journal_article_mods_datastream.rb
+
+# a Fedora Datastream object containing Mods XML for the descMetadata 
+# datastream in the Journal Article hydra content type, defined using 
+# ActiveFedora and OM.
+
+require 'hydra-mods'
+
+class JournalArticleModsDatastream < ActiveFedora::NokogiriDatastream
+
+  # OM (Opinionated Metadata) terminology mapping for the mods xml
+  set_terminology do |t|
+    t.root(:path=>"mods", :xmlns=>"http://www.loc.gov/mods/v3", :schema=>"http://www.loc.gov/standards/mods/v3/mods-3-2.xsd")
+    t.title_info(:path=>"titleInfo") {
+      t.main_title(:index_as=>[:facetable],:path=>"title", :label=>"title")
+    }
+    t.author(:path=>"name", :attributes=>{:type=>"personal"}) {
+      t.first_name(:path=>"namePart", :attributes=>{:type=>"given"})
+      t.last_name(:path=>"namePart", :attributes=>{:type=>"family"})
+      t.role {
+        t.text(:path=>"roleTerm",:attributes=>{:type=>"text"})
+      }
+    }
+    t.abstract 
+    t.journal(:path=>'relatedItem', :attributes=>{:type=>"host"}) {
+      t.title_info(:ref=>[:title_info])
+      t.issue(:path=>"part") {
+        t.volume(:path=>"detail", :attributes=>{:type=>"volume"}) {
+          t.number
+        }
+        t.level(:path=>"detail", :attributes=>{:type=>"level"}) {
+          t.number
+        }
+        t.pages(:path=>"extent", :attributes=>{:unit=>"pages"}) {
+          t.start
+          t.end
+        }
+        t.date
+      }
+    }
+      
+    # these proxy declarations allow you to use more familiar term/field names that hide the details of the XML structure
+    t.title(:proxy=>[:mods, :title_info, :main_title])
+    t.journal_title(:proxy=>[:journal, :title_info, :main_title])
+    t.journal_volume(:proxy=>[:journal, :issue, :volume, :number])
+    t.journal_issue(:proxy=>[:journal, :issue, :level, :number])
+    t.start_page(:proxy=>[:journal, :issue, :pages, :start])
+    t.end_page(:proxy=>[:journal, :issue, :pages, :end])
+    t.publication_date(:proxy=>[:journal, :issue, :date])
+
+  end # set_terminology
+
+  # This defines what the default xml should look like when you create empty MODS datastreams.
+  # We are reusing the ModsArticle xml_template that Hydra provides, but you can make this method return any xml you desire.
+  # See the API docs for more info. http://rubydoc.info/github/projecthydra/om/OM/XML/Container/ClassMethods#xml_template-instance_method
+  def self.xml_template
+    return Hydra::ModsArticle.xml_template
+  end
+end # class
+</pre>
+
+Save that file and run the tests again.  They should pass - if not - you need to add a cmd in the config/application.rb to ensure that your new app/model/datastreams/journal_article_mods_datastream.rb is available.
+<pre>
+class Application < Rails::Application
+   ...
+   config.autoload_paths += Dir[Rails.root.join('app', 'models', '{**}')]
+   ...
+end 
+</pre>
+Good to go. You might get some extra information output onto the console while the tests run.
+
+<pre>
+rspec spec/datastreams/journal_article_mods_datastream_spec.rb
+..
+
+Finished in 7.26 seconds
+2 examples, 0 failures
+</pre>
+
+The key here is "2 examples, 0 failures".
+
+Try deleting lines from the datastream definition or changing values in the fixture xml then re-run the tests to see what it looks like when the tests fail.
+
+
+h4. rightsMetadata -- The Hydra Rights Metadata Datastream
+
+The hydra-head plugin provides a class definition for the rightsMetadata datastream, so you won't have to define the OM Terminology yourself.  The definition is in the hydra-head plugin code in "lib/hydra/rights_metadata.rb":https://github.com/projecthydra/hydra-head/blob/master/lib/hydra/rights_metadata.rb.
+
+Here's an example of what rightsMetadata XML looks like:
+
+<pre>
+  <rightsMetadata xmlns="http://hydra-collab.stanford.edu/schemas/rightsMetadata/v1">
+      <copyright>
+        <human>(c)2009 The Hydra Project</human>
+        <human type="someSpecialisedType">Blah Blah</human>
+        <human type="aDifferentType">More blah</human>
+    		<machine><a rel="license" href="http://creativecommons.org/licenses/publicdomain/"><img alt="Creative Commons License" style="border-width:0" src="http://i.creativecommons.org/l/publicdomain/88x31.png" /></a><br />This work is in the <a rel="license" href="http://creativecommons.org/licenses/publicdomain/">Public Domain</a>.</machine>
+  	</copyright>
+  	<access type="discover">
+  		<human></human>
+  		<machine>
+  			<policy>hydra-policy:4502</policy>
+        <group>public</group>
+      </machine>
+  	</access>
+  	<access type="read">
+  		<human></human>
+  		<machine>
+        <group>public</group>
+      </machine>
+  	</access>
+  	<access type="edit">
+  		<human></human>
+  		<machine>
+  		  <person>researcher1</person>
+        <group>archivist</group>
+  		</machine>        
+  	</access>
+    <access type="etc">
+            <!-- etc -->
+    </access>
+  	<use>
+  		<human>You are free to re-distribute this object, but you cannot change it or sell it. </human>
+  		<machine><a rel="license" href="http://creativecommons.org/licenses/by-nc-nd/3.0/us/"><img alt="Creative Commons License" style="border-width:0" src="http://i.creativecommons.org/l/by-nc-nd/3.0/us/88x31.png" /></a><br />This <span xmlns:dc="http://purl.org/dc/elements/1.1/" href="http://purl.org/dc/dcmitype/Sound" rel="dc:type">work</span> is licensed under a <a rel="license" href="http://creativecommons.org/licenses/by-nc-nd/3.0/us/">Creative Commons Attribution-Noncommercial-No Derivative Works 3.0 United States License</a>.</machine>
+  	</use>
+
+  </rightsMetadata>
+</pre>
+
+
+The Hydra::RightsMetadata datastream definition is provided by hydra-head, so we don't need to implement it or write tests for it.
+
+h4. RELS-EXT & DC Datastreams (Fedora defaults)
+
+There are two special datastreams that Fedora creates for you -- the DC datastream and the RELS-EXT datastream.  We don't really use the DC datastream.  It contains simple Dublin Core metadata that mainly exists for Fedora's internal use.  The RELS-EXT datastream contains RDF representing the relationships between the objects in a Fedora repository.  ActiveFedora and Hydra both use these RDF relationships in a number of ways.  For more information about how to work with RDF relationships in ActiveFedora, see the ActiveFedora documentation links at the end of this tutorial.
+
+h3. Defining the Model and adding the Datastreams to it
+
+Now we're ready to assemble the JournalArticle model and make its tests pass.  First, rerun the tests to see them pass:
+
+<pre>rake spec</pre>
+
+<b><i>Create a file in app/models called journal_article.rb</i></b> and put these lines into it:
+
+<pre>
+# app/models/journal_article.rb
+# a Fedora object for the Journal Article hydra content type
+class JournalArticle < ActiveFedora::Base
+  include Hydra::ModelMethods
+  
+  has_metadata :name => "descMetadata", :type=> JournalArticleModsDatastream
+  has_metadata :name => "rightsMetadata", :type => Hydra::RightsMetadata
+end
+</pre>
+
+Rerun the tests in journal_article_spec.rb and you will see actual failures (probably in red) instead of the error message about JournalArticle being undefined.
+
+<pre>rspec ./spec/models/journal_article_spec.rb</pre>
+
+<pre>
+.F
+
+Failures:
+
+  1) JournalArticle should have the attributes of a journal article and support update_attributes
+     Failure/Error: @article.update_attributes( attributes_hash )
+     ActiveFedora::UnknownAttributeError:
+       unknown attribute: end_page
+     # ./spec/models/journal_article_spec.rb:31
+
+Finished in 7.51 seconds
+2 examples, 1 failure
+
+Failed examples:
+
+rspec ./spec/models/journal_article_spec.rb:19 # JournalArticle should have the attributes of a journal article and support update_attributes
+</pre>
+
+"2 examples, 1 failure" means that the first test is now passing.  You have defined the datastreams correctly using has_metadata.  Now we need to make the JournalArticle model delegate the attributes we want to the descMetadata datastream.  To do that, add these lines into the JournalArticle class defnition:
+
+<pre>
+  # The delegate method allows you to set up attributes on the model that are stored in datastreams
+  # When you set :unique=>"true", searches will return a single value instead of an array.
+  delegate :title, :to=>"descMetadata", :unique=>"true"
+  delegate :abstract, :to=>"descMetadata", :unique=>"true"
+  
+  delegate :start_page, :to=>"descMetadata"
+  delegate :end_page, :to=>"descMetadata"
+  delegate :publication_date, :to=>"descMetadata"
+  delegate :journal_title, :to=>"descMetadata"
+  delegate :journal_volume, :to=>"descMetadata"
+  delegate :journal_issue, :to=>"descMetadata"  
+</pre>
+
+
+h3. Test Your Work
+
+Now rerun the tests.  They should all pass.
+
+<pre>
+rspec ./spec/models/journal_article_spec.rb
+
+..
+
+Finished in 8.09 seconds
+2 examples, 0 failures
+</pre>
+
+<pre>rake spec
+....*
+
+Pending:
+  User add some examples to (or delete) /Users/matt/Develop/projects/hydra-tutorial-app/spec/models/user_spec.rb
+    # Not Yet Implemented
+    # ./spec/models/user_spec.rb:4
+
+Finished in 8.12 seconds
+5 examples, 0 failures, 1 pending
+</pre>
+
+The test that's marked "pending" was generated when you ran the blacklight generator.  You can either add some assertions to it or delete it in order to make your test suite "green" (everything passing, nothing pending). 
+
+
+h2. Defining Journal Articles Controller and Views
+
+Now that you've defined the Model, you need to define the Controller & Views for Creating, Retrieving, Updating and Deleting (CRUD) Journal Articles.
+
+
+<pre> 
+# spec/controllers/journal_articles_controller_spec.rb
+describe JournalArticlesController do
+
+  describe "creating" do
+    it "should render the create page" do
+       get :new
+       assigns[:journal_article].should be_kind_of JournalArticle
+       renders.should == "new"
+    end
+  end
+end
+</pre>
+
+... no controller ...
+
+h3. URL Routing for JournalArticles
+
+<pre> 
+# config/routes.rb
+...
+   resources :journal_articles
+...
+</pre> 
+
+h3. Defining the JournalArticlesController
+
+<pre> 
+# app/controllers/journal_articles_controller.rb
+class JournalArticlesController < ApplicationController
+  def new
+    @journal_article = JournalArticle.new
+  end
+end
+</pre>
+
+h3. The "Create" View
+
+h4. Cucumber Test for "Create" View
+
+You will need to have run:
+
+<pre>
+rails g cucumber:install
+</pre>
+
+<pre>
+Given I am logged in as archivist1@example.com
+And I am on the home page
+When I click "Add a Journal Article"
+Then I should see ...
+When I fill in ...
+And I click "Create this Journal Article"
+Then I should see "Journal Article 'My title' created."
+</pre>
+
+h4. "Add a Journal Article" button
+
+First, we need to add a link to the Hydra Head that lets you create Journal Articles.  To do this, you need to override the _add_asset_links view partial.  Here's the cucumber test for what you want:
+
+hydra-head puts a list of "add asset" links into the user_util_links section of the page.  This list is defined in app/views/_add_asset_links.html.erb. By default, this list includes links for adding Images, MODS Assets and Generic Content.  We want it to have just one link -- create an Article.  To override the list, create a file at app/views/_add_assets_links.html.erb and put this into it:
+
+<pre>
+<div id="select-item-box">
+  <a class="add-new-asset" href="#">Add a New Asset</a>
+  <ul id="select-item-list">
+    <li>
+      <%= link_to_create_asset 'Add an Article', 'journal_article' %>
+    </li>
+  </ul>
+</div>
+</pre>
+
+h4. Form for Creating Journal Articles
+
+h4. Controller "Create" Method
+
+<pre>
+# spec/controllers/journal_articles_controller_spec.rb
+describe JournalArticlesController do
+
+  describe "creating" do
+    it "should render the create page" do
+       ...
+    end
+    it "should support create requests" do
+       post :create, :journal_article=>{"title"=>"My title"}
+       ja = assigns[:journal_article]
+       ja.title.should == "My title"
+    end
+  end
+end
+</pre>
+
+Restart the app, load up http://localhost:3000/journal_articles/new and try it out.
+
+h3. The "Edit" View
+
+h4. The Fixture Object for tests
+
+h4. Cucumber Test for "Edit"
+
+<pre>
+  Given I am on the edit page for "hydra:fixture_journal_article"
+  And I fill in "Title" with "The History of Hopscotch"
+  When I click "Save"
+  Then I should see "The History of Hopscotch has been updated."
+</pre>
+
+h4. Controller Edit & Update Methods
+
+<pre>
+# spec/controllers/journal_articles_controller_spec.rb
+describe JournalArticlesController do
+
+  describe "creating" do
+    ...
+  end
+
+  describe "editing" do
+    it "should support edit requests" do
+       get :edit, :id=>"hydra:fixture_journal_article"
+       assigns[:journal_article].should be_kind_of JournalArticle
+       assigns[:journal_article].pid.should == "hydra:fixture_journal_article"
+    end
+    it "should support updating objects" do
+       put :update, :journal_article=>{"title"=>"My Newest Title"}
+       ja = assigns[:journal_article]
+       ja.title.should == "My Newest Title"
+    end
+  end
+end
+</pre>
+
+<pre>
+# app/controllers/journal_articles_controller.rb
+class JournalArticlesController < ApplicationController
+  def new
+    ...
+  end
+
+  def edit
+    @journal_article = JournalArticle.find(params[:id])
+  end
+
+  def update
+    @journal_article = JournalArticle.find(params[:id])
+    @journal_article.update_attributes(params[:journal_article])
+    redirect_to :edit
+  end
+end
+</pre>
+
+h4. Form for Editing Journal Articles
+
+<pre>
+# app/views/journal_articles/_edit.html.erb
+<%= form_for @journal_article do |f| %>
+  <%= f.label :title %>
+  <%= f.text_field :title %>
+  <%= f.submit "Save" %>
+<% end %>
+</pre>
+
+h3. The Show Page
+
+h4. Controller "Show" Method
+
+The show method definition is almost identical to the edit method.  With time, the two methods will accumulate different logic within your application, but for now they both have one basic role: load the requested object and pass it into the requested view template.
+
+<pre>
+# app/controllers/journal_articles_controller.rb
+class JournalArticlesController < ApplicationController
+  def new
+    ...
+  end
+
+  def show
+    @journal_article = JournalArticle.find(params[:id])
+  end
+
+  def edit
+    @journal_article = JournalArticle.find(params[:id])
+  end
+
+  def update
+    ...
+  end
+end
+</pre>
+
+h4. View Template for "Show"
+
+
+<pre>
+# app/views/journal_articles/edit.html.erb
+<h1>&lt;%= @journal_article.title %>&lt;/h1>
+<dl>
+  <dt>Title&lt;/dt>
+  <dd>
+    <%= @journal_article.title %>
+  </dd>
+  <dt>Journal&lt;/dt>
+  <dd>
+    <%= @journal_article.journal_title %>
+  </dd>
+</dl>
+</pre>
+
+h2. Journal Articles in Blacklight Search Results
+
+h3. Look at the Solr Document for a Journal Article
+
+title_t, journal_title_t
+
+active_fedora_model_s and Blacklight.config[:display_type]
+
+h3. The _index partial
+
+<pre>
+# app/views/journal_articles/_index.html.erb
+<dl>
+  <dt>Title&lt;/dt>
+  <dd>
+    <%= document["title_t"] %>
+  </dd>
+  <dt>Journal&lt;/dt>
+  <dd>
+    <%= document["journal_title_t"] %>
+  </dd>
+</dl>
+</pre>
+
+h2. Hydra Modeling Conventions
+
+See "Hydra Modeling Conventions":https://github.com/projecthydra/hydra-head/wiki/Models---Hydra-Conventions
+
+h2. For Further Information
+
+See "Reference":https://github.com/projecthydra/hydra-head/wiki/Reference for more links.