Structure - Revision history

Tdb01r: Redirecting to Category:API

2009-08-12T12:17:05Z

← Older revision		Revision as of 12:17, 12 August 2009
Line 1:		Line 1:
	~~{{development}}~~		#REDIRECT [[:Category:API]]
	~~{{manual}}~~
	~~==Terms==~~
	~~This is a definition of some terms used in the eprints documentation and comments. Many of these are "objects" within the code and the perl module which handle them is listed.~~

	~~=== repository ===~~
	~~<code>~~
	~~EPrints~~::~~Repository~~
	~~</code>~~
	An archive is a eprints archive with it's own website configuration and data. One install of the eprints software can run serveral seperate archives. Sharing code but with totally different configurations. Before EPrints 2.4 this was known as EPrints::Archive. This was changed to avoid confusion with the eprint status of "archive".
	~~===session===~~
	~~<code>~~
	~~EPrints::Session~~
	~~</code>~~
	~~A session is created every time a cgi script or a bin script is executed, and terminated afterwards.~~

	~~=== eprint ===~~
	~~<code>~~
	~~EPrints::DataObj::EPrint~~
	~~</code>~~
	An eprint is a record in the system which has one or more ''documents'' and some ''metadata''. Usually, more than one ''document'' is to provide the same information in multiple formats, although this is not compulsary. Pre 2.4 this was known as EPrints::EPrint.
	~~=== document ===~~
	~~<code>~~
	~~EPrints::DataObj::Document~~
	~~</code>~~
	A document is a single format of an ''eprint'', eg. HTML, PDF, PS etc. It can contain more than one file, for example HTML may contain more than one html page + image files. The actual files are stored in the filesystem. Pre 2.4 this was known as EPrints::Document.
	~~=== user ===~~
	~~<code>~~
	~~EPrints::DataObj::User~~
	~~</code>~~
	~~A user registered with the system. (NOT necesarily the author of the ''eprints'' they deposit). Pre 2.4 this was known as EPrints::User~~
	~~=== subject ===~~
	~~<code>~~
	~~EPrints::DataObj::Subject~~
	~~</code>~~
	A ''subject'' has an id and a list of who it's parents are. There is a build in ''subject'' with the id "ROOT" to act as the top level. A subject can have more than one parent to allow you to create a rich lattice, rather than just a tree, but loops are not allowed.
	; '''type''' or '''usertype''' or '''eprinttype''' : ''users'', ''eprints'' and ''documents'' all have a "type". This controls how they are "cited" and also for ''users'' and ''eprints'' it controls what ''fields'' may be edited, and which are required.
	~~=== dataobj (aka "item") ===~~
	~~<code>~~
	~~EPrints::DataObj~~
	~~</code>~~
	The "super class" of ''subjects'', ''users'', ''eprints'' and ''documents'' etc. In the very core of the system these are all treated identically and much of the configuration and methods of these classes of "thing" are identical. We use the term ''item'' to speak about the general case.
	~~=== dataset ===~~
	~~<code>~~
	~~EPrints::DataSet~~
	~~</code>~~
	~~A dataset is a collection of ''items'' of the same type. It can be searched.~~
	Some datasets all have the same "config id". The "config id" is used to get information about the dataset from the archive config - inbox, buffer, archive and deletion all have the same metadata fields and types.
	~~Core datasets are:~~

	{\|
	~~\| DATASET ID~~
	~~\| COMMENT~~
	\|-
	~~\| eprint~~
	~~\| EPrint records are the core of the system.~~
	\|-
	~~\| user~~
	~~\| Users registered with the system.~~
	\|-
	~~\| subject~~
	~~\| The subject tree.~~
	\|-
	~~\| document~~
	~~\| Documents belonging to EPrints. Every document is part of an EPrint record.~~
	\|-
	~~\| subscription~~
	~~\| Subscriptions made by users. Every subscription is a part of a Subscription record.~~
	\|-
	~~\| history~~
	~~\| Stores actions performed on records.~~
	\|}

	~~In addtion to these datasets are four virtual datasets: inbox, buffer, archive and deletion. These act just like "eprint" except that they are filtered to only contain records with those status.~~

	~~Note that prior to 2.4 the "eprint" dataset was virtual, rather than "inbox", "buffer" etc. The History dataset was introduced in 2.4.~~
	~~=== database ===~~
	~~<code>~~
	~~EPrints::Database~~
	~~</code>~~
	~~The connection to the MySQL back end. ''datasets'' are stored in the MySQL system, but you do not have to address it directly.~~
	~~=== fields (or "metadata fields") ===~~
	~~<code>~~
	~~EPrints::MetaField~~
	~~</code>~~
	~~A single field in a dataset. Each dataset has a few "system" fields which eprints uses to manage the system and then any number of ''archive'' specific fields which you may configure.~~
	~~=== subscriptions ===~~
	~~<code>~~
	~~EPrints::Subscription~~
	~~</code>~~

	~~Some software refers to this concept as "alerts".~~

	~~A stored search which is performed every day/week/month and any new results are the mailed to the user who owns the subscription.~~

	~~This diagram does not show "Subscription". Subscription is a subclass of DataObj (like EPrint, User etc.). A Subscription is associated with one User. A User is associated with 0..n Subscription's.~~

