Hi Mark, Just getting to this now.
Could you give us more details about the use case for these possible "Attributes"? I'm unclear what you mean when you say "lists of operational data". The only example seems to be a Java class configuration. How would this data be used? What sorts of data are we talking about (simple strings, dates, boolean, just java class info)? Based on use cases are you *certain* this data would not need translation to other languages? This almost sounds like it's either one of two things. Either it is metadata about a Collection, which does sound somewhat like "Metadata For All". Or, it's really Collection configuration/settings which sounds more like "Dynamic Configurations" (but possibly making them object-specific for some types of configurations): https://jira.duraspace.org/browse/DS-1242 The word "Attribute" here may be confusing me, as that makes me think of simplistic metadata on an object. But, your example sounds more like trying to find ways to store object-specific configuration/settings (which may affect how an object is displayed or similar) in the database. - Tim On 1/24/2014 1:22 PM, Mark H. Wood wrote: > (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. > > > > ------------------------------------------------------------------------------ > 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 > ------------------------------------------------------------------------------ WatchGuard Dimension instantly turns raw network data into actionable security intelligence. It gives you real-time visual feedback on key security issues and trends. Skip the complicated setup - simply import a virtual appliance and go from zero to informed in seconds. http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk _______________________________________________ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
