ROADS v2 Requirements (draft3)

This document sets out the requirements for ROADS v2. It includes requirements discussed at the Templates Workshop (8th October), Technical Workshop (9th October) and the Requirements Meeting (7th November). It is intended for discussion on open-roads, after which a final document will be produced.

The requirements have prioritised into essential and desirable categories. Those requirements that have been designated desirable will only be implemented if there is time. Each requirement has also been rated for technical difficulty as follows in ascending order of difficulty.

EASY*

EASY**

DIFFICULT*

DIFFICULT**

The number after each requirement refers to the original discussion document prepared for the Requirements Meeting <URL:http://www.ukoln.ac.uk/~lismd/ROADSv2.html>.

Essential Requirements

User interface

  1. The template editor should be re-written to make it less complex and monolithic. (Jon Knight wanted to split the template editor into two blocks so that the code could be simplified. This change should be invisible to the user.) (DIFFICULT**) 15
  2. Sensible defaults should be inserted whether attributes are visible or not. (DIFFICULT*) 18
  3. The number of variants should be dynamically alterable during the editing of a template. It is difficult always to know how many variants would be required for a particular record before it is actually catalogued. With volunteers about to get involved in the cataloguing process, this would be important. (DIFFICULT**) 20
  4. It should be possible to edit the options that appear at the bottom of the template editor views, so that TIPS only have access to the ones the ROADS administrator wishes. With authentication information (primarily username and server, but possibly including passwords so that authorised users could access the template editor from a different server), different options could be offered to different people. (DIFFICULT*) 22
  5. A Separate tool to identify duplicate URLs. (EASY**) 24
  6. A general mechanism to insinuate extra attribute/value constraints into searches via the search form would be the most useful way of approaching hard wiring a search constraint such as a particular subject category, but not necessarily making this visible to the end user. (DIFFICULT*) 26
  7. The result views feature should be enhanced to take in multiple views selected by template type and the status of the completed search (hits/no hits/stoplisted search terms/...) plus extra conditional features in the pseudo-HTML rendering language (Needs further discussion). (DIFFICULT**) 27
  8. The two search views 'full' and 'headlines' could be extended so that 1. different views are allowed depending on template type, and 2. arbitrary views can be set up - this would allow for different views to be used for the results of searches in different databases. (DIFFICULT**) 30

Templates

  1. The template editor should write out the value associated with a particular attribute as a single line, with a tool which would convert existing templates. (Note: the general format of records is separate to how they will be delivered via WHOIS++. The question was whether we should use the same format as WHOIS++ - formatted descriptions with line breaks. This would allow for compatibility with Bunyip's WHOIS++ servers and CNIDR. It would also allow formatting in the description field. Martin Hamilton noted that it was a developer's requirement and needed more investigation.) 2
  2. To allow the description of relationships between objects in the templates - initially concentrating on parent / child relationships, but allowing for other relationships to be defined at a later stage. (There was a discussion of what attribute should be used to store this information - maybe a Relation attribute or part of the Subject-Description: e.g. Subject-Description-Scheme-v1: relation. This requires discussion on the mailing list.) (EASY**) 5
  3. The addition of a specific country code to a record template so that one can make browsable lists by country, using an attribute called Organisation-Country in the ORGANISATION cluster, and the ISO country codes as the format of entry. (EASY**) 7
  4. The addition of new default TRAINMAT template - outlined in Appendix A of RFC 2007: Foster, et al., Catalogue of Network Training Materials, October 1996. <http://ds.internic.net/rfc/rfc2007.txt> and EVENT template. (EASY*) 8

Documentation

  1. Configuration documentation should be consolidated into an Admin. Guide to Configuration, including pseudo-HTML configuration features. The individual documentation should be consolidated into an full admin. Guide. Should be in different formats: RTF, PostScript, HTML and LaTeX. (EASY**) 38
  2. There should be a document explaining the logic behind the search algorithm. This was asked for at the Technical Meeting. (EASY**) 39
  3. It has been noted that there is difficulty in working at the Unix command line level when the files being manipulated are typically owned by nobody. There should be a document covering strategies for dealing with this using Unix users/groups and ACLs where available. This would become part of the Admin. Guide. (EASY**) 40
  4. The Admin Guide should include guidance on moving a test installation to a live installation. (EASY**) 41

Desirable Requirements

User Interface

  1. The installer tool should do more to advise or enforce sensible access control lists, perhaps by providing a reference to the admin-centre installation checking tool (EASY**) 13
  2. The installation should be able to use existing configuration information - i.e. the lib/ROADS.pm file. (DIFFICULT**) 14
  3. It should be possible to insert an existing template into one being edited by quoting its handle, in addition to the cluster search feature. The cataloguer could just insert the handle of an ORGANISATION template or cluster. (DIFFICULT*) 16
  4. It should be possible to create a new template based on a currently displayed one. (DIFFICULT*) 16
  5. Automatically generated fields could be hidden on the template editor, assuming that sensible defaults are present for hidden fields (DIFFICULT*). Also arbitrary text should be able to be associated with attributes when rendered in the template editor, e.g. a note next to the handle field informing the user that is automatically generated. (EASY*) 18
  6. It should be possible to make global changes across multiple templates. This should be done through a separate script. (EASY**) (Note: Jasper Tredgold, SOSIG Technical Officer, has written a script to do this which may be included with ROADS.) 19
  7. A simple template view of the most commonly used templates, using the most commonly used attributes should be distributed as standard. (EASY* but TIME CONSUMING) 21
  8. Addition of sub-string searching. (DIFFICULT*) 28
  9. Addition of proximity searching. (DIFFICULT**) 30
  10. Indexing of keyword phrases (may be dependant on index and database caching.) (DIFFICULT**) 30
  11. Access should be able to be restricted on a more fine-grained level, e.g. so that a TIP could run the template editor but not use other admin. centre features, or could use the template editor to enter a record, but not be able to re-index the database or delete templates. ROADS needs a access control list, which includes server and username. (DIFFICULT*) 31
  12. Only display parents in subject listings with links to children. (EASY**) 5

Templates

  1. Use the dormant category attribute in ROADS templates to describe the type of object being described. (DIFFICULT**) (Note: There would need to be some agreement on sub-categories so that searching across services could be possible. Agreed categories could selected from a drop-down menu. Discussion required on mailing list) 4
  2. ROADS templates should be version numbered. (DIFFICULT*) 10
  3. A minimum set of attributes should be defined in order to promote interoperability between services. This requires discussion on the mailing list. (DIFFICULT*) 11
  4. Addition of a record-status attribute to record at which stage the cataloguing process has got to. (EASY*) 12
  5. Addition of attributes to record information about the person or organisation that originally provided the record. These would take the form: Record-Created-By-Name or Record-Information-Provider. (EASY*) 12
  6. The what's new list should be more flexible, e.g. restricting the list to the last 30 new records, or by date depending on the number of resources added to the database. (DIFFICULT*) 32
  7. A BUBL style mailshot of what's new list. (DIFFICULT**)
  8. The link checker should note when the content of an object has changed. Martin noted a problem in that he would not encourage people to download all objects on the database. Easier would be to check the HTTP return code last modified date and flag any changes. OMNI thought that this would be better than nothing. (DIFFICULT**) 41
  9. There should be some way of breaking down subdivisions of browsable lists. OMNI, for example, by way of e-journal, mailing list, etc. (DIFFICULT**) 41

Chris Osborne

c.j.osborne@bris.ac.uk