Moj at 12:21, 3 January 2007

2007-01-03T12:21:39Z

← Older revision		Revision as of 12:21, 3 January 2007
Line 1:		Line 1:
			{{development}}
	{{manual}}		{{manual}}
	==Terms==		==Terms==

WikiSysop: /* repository */

2006-03-06T10:36:14Z

repository

← Older revision		Revision as of 10:36, 6 March 2006
Line 8:		Line 8:
	</code>		</code>
	An archive is a eprints archive with it's own website configuration and data. One install of the eprints software can run serveral seperate archives. Sharing code but with totally different configurations. Before EPrints 2.4 this was known as EPrints::Archive. This was changed to avoid confusion with the eprint status of "archive".		An archive is a eprints archive with it's own website configuration and data. One install of the eprints software can run serveral seperate archives. Sharing code but with totally different configurations. Before EPrints 2.4 this was known as EPrints::Archive. This was changed to avoid confusion with the eprint status of "archive".
	~~; '''~~session~~''' :~~		===session===
	<code>		<code>
	EPrints::Session		EPrints::Session
	</code>		</code>
	A session is created every time a cgi script or a bin script is executed, and terminated afterwards.		A session is created every time a cgi script or a bin script is executed, and terminated afterwards.

	=== eprint ===		=== eprint ===
	<code>		<code>

WikiSysop at 10:35, 6 March 2006

2006-03-06T10:35:56Z

← Older revision		Revision as of 10:35, 6 March 2006
Line 3:		Line 3:
	This is a definition of some terms used in the eprints documentation and comments. Many of these are "objects" within the code and the perl module which handle them is listed.		This is a definition of some terms used in the eprints documentation and comments. Many of these are "objects" within the code and the perl module which handle them is listed.

	~~; '''~~repository~~''' :~~		=== repository ===
	<code>		<code>
	EPrints::Repository		EPrints::Repository
	</code>		</code>
	An archive is a eprints archive with it's own website configuration and data. One install of the eprints software can run serveral seperate archives. Sharing code but with totally different configurations. Before EPrints 2.4 this was known as EPrints::Archive.		An archive is a eprints archive with it's own website configuration and data. One install of the eprints software can run serveral seperate archives. Sharing code but with totally different configurations. Before EPrints 2.4 this was known as EPrints::Archive. This was changed to avoid confusion with the eprint status of "archive".
	; '''session''' :		; '''session''' :
	<code>		<code>
Line 13:		Line 13:
	</code>		</code>
	A session is created every time a cgi script or a bin script is executed, and terminated afterwards.		A session is created every time a cgi script or a bin script is executed, and terminated afterwards.
	~~; '''~~eprint~~''' :~~		=== eprint ===
	<code>		<code>
	EPrints::DataObj::EPrint		EPrints::DataObj::EPrint
	</code>		</code>
	An eprint is a record in the system which has one or more ''documents'' and some ''metadata''. Usually, more than one ''document'' is to provide the same information in multiple formats, although this is not compulsary. Pre 2.4 this was known as EPrints::EPrint.		An eprint is a record in the system which has one or more ''documents'' and some ''metadata''. Usually, more than one ''document'' is to provide the same information in multiple formats, although this is not compulsary. Pre 2.4 this was known as EPrints::EPrint.
	~~; '''~~document~~''' :~~		=== document ===
	<code>		<code>
	EPrints::DataObj::Document		EPrints::DataObj::Document
	</code>		</code>
	A document is a single format of an ''eprint'', eg. HTML, PDF, PS etc. It can contain more than one file, for example HTML may contain more than one html page + image files. The actual files are stored in the filesystem. Pre 2.4 this was known as EPrints::Document.		A document is a single format of an ''eprint'', eg. HTML, PDF, PS etc. It can contain more than one file, for example HTML may contain more than one html page + image files. The actual files are stored in the filesystem. Pre 2.4 this was known as EPrints::Document.
	~~; '''~~user~~''' :~~		=== user ===
	<code>		<code>
	EPrints::DataObj::User		EPrints::DataObj::User
	</code>		</code>
	A user registered with the system. (NOT necesarily the author of the ''eprints'' they deposit). Pre 2.4 this was known as EPrints::User		A user registered with the system. (NOT necesarily the author of the ''eprints'' they deposit). Pre 2.4 this was known as EPrints::User
	~~; '''~~subject~~''' :~~		=== subject ===
	<code>		<code>
	EPrints::DataObj::Subject		EPrints::DataObj::Subject
