Find file
Fetching contributors…
Cannot retrieve contributors at this time
executable file 153 lines (112 sloc) 5.93 KB
* 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
* 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
* 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
* 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
* 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
* 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
* 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
* 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
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 (
* 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.
* Investigate Open Library work ID and their API.
* Investigate OCLC work ID.
* Look at Freebase and DBPedia as sources of information. Eg:
* Ruby RDF libraries (Ross Singer)
* Bill Dueber's library_stdnums gem would make some things easier
* Investigate the new RDF.rb
* 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
* Use the Work-of-Works model to implement aggregates.