hydra 10.0.0 → 10.0.1
Sign up to get free protection for your applications and to get access to all the features.
- checksums.yaml +4 -4
- data/doc/Dive-into-Hydra.md +60 -57
- data/doc/For-Developers.md +0 -1
- data/doc/Hackfest-ideas.md +18 -0
- data/doc/Home.md +3 -1
- data/doc/Hydra-Recipes.md +5 -1
- data/doc/LDP-Containers-for-the-perplexed.md +119 -0
- data/doc/Lesson---Adding-attached-files.md +83 -0
- data/doc/Lesson---Build-a-Codex-model-with-XML.md +272 -0
- data/doc/Lesson---Build-a-book-model-with-RDF.md +250 -0
- data/doc/Lesson---Define-Relationships-Between-Objects.md +125 -0
- data/doc/{Lesson:-Generate-Rails-Scaffolding-for-Creating-and-Editing-Books.md → Lesson---Generate-Rails-Scaffolding-for-Creating-and-Editing-Books.md} +57 -50
- data/doc/Lesson---Start-FCRepo-and-Solr.md +76 -0
- data/doc/{Lesson:-add-the-Hydra-dependencies.md → Lesson---add-the-Hydra-dependencies.md} +3 -3
- data/doc/{Lesson:-generate-a-rails-application.md → Lesson---generate-a-rails-application.md} +78 -91
- data/doc/Lesson---make-blacklight-return-search-results.md +71 -0
- data/doc/Lesson---start-the-application-&-search-for-results.md +55 -0
- data/doc/Recipe:-Add-full-text-indexing-to-your-app.md +27 -0
- data/doc/Using-rdf:resource-within-your-models.md +43 -0
- data/hydra.gemspec +1 -1
- data/lib/hydra/version.rb +1 -1
- data/script/grant_revoke_gem_authority.rb +1 -1
- metadata +18 -17
- data/doc/Lesson:-Define-Relationships-Between-Objects.md +0 -131
- data/doc/Lesson:-Reading-Hydra-rightsMetadata-XML.md +0 -87
- data/doc/Lesson:-Use-Hydra-Access-Controls-to-Control-Access-to-Blacklight-show-Pages.md +0 -37
- data/doc/Lesson:-Using-Hydra-Access-Controls-and-CanCan-to-conditionally-render-part-of-a-page.md +0 -29
- data/doc/Lesson:-adding-content-datastreams.md +0 -57
- data/doc/Lesson:-build-a-book-model.md +0 -265
- data/doc/Lesson:-install-hydra-jetty.md +0 -148
- data/doc/Lesson:-make-blacklight-return-search-results.md +0 -69
- data/doc/Lesson:-set-up-your-Rails-Application-to-use-rspec.md +0 -41
- data/doc/Lesson:-start-the-application-&-search-for-results.md +0 -29
@@ -0,0 +1,76 @@
|
|
1
|
+
# Goals
|
2
|
+
* Install FCRepo and Solr
|
3
|
+
* Learn to start and stop FCRepo and Solr
|
4
|
+
|
5
|
+
# Explanation
|
6
|
+
In order to use blacklight and hydra-head you need an installation of Solr. In addition, hydra-head requires a copy of Fedora. Fedora and Solr are both Java web applications.
|
7
|
+
|
8
|
+
For developer environments, we have created a `solr_wrapper` and `fcrepo_wrapper` -- commands to assist you in starting Solr and Fedora. Whenever you need Fedora and Solr running in your development environment, just start or stop that copy of `solr_wrapper` or `fcrepo_wrapper`
|
9
|
+
|
10
|
+
>
|
11
|
+
**TIP** *DO NOT* use `solr_wrapper` or `fcrepo_wrapper` for production installations.
|
12
|
+
>
|
13
|
+
|
14
|
+
>
|
15
|
+
**WORKSHOPS & HYDRA CAMP** if you're using a VM provided for the workshop, there's probably a copy of solr and fedora already on your VM, follow the instructions your facilitator provides to copy the files instead of having to download them again. Probably something like
|
16
|
+
```
|
17
|
+
cp ~/downloads/solr-5.4.1.zip /tmp
|
18
|
+
cp ~/downloads/fcrepo-webapp-4.5.0-jetty-console.jar /tmp
|
19
|
+
```
|
20
|
+
>
|
21
|
+
|
22
|
+
### Step 1: Start Solr
|
23
|
+
Open a new terminal window and type:
|
24
|
+
```
|
25
|
+
cd <hydra-demo app path>
|
26
|
+
solr_wrapper -d solr/config/ --collection_name hydra-development
|
27
|
+
```
|
28
|
+
|
29
|
+
You can check to see if Solr is started by going to [[http://localhost:8983/]]
|
30
|
+
|
31
|
+
>
|
32
|
+
**TIP** Running solr_wrapper in a tmux panel can silently fail. Use a separate new terminal window, or install https://github.com/ChrisJohnsen/tmux-MacOSX-pasteboard for Mac OSX.
|
33
|
+
>
|
34
|
+
|
35
|
+
|
36
|
+
|
37
|
+
### Step 2: Start FCRepo
|
38
|
+
Open a new terminal window and type:
|
39
|
+
|
40
|
+
```
|
41
|
+
fcrepo_wrapper -p 8984
|
42
|
+
```
|
43
|
+
|
44
|
+
You can check to see if FCRepo is started by going to [[http://localhost:8984/]]
|
45
|
+
|
46
|
+
### Step 3: Make git ignore the `fcrepo4-data` directory
|
47
|
+
|
48
|
+
We want git to ignore the `fcrepo4-data` directory for the same reasons that we don't check our development databases into git -- because it's big and bulky and you don't actually need other developers to have exact copies of your data as long as they have all the other code.
|
49
|
+
|
50
|
+
We do that by editing `.gitignore` and adding the something like this:
|
51
|
+
|
52
|
+
```text
|
53
|
+
# Ignore Fedora data files
|
54
|
+
/fcrepo4-data
|
55
|
+
|
56
|
+
```
|
57
|
+
|
58
|
+
Now commit this change
|
59
|
+
|
60
|
+
```text
|
61
|
+
git add .gitignore
|
62
|
+
git commit -m "Adds /fcrepo4-data to .gitignore"
|
63
|
+
```
|
64
|
+
|
65
|
+
#### FYI: Stopping FCRepo and Solr
|
66
|
+
In order to stop either service, open the window they are running in and type `<Control>-C`. Wait a few moments for the process to terminate.
|
67
|
+
|
68
|
+
|
69
|
+
>
|
70
|
+
**Tip:** Sometimes people are confused about whether they need to restart Fedora or Solr when they restart their Rails application. In most cases it is fine to leave Fedora and Solr running when you start, stop, and restart the Rails application. The only exception is when you make changes to Solr's configuration or Fedora's configuration -- these would be changes to files inside of your copy of the solr configuration (i.e. solr/config), not changes to files in your Rails application's Ruby code. In those cases, where you have made changes to Solr or Fedora's configuration, you need to restart the processes in order for those changes to take effect. The most common change that requires restarting Solr is when you modify the solrconfig.xml or schema.xml in your solr config directory. Normally, changes to your data steams or models do not require restarts to Solr and Fedora because these changes are indexed dynamically by Hydra.
|
71
|
+
>
|
72
|
+
|
73
|
+
|
74
|
+
|
75
|
+
# Next Step
|
76
|
+
Go on to [[Lesson - Start the Application & Search for Results]] or return to the [[Dive into Hydra]] page.
|
@@ -15,10 +15,10 @@ Hydra builds on and extends the features provided by Blacklight, the hydra gener
|
|
15
15
|
Open up `Gemfile` in your editor. We're going to add the following lines after the `source` line:
|
16
16
|
|
17
17
|
```ruby
|
18
|
-
gem 'hydra'
|
18
|
+
gem 'hydra', '9.1.0'
|
19
19
|
```
|
20
20
|
|
21
|
-
This includes the hydra
|
21
|
+
This includes the hydra gem in our application. Bundler will then ensure that the hydra-head, blacklight, active-fedora and other gems required by hydra get included (required) correctly.
|
22
22
|
|
23
23
|
Now save the change and install the dependencies by running bundler:
|
24
24
|
```text
|
@@ -67,4 +67,4 @@ git commit -m "Ran hydra generator"
|
|
67
67
|
```
|
68
68
|
|
69
69
|
# Next Step
|
70
|
-
Go on to [[Lesson
|
70
|
+
Go on to [[Lesson - Start FCRepo and Solr]] or return to the [[Dive into Hydra]] page.
|
data/doc/{Lesson:-generate-a-rails-application.md → Lesson---generate-a-rails-application.md}
RENAMED
@@ -1,91 +1,78 @@
|
|
1
|
-
# Goals
|
2
|
-
* Create your new Ruby on Rails Application
|
3
|
-
* Initialize the local git repository for your project
|
4
|
-
|
5
|
-
# Explanation
|
6
|
-
|
7
|
-
**Note:** This lesson is roughly covers the [Getting Started](http://curriculum.railsbridge.org/curriculum/getting_started) and [Create A New Git Repo](http://curriculum.railsbridge.org/curriculum/create_a_new_git_repo) steps in the RailsBridge Curriculum.
|
8
|
-
|
9
|
-
This lesson assumes you are using a **
|
10
|
-
|
11
|
-
The first step to creating a Hydra Head, or any other type of Rails Application, is to generate the basic skeleton of the application code.
|
12
|
-
|
13
|
-
We'll also initialize our Git repository in this lesson so we can track incremental changes to our code. In order to track the changes you make to your code, to share your changes with others, and to pull other people's changes into your code, you need some form of Version Control. The Hydra community uses Git for version control and to share work on Github.
|
14
|
-
|
15
|
-
# Steps
|
16
|
-
|
17
|
-
### Step 1: Create a new rails application
|
18
|
-
|
19
|
-
Once you have installed a suitable rails gem (
|
20
|
-
|
21
|
-
```text
|
22
|
-
rails new hydra-demo
|
23
|
-
```
|
24
|
-
|
25
|
-
This generates the file structure for an empty rails application. And it runs 'bundler' which loads in all of the external dependencies for rails.
|
26
|
-
|
27
|
-
Enter the directory for the new rails app:
|
28
|
-
|
29
|
-
```text
|
30
|
-
cd hydra-demo
|
31
|
-
```
|
32
|
-
|
33
|
-
When you type `ls` at the command prompt, you should see a file structure like this:
|
34
|
-
|
35
|
-
>
|
36
|
-
```text
|
37
|
-
Gemfile Rakefile config.ru lib script vendor
|
38
|
-
Gemfile.lock app db log test
|
39
|
-
README.rdoc config doc public tmp
|
40
|
-
```
|
41
|
-
>
|
42
|
-
|
43
|
-
|
44
|
-
|
45
|
-
|
46
|
-
|
47
|
-
|
48
|
-
|
49
|
-
|
50
|
-
|
51
|
-
|
52
|
-
|
53
|
-
|
54
|
-
|
55
|
-
|
56
|
-
|
57
|
-
|
58
|
-
|
59
|
-
|
60
|
-
|
61
|
-
|
62
|
-
|
63
|
-
|
64
|
-
|
65
|
-
|
66
|
-
|
67
|
-
|
68
|
-
|
69
|
-
|
70
|
-
|
71
|
-
|
72
|
-
|
73
|
-
|
74
|
-
|
75
|
-
|
76
|
-
|
77
|
-
|
78
|
-
|
79
|
-
Initialized empty Git repository in /Users/camper/hydra-demo/.git/
|
80
|
-
```
|
81
|
-
>
|
82
|
-
|
83
|
-
Next, we'll add all the files rails created into the repository. This way we can jump back to this state later if the need arises.
|
84
|
-
|
85
|
-
```text
|
86
|
-
git add .
|
87
|
-
git commit -m "Initial rails application"
|
88
|
-
```
|
89
|
-
|
90
|
-
# Next Step
|
91
|
-
Go on to [[Lesson: Add the Hydra Dependencies]] or return to the [[Dive into Hydra]] page.
|
1
|
+
# Goals
|
2
|
+
* Create your new Ruby on Rails Application
|
3
|
+
* Initialize the local git repository for your project
|
4
|
+
|
5
|
+
# Explanation
|
6
|
+
|
7
|
+
**Note:** This lesson is roughly covers the [Getting Started](http://curriculum.railsbridge.org/curriculum/getting_started) and [Create A New Git Repo](http://curriculum.railsbridge.org/curriculum/create_a_new_git_repo) steps in the RailsBridge Curriculum.
|
8
|
+
|
9
|
+
This lesson assumes you are using a **4.2.x version of rails**. To avoid confusion, it's better to have a clean gemset with only one version of rails installed. Most people use either [RVM](http://rvm.io) or [rbenv](https://github.com/sstephenson/rbenv) to handle gemsets and ruby versions.
|
10
|
+
|
11
|
+
The first step to creating a Hydra Head, or any other type of Rails Application, is to generate the basic skeleton of the application code.
|
12
|
+
|
13
|
+
We'll also initialize our Git repository in this lesson so we can track incremental changes to our code. In order to track the changes you make to your code, to share your changes with others, and to pull other people's changes into your code, you need some form of Version Control. The Hydra community uses Git for version control and to share work on Github.
|
14
|
+
|
15
|
+
# Steps
|
16
|
+
|
17
|
+
### Step 1: Create a new rails application
|
18
|
+
|
19
|
+
Once you have installed a suitable rails gem (4.2.x releases work best for this tutorial), begin by using it to generate a new rails application. You can choose any name for your application. In this tutorial we are calling it hydra-demo
|
20
|
+
|
21
|
+
```text
|
22
|
+
rails new hydra-demo
|
23
|
+
```
|
24
|
+
|
25
|
+
This generates the file structure for an empty rails application. And it runs 'bundler' which loads in all of the external dependencies for rails.
|
26
|
+
|
27
|
+
Enter the directory for the new rails app:
|
28
|
+
|
29
|
+
```text
|
30
|
+
cd hydra-demo
|
31
|
+
```
|
32
|
+
|
33
|
+
When you type `ls` at the command prompt, you should see a file structure like this:
|
34
|
+
|
35
|
+
>
|
36
|
+
```text
|
37
|
+
Gemfile Rakefile config.ru lib script vendor
|
38
|
+
Gemfile.lock app db log test
|
39
|
+
README.rdoc config doc public tmp
|
40
|
+
```
|
41
|
+
>
|
42
|
+
|
43
|
+
**Windows Only**: if you're running this tutorial directly on a Windows system, you'll need to use `dir` instead of `ls` anywhere in these instructions where you're asked to list files.
|
44
|
+
|
45
|
+
#### Step 1a: (**Linux only**) Enable javascript runtime
|
46
|
+
|
47
|
+
Find the line in your Gemfile that has ```# gem 'therubyracer', platforms: :ruby``` and uncomment that line. This allows your system to identify the appropriate javascript runtime.
|
48
|
+
|
49
|
+
Now save the Gemfile and run ```bundle install```. This tells bundler to update your dependencies to reflect the change in your Gemfile.
|
50
|
+
|
51
|
+
Alternatively, a Node.js runtime will be resolved without adding `therubyracer`. Joyent maintains simple instructions for [installing Node.js with various Linux package managers](https://github.com/joyent/node/wiki/installing-node.js-via-package-manager).
|
52
|
+
|
53
|
+
|
54
|
+
### Step 2: Initialize your git repository
|
55
|
+
|
56
|
+
Now, let's turn the application directory into a git repository. Type the following:
|
57
|
+
|
58
|
+
```text
|
59
|
+
git init .
|
60
|
+
```
|
61
|
+
|
62
|
+
Then you should see something like this:
|
63
|
+
|
64
|
+
>
|
65
|
+
```text
|
66
|
+
Initialized empty Git repository in /Users/camper/hydra-demo/.git/
|
67
|
+
```
|
68
|
+
>
|
69
|
+
|
70
|
+
Next, we'll add all the files rails created into the repository. This way we can jump back to this state later if the need arises.
|
71
|
+
|
72
|
+
```text
|
73
|
+
git add .
|
74
|
+
git commit -m "Initial rails application"
|
75
|
+
```
|
76
|
+
|
77
|
+
# Next Step
|
78
|
+
Go on to [[Lesson - Add the Hydra Dependencies]] or return to the [[Dive into Hydra]] page.
|
@@ -0,0 +1,71 @@
|
|
1
|
+
# Goals
|
2
|
+
* *(for now)* Turn off access controls for Blacklight-based searches and "show" views
|
3
|
+
* Tell Blacklight which fields to use in searches
|
4
|
+
* Run a search in Blacklight and see results rendered
|
5
|
+
|
6
|
+
# Explanation
|
7
|
+
|
8
|
+
In [[Lesson - Build a book model with RDF]] and/or [[Lesson - Build a codex model with XML]] you defined an object model and stored a new digital object in your repository. We saved the objects and saw that their metadata was indexed in Solr. Now we will make your repository objects appear in your Blacklight searches.
|
9
|
+
|
10
|
+
One of the main features that Hydra adds to Blacklight is the ability to control who has access to which information in search results. That topic gets a little bit complicated. For the purpose of this Tutorial we want to stay focused on showing you how to set up an app, define models and create objects based on those models, so in order to keep things simple we will make this Hydra Head behave like an open access repository where everyone can see everything. Once you've completed this tutorial, you can check out [Access Controls with Hydra](https://github.com/projecthydra/hydra-head/wiki/Access-Controls-with-Hydra) to learn how to assert access controls on objects and enforce those access controls in a Hydra Head.
|
11
|
+
|
12
|
+
Once you've turned off access controls in step #1, we show you how to tell blacklight which fields you want to use for default searches in the remaining steps.
|
13
|
+
|
14
|
+
# Steps
|
15
|
+
|
16
|
+
### Step 1: Comment out and change the lines that enforce access controls in Blacklight's CatalogController
|
17
|
+
|
18
|
+
If you open ```app/controllers/catalog_controller.rb``` and look at the code near lines 8-12 you should see this:
|
19
|
+
```ruby
|
20
|
+
# These before_filters apply the hydra access controls
|
21
|
+
before_filter :enforce_show_permissions, :only=>:show
|
22
|
+
# This applies appropriate access controls to all solr queries
|
23
|
+
Hydra::SearchBuilder.default_processor_chain += [:add_access_controls_to_solr_params]
|
24
|
+
```
|
25
|
+
|
26
|
+
This code tells blacklight to enforce access controls on the search and result view pages. For the time being we will turn this off by commenting out the before_filter and changing ``` += ``` to ``` -= ``` in order to remove ``` :add_access_controls_to_solr_params ``` from the default_processor_chain, the code should look like this:
|
27
|
+
|
28
|
+
```ruby
|
29
|
+
# These before_filters apply the hydra access controls
|
30
|
+
#before_filter :enforce_show_permissions, :only=>:show
|
31
|
+
# This applies appropriate access controls to all solr queries
|
32
|
+
Hydra::SearchBuilder.default_processor_chain -= [:add_access_controls_to_solr_params]
|
33
|
+
```
|
34
|
+
Then, save the file.
|
35
|
+
|
36
|
+
### Step 2: Run a search in the CatalogController
|
37
|
+
|
38
|
+
Visit or reload the page at [[http://localhost:3000/]]. You should see the Blacklight search interface with a search box. If you just hit enter on the blank search box (effectively asking blacklight to return all objects) you should get a response with the object(s) you've created using the rails console. **IN ADDITION** If you search for your title or author by typing part of it into your search box and then hitting enter, you'll see any matching results. This happens because Blacklight configures 'title', 'author', and 'subject' as default search fields out of the box.
|
39
|
+
|
40
|
+
### Step 3: Tell Blacklight which fields to use in Queries
|
41
|
+
|
42
|
+
Sometimes, we want to tell Blacklight explicitly which fields to search in. Let's fix that by setting the default 'qf' solr parameter. Open `app/controllers/catalog_controller.rb` and set the `default_solr_params` section (around line 18) to this:
|
43
|
+
|
44
|
+
```ruby
|
45
|
+
config.default_solr_params = {
|
46
|
+
qf: 'title_tesim author_tesim',
|
47
|
+
qt: 'search',
|
48
|
+
rows: 10
|
49
|
+
}
|
50
|
+
```
|
51
|
+
|
52
|
+
> NOTE: Because we used the same names, 'author' and 'title' for both our book and codex models, blacklight will return results that match either digital object type. We'll talk about filtering object types in one of the bonus lessons.
|
53
|
+
|
54
|
+
### Step 4: Re-run your search
|
55
|
+
|
56
|
+
Save the changes to your `catalog_controller.rb` file, and restart your web server from the terminal (Ctrl-C to stop the server and `rails server` to restart it.) Now, in your browser, search for one of the words in your author or title fields and you should see a list of matching results.
|
57
|
+
|
58
|
+
~~**Tip:** When you make changes like this, you *don't* need to restart the Rails server. This is because in development mode (which is the default environment for the Rails server), the Rails server reloads any files in app/models, app/controllers, app/views, etc. for every request it receives from a browser. This makes the server slower, but it makes life much smoother when you're actively developing and making changes.~~
|
59
|
+
|
60
|
+
### Step 5: Commit your changes
|
61
|
+
|
62
|
+
Now that we've updated our search functionality, it's a great time to commit to git:
|
63
|
+
|
64
|
+
```text
|
65
|
+
git add .
|
66
|
+
git commit -m "Disabled access controls and set default search fields"
|
67
|
+
```
|
68
|
+
|
69
|
+
# Next Step
|
70
|
+
Go on to **BONUS** [[Lesson - Define Relationships Between Objects]] or
|
71
|
+
explore other [Dive into Hydra](Dive into Hydra#bonus) tutorial bonus lessons.
|
@@ -0,0 +1,55 @@
|
|
1
|
+
# Goals
|
2
|
+
* Configure the application
|
3
|
+
* Start and Stop a local "development" copy of the application
|
4
|
+
* Remove the default Welcome page provided by Rails
|
5
|
+
* Run a Search in Blacklight through your browser
|
6
|
+
|
7
|
+
# Steps
|
8
|
+
|
9
|
+
### Step 1: Configure the application
|
10
|
+
|
11
|
+
There are a couple configurations that need to be set, or verified, before starting the application.
|
12
|
+
|
13
|
+
#### config/solr.yml
|
14
|
+
The urls and collection name must be set to match what is running by solr_wrapper.
|
15
|
+
```
|
16
|
+
development:
|
17
|
+
url: http://127.0.0.1:<%= ENV['SOLR_TEST_PORT'] || 8983 %>/solr/hydra-development
|
18
|
+
```
|
19
|
+
|
20
|
+
#### config/fedora.yml
|
21
|
+
The urls to the Fedora server must be properly set for production and what is running by fcrepo_wrapper.
|
22
|
+
```
|
23
|
+
development:
|
24
|
+
url: http://127.0.0.1:<%= ENV['FCREPO_DEVELOPMENT_PORT'] || 8984 %>/rest
|
25
|
+
...
|
26
|
+
```
|
27
|
+
|
28
|
+
### Step 2: Start the Rails server
|
29
|
+
|
30
|
+
Now, let's see our model on the web. You can start 'webrick', a development server that comes with rails by typing:
|
31
|
+
|
32
|
+
```bash
|
33
|
+
rails server -b 0.0.0.0
|
34
|
+
```
|
35
|
+
|
36
|
+
>
|
37
|
+
*NOTE:* -b 0.0.0.0 isn't strictly required, but lets you access your server from your host browser if you're running it in a VM
|
38
|
+
>
|
39
|
+
|
40
|
+
Leave this terminal window open through the rest of the tutorial. It will print info whenever the server does anything. You will return to this window when you want to stop or restart the server.
|
41
|
+
|
42
|
+
### Step 3: Look at the application in your Browser and customize the home page
|
43
|
+
|
44
|
+
Now you can visit your local copy of the application with a web browser when you go to [[http://localhost:3000/]].
|
45
|
+
|
46
|
+
The default home page gives instructions for customizing the home page: essentially, create a ```app/views/catalog/_home_text.html.erb``` with the content you want. After saving that file and reloading in the browser you should see your changes.
|
47
|
+
|
48
|
+
### Step 4: Run a Search
|
49
|
+
|
50
|
+
If you enter a search query you don't see any results because we haven't created any objects yet -- your Solr index is empty.
|
51
|
+
|
52
|
+
In the next lessons we will create a objects in your Fedora repository, then we will show you how to make them appear in your search results.
|
53
|
+
|
54
|
+
# Next Step
|
55
|
+
If you're interested in how RDF object modeling works, go on to [[Lesson - Build a book model with RDF]]; otherwise go on to [[Lesson - Build a codex model with XML]] or return to the [[Dive into Hydra]] page.
|
@@ -0,0 +1,27 @@
|
|
1
|
+
There are number of areas in the Hydra stack that need to be touched to do full-text indexing. Sufia supports full-text indexing using Apache Tika (which is provided in Apache Solr), and here's how it's implemented. (Note: if you're using Sufia, this is already done for you!)
|
2
|
+
|
3
|
+
# Solr
|
4
|
+
|
5
|
+
The [Solr schema](https://github.com/projecthydra/sufia/blob/eb714cb91f4ecd49dec67b0e9996dc3d4e918f1a/solr_conf/conf/schema.xml#L174-L175) contains a field called `all_text_timv`.
|
6
|
+
|
7
|
+
The [Solr config](https://github.com/projecthydra/sufia/blob/7cedb837b2d6388d81ba7d9a815edc0e4b4c1251/solr_conf/conf/solrconfig.xml#L16-L17) pulls in a bunch of extraction libraries and [adds the `all_text_timv` field to the default qf and pf](https://github.com/projecthydra/sufia/blob/7cedb837b2d6388d81ba7d9a815edc0e4b4c1251/solr_conf/conf/solrconfig.xml#L42-L47). The [ExtractingRequestHandler](https://github.com/projecthydra/sufia/blob/7cedb837b2d6388d81ba7d9a815edc0e4b4c1251/solr_conf/conf/solrconfig.xml#L110-L121) must be enabled as well.
|
8
|
+
|
9
|
+
# Extraction libraries
|
10
|
+
|
11
|
+
Sufia uses [a rake task](https://github.com/projecthydra/sufia/blob/eb714cb91f4ecd49dec67b0e9996dc3d4e918f1a/sufia-models/lib/tasks/sufia-models_tasks.rake#L27-L96) to download extraction libraries and store them where Solr looks for them.
|
12
|
+
|
13
|
+
# Blacklight catalog
|
14
|
+
|
15
|
+
The `all_text_timv` field is added to the `all_fields` search qf in the [Catalog controller](https://github.com/projecthydra/sufia/blob/a064489d3cf4d228abf978d7126644e2c653aa5e/lib/generators/sufia/templates/catalog_controller.rb#L125)
|
16
|
+
|
17
|
+
# Modeling
|
18
|
+
|
19
|
+
Sufia's `GenericFile` model mixes in [a module that knows how to talk to Solr's ExtractingRequestHandler](https://github.com/projecthydra/sufia/blob/a064489d3cf4d228abf978d7126644e2c653aa5e/sufia-models/app/models/concerns/sufia/generic_file/full_text_indexing.rb). (The `#extract_content` method is where that happens.)
|
20
|
+
|
21
|
+
# Indexing
|
22
|
+
|
23
|
+
Sufia has [an indexing service](https://github.com/projecthydra/sufia/blob/7644ff5b04d66cfe1c4d7bee75a6840eb09eb664/sufia-models/app/services/sufia/generic_file_indexing_service.rb#L10) that takes the output of Apache Tika and indexes it in Solr. (This is the equivalent of overriding `#to_solr` on an ActiveFedora model.)
|
24
|
+
|
25
|
+
# Workflow
|
26
|
+
|
27
|
+
When a file is uploaded, Sufia spawns [a background job that characterizes the file](https://github.com/projecthydra/sufia/blob/a064489d3cf4d228abf978d7126644e2c653aa5e/sufia-models/app/jobs/characterize_job.rb#L7). The `#characterize` method calls [#append_metadata](https://github.com/projecthydra/sufia/blob/a064489d3cf4d228abf978d7126644e2c653aa5e/sufia-models/app/models/concerns/sufia/generic_file/characterization.rb#L75). That method in turn calls the `#extract_content` method which hits Apache Tika via the Solr API.
|
@@ -0,0 +1,43 @@
|
|
1
|
+
Some data models may call for adding properties to objects that consist of URI references using the `rdf:resource` syntax. For example, you may want to define an object's language by reference to a standard list available online, such as that supplied by Library of Congress. In this example, we will add a language property to the Book example from Dive Into Hydra which consists of a URI reference.
|
2
|
+
|
3
|
+
First, you add the required property to the model:
|
4
|
+
|
5
|
+
```ruby
|
6
|
+
property :language, predicate: ::RDF::DC.language, multiple: false
|
7
|
+
```
|
8
|
+
|
9
|
+
Then you add a getter and setter method:
|
10
|
+
|
11
|
+
```ruby
|
12
|
+
def language_uri=(uri)
|
13
|
+
self.language = ::RDF::URI.new(uri) if uri.present?
|
14
|
+
end
|
15
|
+
|
16
|
+
def language_uri
|
17
|
+
self.language.to_term.value unless language.nil?
|
18
|
+
end
|
19
|
+
```
|
20
|
+
|
21
|
+
In your rails console try assigning a language to an object, for example:
|
22
|
+
|
23
|
+
```
|
24
|
+
b = Book.new
|
25
|
+
b.language_uri = "http://id.loc.gov/vocabulary/languages/abk"
|
26
|
+
b.language_uri
|
27
|
+
=> "http://id.loc.gov/vocabulary/languages/abk"
|
28
|
+
b.language
|
29
|
+
=> #<ActiveTriples::Resource:0x42c2258(default)>
|
30
|
+
b.resource.dump(:rdf)
|
31
|
+
=> "<?xml version='1.0' encoding='utf-8' ?>
|
32
|
+
<rdf:RDF xmlns:ns0='info:fedora/fedora-system:def/model#' xmlns:ns1='http://purl.org/dc/terms/' xmlns:rdf='http://www.w3.org/1999/02/22-rdf-syntax-ns#'>
|
33
|
+
<rdf:Description rdf:about=''>
|
34
|
+
<ns1:language rdf:resource='http://id.loc.gov/vocabulary/languages/abk' />
|
35
|
+
<ns0:hasModel>Book</ns0:hasModel>
|
36
|
+
</rdf:Description>
|
37
|
+
</rdf:RDF>"
|
38
|
+
```
|
39
|
+
|
40
|
+
As you can see, the link has been added to the property as an `rdf:resource` attribute rather than as a value. If you are updating objects via a web form, you will use the language_uri attribute in the form rather than the language attribute. You will also need to add the `language_uri` field to the whitelisted parameters in the controller.
|
41
|
+
|
42
|
+
|
43
|
+
|