Skip to content
This repository
branch: master
Fetching contributors…

Octocat-spinner-32-eaf2f5

Cannot retrieve contributors at this time

executable file 153 lines (112 sloc) 6.068 kb
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 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 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152
* Make a universal edit_in_place function instead of duplicating it in
  the work and expression controllers. (Tried but got funny stuff
  about an & sneaking in somewhere that messed things up.)

* Make tests. There are no tests. This is not test-driven
  development.

* There is no error-checking. Raise exceptions and handle errors
  wherever something might go wrong.

* Add relation attributes to Creation, Realization, Production and
  Owernship test fixtures, and show the relations on the WEMI pages
  (e.g. isAuthorOf, isPublisherOf, owned, translated). Use the RDA
  roles?

* Add Work to the Aboutness model so that a Work can have another Work
  as its subject.

* Set up a many-to-many Work-to-Work relation, with relation
  attribute.

* Do I need these? Not sure any more.
  * Set up an many-to-many Expression-to-Expression relation, with
    relation attribute.
  * Set up a many-to-many Manifestation-to-Manifestation relation, with
    relation attribute.
  * Set up an many-to-many Item-to-Item relation, with relation
    attribute.

* In a Work's tree display, use Ajax drag and drop to move a
Manifestation from one Expression to another, or an Item from one
Manifestation to another.

* Make an intelligent autocompleting textbox, one that knows about
either all entities or a subset of them (e.g. just Works or just G2
entities or just G3 entities).

If I want to add a subject to a work, for example, it would be nice
if I could start typing and all possible subjects would be suggested
as I typed, displaying the anchor_text and telling me what type the
entity is (Expression, Maniestation, etc.)

On every entity page, use this autocompleting textbox on Works to
make it easy to add the entity to a Work as a subject.

* Be able to remove the connection between any two entities, e.g. Work
and any of its subjects, G2 entity and G1 entity, etc. (What to do
about disconnecting an Expression from a Work, for example? That
would leave an expression hanging. Maybe it should be impossible to
disconnect an Item from a Manifestation, a Manifestation from an
Expression, or an Expression from a Work. One can either move them
to a place under another entity, or delete it if it has no
children.)

* If any entity is deleted, destroy all its connections with other
entities. (Can this be done in the model with callbacks?) Or is
this done automatically by what's set up in the models?

* Make a simple way of listing all works for which a given entity is a
  subject.

* Add methods to Manifestation and Item so it is easy to tell which
  Work(s) they represent. (Beware of aggregates later.)

* Two Works, Expressions or Manifestations may have the same title, in
  which case find_or_create_by_title isn't enough. Is the anchor_text
for these entities (see model files) enough to uniquely identify
them (without knowing the ID number from the database)? If not,
what is? There has to be a reliable way to people to unambiguously
identify or find something. The unambiguous identifier should be
used as the anchor_text and displayed everywhere the entity is
listed.

* How to make a find_or_create_unambiguously for every entity? For G1
entities find_or_create_by_title does the job but is ambiguous (see
above note). For G2 find_or_create_by_name is also ambiguous, and
notice it's name instead of title. (Aha, we're into authority
control here. Perhaps we can gloss over this for a while until
implementing FRAD is necessary, or maybe we can pull in bits from
FRAD as needed.) For G3 entities, find_or_create_by_term is also,
sadly, ambiguous, because there could be a Concept with the same
term as a Place or Object etc.

This find_or_create_unambiguously method would be useful for
associating subjects with works.

In the meantime, could work around by requiring a Work to be
associated with a subject from the subject's page, i.e. there is a
  "Make this the subject of work ____" on every page.

* Redirect people back to the page they want to edit after they've
successfully logged in.

* Add OpenID. See
http://railscasts.com/episodes/170-openid-with-authlogic
for example.

* Let user add/remove a Creator on a work page, a Realizer on an
Expression page, a Producer on an Manifestation page, and an Owner
on an Item page.

* Move from REXML to Nokogiri (http://nokogiri.org/)

* Investigate fuzzy matching tools in Ruby (or something else) to
help with matching text strings.

* Try getting xISBN results in native Ruby format.

* Investigate connecting ISTC to Expressions, though it may not match
well. Maybe Works.
http://www.myidentifiers.com/multimedia/pdfs/ISTC_overview_ISQv21no3.pdf

* Investigate Open Library work ID and their API.
http://openlibrary.org/dev/docs/restful_api
http://openlibrary.org/works/OL102749W/Moby_Dick

* Investigate OCLC work ID.

* Look at Freebase and DBPedia as sources of information. Eg:

http://dbpedia.org/page/Harry_Potter_and_the_Philosopher%27s_Stone
RDF: http://dbpedia.org/data/Harry_Potter_and_the_Philosopher%27s_Stone.rdf

http://www.freebase.com/view/en/harry_potter_and_the_goblet_of_fire
RDF: http://rdf.freebase.com/rdf/en.harry_potter_and_the_goblet_of_fire

* Ruby RDF libraries
http://github.com/rsinger/RDFObjects (Ross Singer)
http://github.com/gkellogg/rdf_context
http://rdf.rubyforge.org/
See http://blog.datagraph.org/2010/04/parsing-rdf-with-ruby

* Bill Dueber's library_stdnums gem would make some things easier
  http://robotlibrarian.billdueber.com/simple-ruby-gem-for-dealing-with-isbnissnlccn/

* Investigate the new RDF.rb
  http://blog.datagraph.org/2010/12/rdf-for-ruby

Aggregates
----------

* Keep aggregates in mind for now, but save the implementation for
  later until the project is further along. Assume many-to-many
  relationships everywhere, but do not use them, or just use the
  :first object returned from a list for now instead of the whole
  array.

* Use the Work-of-Works model to implement aggregates.




Something went wrong with that request. Please try again.