(This is independent of Metadata for All, which is needed anyway.) I want to attach to Collections lists of operational data, with multiple values per Collection. I immediately thought of overloading "metadata" for this purpose, given that we want to extend metadata operations to all DSpaceObject subclasses. But (a) these lists don't have language, authority, confidence, or a structured namespace, and (b) they should never be exposed outside of the DSpace administrative UI. This seemed like an abuse of metadata. So I came up with another type of information about DSOs: "attributes".
An Attribute has a name, which is a simple string (but you may
pretend to group things "like.this"). It has an unordered collection
of String values. It's stored in the database like this:
CREATE TABLE Attributes
(
attribute_id INTEGER PRIMARY KEY,
object_type INTEGER,
object_id INTEGER,
name VARCHAR(64),
value VARCHAR
);
CREATE INDEX attributes_idx ON Attributes(object_type, object_id, name);
I guess the values *could* be ordered, if someone can think of a good
reason. Just add another INTEGER field.
The immediate purpose of inventing Attributes is to avoid spawning yet
another configuration horror:
identifier.classes.COLLECTION_ID.1 = foo
identifier.classes.COLLECTION_ID.2 = bar
...
Instead there would be new administrative UI to manage the
"identifier.classes" Attribute. It's sort of the entering wedge of
moving configuration into the database.
Attributes do not appear on object detail pages and are not exposed to
harvesters and such. They hold local administrative information about
their objects. They should be exportable for backup but not for
dissemination.
Thoughts? Am I overcomplicating things? Or is this *too* simple?
Alternative: a way to mark a metadata namespace as "not for export".
It's still rather severe overloading, but at least we'd have a simple
way to keep values from leaking out of the DSpace instance or being
shown to users. We probably need this anyway.
Another alternative: configure this kind of thing using Spring. But
we want to move away from configuration *files*, and this would often
require introducing a new bean which has no behavior and no obvious
place to be injected -- just a data structure to be stuck into
something handy. If a design is ugly, it's probably wrong.
Another alternative: create a new DB table each time we need a new type
of list. This just seems likely to lead to a clutter of tiny tables,
all alike.
--
Mark H. Wood, Lead System Programmer mw...@iupui.edu
Machines should not be friendly. Machines should be obedient.
signature.asc
Description: Digital signature
------------------------------------------------------------------------------ CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
_______________________________________________ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