Line 34:		Line 34:
	A ''subject'' has an id and a list of who it's parents are. There is a build in ''subject'' with the id "ROOT" to act as the top level. A subject can have more than one parent to allow you to create a rich lattice, rather than just a tree, but loops are not allowed.		A ''subject'' has an id and a list of who it's parents are. There is a build in ''subject'' with the id "ROOT" to act as the top level. A subject can have more than one parent to allow you to create a rich lattice, rather than just a tree, but loops are not allowed.
	; '''type''' or '''usertype''' or '''eprinttype''' : ''users'', ''eprints'' and ''documents'' all have a "type". This controls how they are "cited" and also for ''users'' and ''eprints'' it controls what ''fields'' may be edited, and which are required.		; '''type''' or '''usertype''' or '''eprinttype''' : ''users'', ''eprints'' and ''documents'' all have a "type". This controls how they are "cited" and also for ''users'' and ''eprints'' it controls what ''fields'' may be edited, and which are required.
	~~; '''~~dataobj~~''' or '''~~item~~''' :~~		=== dataobj (aka "item") ===
	<code>		<code>
	EPrints::DataObj		EPrints::DataObj
	</code>		</code>
	The "super class" of ''subjects'', ''users'', ''eprints'' and ''documents'' etc. In the very core of the system these are all treated identically and much of the configuration and methods of these classes of "thing" are identical. We use the term ''item'' to speak about the general case.		The "super class" of ''subjects'', ''users'', ''eprints'' and ''documents'' etc. In the very core of the system these are all treated identically and much of the configuration and methods of these classes of "thing" are identical. We use the term ''item'' to speak about the general case.
	~~; '''~~dataset~~''' :~~		=== dataset ===
	<code>		<code>
	EPrints::DataSet		EPrints::DataSet
Line 73:		Line 73:

	Note that prior to 2.4 the "eprint" dataset was virtual, rather than "inbox", "buffer" etc. The History dataset was introduced in 2.4.		Note that prior to 2.4 the "eprint" dataset was virtual, rather than "inbox", "buffer" etc. The History dataset was introduced in 2.4.
	~~; '''~~database~~''' :~~		=== database ===
	<code>		<code>
	EPrints::Database		EPrints::Database
	</code>		</code>
	The connection to the MySQL back end. ''datasets'' are stored in the MySQL system, but you do not have to address it directly.		The connection to the MySQL back end. ''datasets'' are stored in the MySQL system, but you do not have to address it directly.
	~~; '''~~fields~~'''~~ or ~~'''~~metadata fields~~''' :~~		=== fields (or "metadata fields") ===
	<code>		<code>
	EPrints::MetaField		EPrints::MetaField
	</code>		</code>
	A single field in a dataset. Each dataset has a few "system" fields which eprints uses to manage the system and then any number of ''archive'' specific fields which you may configure.		A single field in a dataset. Each dataset has a few "system" fields which eprints uses to manage the system and then any number of ''archive'' specific fields which you may configure.
	~~; '''~~subscriptions~~''' (sometimes called alerts in other archives) :~~		=== subscriptions ===
	<code>		<code>
	EPrints::Subscription		EPrints::Subscription
	</code>		</code>

			Some software refers to this concept as "alerts".

	A stored search which is performed every day/week/month and any new results are the mailed to the user who owns the subscription.		A stored search which is performed every day/week/month and any new results are the mailed to the user who owns the subscription.

	This diagram does not show "Subscription". Subscription is a subclass of DataObj (like EPrint, User etc.). A Subscription is associated with one User. A User is associated with 0..n Subscription's.		This diagram does not show "Subscription". Subscription is a subclass of DataObj (like EPrint, User etc.). A Subscription is associated with one User. A User is associated with 0..n Subscription's.

WikiSysop at 10:33, 6 March 2006

2006-03-06T10:33:15Z

