|This page is under development as part of the EPrints 3.0 manual. It may still contain content specific to earlier versions. Manuals for previous versions of EPrints are also available.|
Metadata Field Types
There are many different types of metadata field. The type controls how a field is rendered, indexed, searched and so forth. A field always has a type and a name property, and usually has several more. Most properties are documented on this page, but some properties are only available to certain types of field, and they are listed on the page for that field.
Some of these subclasses provide very rich features, others very simple. For example the url field works just like the text field except that it's only valid if it looks like a url and when rendered it is a hyper-link.
- Basic metadata field
- Boolean - TRUE or FALSE (or can be unset, of course)
- Compound - virtual field, joins together several "multiple" fields. eg. author_name and author_email
- Multilang - allows language variants of a field. eg. titles in French, German and/or English.
- Date - stores a date.
- Time - stores a date and time.
- File - virtual field represtenting the files in a document
- Float - stores a floating point value
- Id - deprecated (do not use)
- Int - a positive integer value
- Search - a serialised search
- Set - a limited set of options
- Arclanguage - as for set, but the options are the valid languages of this repository
- Fields - as for set, but the options are the fields in a dataset.
- Langid - used internally by multilang fields to store the language id.
- Namedset - like a normal set, but takes its options from a namedset configuration file.
- Subject - possible values are taken from the Subject heirarchy.
- Subobject - a virtual field, similar to itemref, but representing an object or objects which are sub-parts of the current object (as oppose to just related in some way)
- Text - the basic text field. Maximum 255 bytes. nb. uft-8 means some chars take more than one byte.
These can be customised in the user_fields.pl and eprint_fields.pl files. Note that changing these files does not automatically modify the underlying database so should (generally) only be done before the database is created. Some metadata properties do not affect the database, and are marked as such.
If you add or remove fields, or modify a property which affects the database then you'll need to alter the database to match. In 3.0 this must be done by hand, but we have plans to build a tool to do this for you.
Note that true/false properties use 1 and 0 to indicate their setting.
|name||n/a||This property is always required. This property affects the database structure. This is the internal name of the field. It should only contain a-z and underscores. It will be used to identify this field in scripts, other configuration files, in the database, and in the XML export/import system, etc. It must be unique within the object (so the EPrint Object can't have two fields called "email" but the eprint object and User Object could have a field each of the same name.|
|type||n/a||This property is always required. This property affects the database structure. This sets the type of the metafield, which in turn affects what other properties it may have. The value must be one of the metafield types listed above.|
|multiple||0||This property affects the database structure. This indicates if this field is a single value or a list of values. eg. "title" is only a single longtext field but "creators" is a multiple name field. In the database a non-multiple field is stored in one (or more) columns in the main object table, but a multiple field gets its own table.|
|sql_index||1||When the database is created this field indicates that an SQL index should be created to speed searching. Different field types override the default value with the sensible option for that type of field. It's not worth putting an sql index on a field that is only ever searched for words in it (like title or abstract) but it is worth indexing fields whoes values are explicitly searched for, or where ranges are searched - date fields, set fields etc. It's unlikely you'll need to set this by hand. You could change it after the database has been created; it won't break anything. In fact, it won't do anything at all.|
These properties affect how values of the metadata in this field are rendered.
Certain of these properties can be turned on temporarily by the Citation Format files - render_magicstop for example.
|browse_link||undef||This is the name of a view which values of this field should be linked to. For example if their was a browse by publishers view configured named "pubs", then adding browse_link=>"pubs" to the publisher field would cause it to be linked into the page for the named publisher whenever it is rendered.|
|render_quiet||0||Normally if a field is rendered an it isn't set, it is rendered as a big ugly "UNSPECIFIED". Setting render_quiet on a field means it just gets rendered as nothing if it's empty.|
|render_magicstop||0||If true then this renders a full stop at the end of this field. Unless the last character is a dot, question mark or exclamation mark. This helps avoid the ugly "World without Cheese?." affect you get when titles end in ? or !.|
|render_noreturn||0||If true then all CR and LF's are turned into normal spaces.|
|render_dont_link||0||Set this to true to stop this field hyperlinking itself when rendered. Currently only affects url fields and email fields.|
|render_single_value||undef||The value of this property is the name of a subroutine to call to render values from this field. For a multiple field this is called once per value in the list of values. The function should take the following parameters: ( $session, $field, $value, $object). It should return an XHTML DOM object of the rendered value.|
|render_value||undef||As with render single value, but this gets passed the entire list of values (an array reference) if it's a multiple field. Parameters passed are: ( $session, $self, $value, $all_langs, $no_link, $object ). $all_langs indicates that all language variants should be shown - only really useful for multilang fields. $no_link being true is a request to place no hyperlinks in the resulting HTML. It should return an XHTML DOM object of the rendered value.|
Input and Validation Properties
|required||0||If this is set to true then the field is always marked as required, no matter what the workflow says.|
||can_clone||1||no||no||core||If this is set to false then this field is not copied when the object is cloned. This is mostly used by system fields such as "dir" or "datestamp".|