← Older revision		Revision as of 10:33, 6 March 2006
Line 3:		Line 3:
	This is a definition of some terms used in the eprints documentation and comments. Many of these are "objects" within the code and the perl module which handle them is listed.		This is a definition of some terms used in the eprints documentation and comments. Many of these are "objects" within the code and the perl module which handle them is listed.

	; '''~~archive~~''' :		; '''repository''' :
	<code>		<code>
	EPrints::~~Archive~~		EPrints::Repository
	</code>		</code>
	An archive is a eprints archive with it's own website configuration and data. One install of the eprints software can run serveral seperate archives. Sharing code but with totally different configurations.		An archive is a eprints archive with it's own website configuration and data. One install of the eprints software can run serveral seperate archives. Sharing code but with totally different configurations. Before EPrints 2.4 this was known as EPrints::Archive.
	; '''session''' :		; '''session''' :
	<code>		<code>
Line 15:		Line 15:
	; '''eprint''' :		; '''eprint''' :
	<code>		<code>
	EPrints::EPrint		EPrints::DataObj::EPrint
	</code>		</code>
	An eprint is a record in the system which has one or more ''documents'' and some ''metadata''. Usually, more than one ''document'' is to provide the same information in multiple formats, although this is not compulsary.		An eprint is a record in the system which has one or more ''documents'' and some ''metadata''. Usually, more than one ''document'' is to provide the same information in multiple formats, although this is not compulsary. Pre 2.4 this was known as EPrints::EPrint.
	; '''document''' :		; '''document''' :
	<code>		<code>
	EPrints::Document		EPrints::DataObj::Document
	</code>		</code>
	A document is a single format of an ''eprint'', eg. HTML, PDF, PS etc. It can contain more than one file, for example HTML may contain more than one html page + image files. The actual files are stored in the filesystem.		A document is a single format of an ''eprint'', eg. HTML, PDF, PS etc. It can contain more than one file, for example HTML may contain more than one html page + image files. The actual files are stored in the filesystem. Pre 2.4 this was known as EPrints::Document.
	; '''user''' :		; '''user''' :
	<code>		<code>
	EPrints::User		EPrints::DataObj::User
	</code>		</code>
	A user registered with the system. (NOT necesarily the author of the ''eprints'' they deposit).		A user registered with the system. (NOT necesarily the author of the ''eprints'' they deposit). Pre 2.4 this was known as EPrints::User
	; '''subject''' :		; '''subject''' :
	<code>		<code>
	EPrints::Subject		EPrints::DataObj::Subject
	</code>		</code>
	A ''subject'' has an id and a list of who it's parents are. There is a build in ''subject'' with the id "ROOT" to act as the top level. A subject can have more than one parent to allow you to create a rich lattice, rather than just a tree, but loops are not allowed.		A ''subject'' has an id and a list of who it's parents are. There is a build in ''subject'' with the id "ROOT" to act as the top level. A subject can have more than one parent to allow you to create a rich lattice, rather than just a tree, but loops are not allowed.
Line 38:		Line 38:
	EPrints::DataObj		EPrints::DataObj
	</code>		</code>
	The "super class" of ''subjects'', ''users'', ''eprints'' and ''documents''. In the very core of the system these are all treated identically and much of the configuration and methods of these classes of "thing" are identical. We use the term ''item'' to speak about the general case.		The "super class" of ''subjects'', ''users'', ''eprints'' and ''documents'' etc. In the very core of the system these are all treated identically and much of the configuration and methods of these classes of "thing" are identical. We use the term ''item'' to speak about the general case.
	; '''dataset''' :		; '''dataset''' :
	<code>		<code>
Line 47:		Line 47:
	Core datasets are:		Core datasets are:

	~~<code>~~		{\|
	DATASET ID ~~\| CONFIG ID~~ \| COMMENT		\| DATASET ID
	\| \|		\| COMMENT
	~~inbox~~ \| eprint \| ~~Eprints which users~~ are ~~still working on~~.		\|-
	~~buffer \| eprint~~ \| ~~Eprints submitted for editorial approval.~~		\| eprint
	~~archive~~ \| ~~eprint \| Eprints live in the archive.~~		\| EPrint records are the core of the system.
	~~deletion~~ \| ~~eprint \| Eprints which have been deleted from~~ the ~~archive~~.		\|-
	~~user \| user~~ \| ~~Users registered.~~		\| user
	~~subject~~ \| subject \| The subject tree ~~or lattice~~.		\| Users registered with the system.
	~~document~~ \| document \| ~~The documents~~ belonging to ~~ALL~~		\|-
	\| \| ~~eprints in the system~~.		\| subject
	~~subscription~~ \| ~~subscription~~ \| The ~~subscriptions which users have requested~~.		\| The subject tree.
	~~</code>~~		\|-
			\| document
			\| Documents belonging to EPrints. Every document is part of an EPrint record.
			\|-
			\| subscription
			\| Subscriptions made by users. Every subscription is a part of a Subscription record.
			\|-
			\| history
			\| Stores actions performed on records.
			\|}

			In addtion to these datasets are four virtual datasets: inbox, buffer, archive and deletion. These act just like "eprint" except that they are filtered to only contain records with those status.

			Note that prior to 2.4 the "eprint" dataset was virtual, rather than "inbox", "buffer" etc. The History dataset was introduced in 2.4.
	; '''database''' :		; '''database''' :
	<code>		<code>

WikiSysop at 17:51, 1 March 2006

2006-03-01T17:51:45Z

← Older revision		Revision as of 17:51, 1 March 2006
Line 1:		Line 1:
	{{manual}}		{{manual}}
			==Terms==
			This is a definition of some terms used in the eprints documentation and comments. Many of these are "objects" within the code and the perl module which handle them is listed.

			; '''archive''' :
			<code>
			EPrints::Archive
			</code>
			An archive is a eprints archive with it's own website configuration and data. One install of the eprints software can run serveral seperate archives. Sharing code but with totally different configurations.
			; '''session''' :
			<code>
			EPrints::Session
			</code>
			A session is created every time a cgi script or a bin script is executed, and terminated afterwards.
			; '''eprint''' :
			<code>
			EPrints::EPrint
			</code>
			An eprint is a record in the system which has one or more ''documents'' and some ''metadata''. Usually, more than one ''document'' is to provide the same information in multiple formats, although this is not compulsary.
			; '''document''' :
			<code>
			EPrints::Document
			</code>
			A document is a single format of an ''eprint'', eg. HTML, PDF, PS etc. It can contain more than one file, for example HTML may contain more than one html page + image files. The actual files are stored in the filesystem.
			; '''user''' :
			<code>
			EPrints::User
			</code>
			A user registered with the system. (NOT necesarily the author of the ''eprints'' they deposit).
			; '''subject''' :
			<code>
			EPrints::Subject
			</code>
			A ''subject'' has an id and a list of who it's parents are. There is a build in ''subject'' with the id "ROOT" to act as the top level. A subject can have more than one parent to allow you to create a rich lattice, rather than just a tree, but loops are not allowed.
			; '''type''' or '''usertype''' or '''eprinttype''' : ''users'', ''eprints'' and ''documents'' all have a "type". This controls how they are "cited" and also for ''users'' and ''eprints'' it controls what ''fields'' may be edited, and which are required.
			; '''dataobj''' or '''item''' :
			<code>
			EPrints::DataObj
			</code>
			The "super class" of ''subjects'', ''users'', ''eprints'' and ''documents''. In the very core of the system these are all treated identically and much of the configuration and methods of these classes of "thing" are identical. We use the term ''item'' to speak about the general case.
			; '''dataset''' :
			<code>
			EPrints::DataSet
			</code>
			A dataset is a collection of ''items'' of the same type. It can be searched.
			Some datasets all have the same "config id". The "config id" is used to get information about the dataset from the archive config - inbox, buffer, archive and deletion all have the same metadata fields and types.
			Core datasets are:

			<code>
			DATASET ID \| CONFIG ID \| COMMENT
			\| \|
			inbox \| eprint \| Eprints which users are still working on.
			buffer \| eprint \| Eprints submitted for editorial approval.
			archive \| eprint \| Eprints live in the archive.
			deletion \| eprint \| Eprints which have been deleted from the archive.
			user \| user \| Users registered.
			subject \| subject \| The subject tree or lattice.
			document \| document \| The documents belonging to ALL
			\| \| eprints in the system.
			subscription \| subscription \| The subscriptions which users have requested.
			</code>
			; '''database''' :
			<code>
			EPrints::Database
			</code>
			The connection to the MySQL back end. ''datasets'' are stored in the MySQL system, but you do not have to address it directly.
			; '''fields''' or '''metadata fields''' :
			<code>
			EPrints::MetaField
			</code>
			A single field in a dataset. Each dataset has a few "system" fields which eprints uses to manage the system and then any number of ''archive'' specific fields which you may configure.
			; '''subscriptions''' (sometimes called alerts in other archives) :
			<code>
			EPrints::Subscription
			</code>
			A stored search which is performed every day/week/month and any new results are the mailed to the user who owns the subscription.

			This diagram does not show "Subscription". Subscription is a subclass of DataObj (like EPrint, User etc.). A Subscription is associated with one User. A User is associated with 0..n Subscription's.

WikiSysop at 17:51, 1 March 2006

2006-03-01T17:51:41Z

New page