Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Support Metadata On All DSpaceObjects #12

Closed
wants to merge 4 commits into
from

Conversation

Projects
None yet
4 participants
Owner

mdiggory commented May 9, 2012

@Mire Support for Metadata On All DSpaceObjects

Owner

peterdietz commented Jun 11, 2012

I've noticed that some change that has been slipped in is changing from a local ourContext to getContext() method. I guess I'm fine with it, is there any rationale for injecting that change?

Is there any concern with database drift since oracle will use table name RMetadataFieldRegistry and postgres will use: ResourceMetadataFieldRegistry ?

I haven't yet checked this out to give a solid analysis yet.

Owner

helix84 commented Jul 12, 2012

I thought Oracle's limit on table name was 30 bytes. "ResourceMetadataFieldRegistry" is 29 ASCII characters, so why not keep it?

Owner

helix84 commented Jul 12, 2012

Nevermind my last commment, I actually recommended that there shouldn't be separate tables, but existing metadatafieldregistry and metadatavalue be used instead. There's no reason to split metadata for items into one table and for everything else into another table.

Owner

mwoodiupui commented Aug 6, 2012

Also curious about the need for parallel metadata tables.

Owner

mdiggory commented Aug 8, 2012

I want to clarify my position on what the requirements are for metadata on all DSpace Objects

1.) We need different "containers" for metadata (Descriptive, Technical, Administrative) that can be named and be attached to any DSpace Object. These align with METS sections and would be serialized into our SIP/AIP/DIP as such.

2.) We need just plain old "properties" on Objects, which workflow and system can use and which are not exposed publicly.

3.) Finally, we need "Profiles" or true "Schema" that can be enforced on a DSpace Object (i.e. Content Types), these define the fields that can be added for Communities, Collection, Items, Bundles and Bitstreams, and likewise, can be extended to create different "Types" of Items and Bitstreams in DSpace.

At this point, the existing system abuses the concept of "schema" confusing it with "namespace", The closest thing DSpace has to a schema is the input-forms.xml that enforces input values that can go into Item metadata regardless of what MetadataSchema is in the Registry.... To be clear "MetadataSchema should be "MetadataNamespace" and DSpace has no "Schema" at this time. Don't confuse XML Schema with DCMI Namespace. Its a poor design.

The point of presenting this example is that we did actually create a typing mechanism for identifying the fields and can be used on DSpaceObject types.

Owner

mdiggory commented Aug 14, 2012

I'm going to delay this contribution and close this pull request

@mdiggory mdiggory closed this Aug 14, 2012

Owner

mwoodiupui commented Jun 19, 2013

"We need different 'containers' for metadata...." Why?

"We need...properties...which are not exposed publicly." We need ACLs on fields. Every time we hardwire what is or is not visible, someone comes up with an exception. Just make it all configurable.

@lap82 lap82 pushed a commit to lap82/DSpace that referenced this pull request Oct 23, 2013

@kstamatis kstamatis Merge pull request #12 from lap82/DS-1252-bte
 Some minor changes, fix retrieve data from crossref response
3638d9a
Owner

mdiggory commented Jun 6, 2014

mwoodiupui: "We need different 'containers' for metadata...." Why?

mdiggory: because, all metadata is not just "Descriptive", METS provides "Container-ship" and "Assignment" of sets of metadata in different formats (premis, mods, dc, etc) these sets serve various purposes within the METS wrapper.

mwoodiupui: "We need...properties...which are not exposed publicly." We need ACLs on fields. Every time we hardwire what is or is not visible, someone comes up with an exception. Just make it all configurable.

mdiggory: Yes, we do need ACL's on fields. But we also need to clearly separate the set of internal system level configuration properties from sets of publicly and/or semi-publically disseminated content metadata. This is so that theres a clear place to store "configuration" details vs "metadata"

@artlowel artlowel pushed a commit to atmire/DSpace that referenced this pull request Jun 13, 2014

@kstamatis kstamatis Merge pull request #12 from lap82/DS-1252-bte
 Some minor changes, fix retrieve data from crossref response
e2e3be9

@hardyoyo hardyoyo pushed a commit to hardyoyo/DSpace that referenced this pull request Mar 9, 2015

Hardy Pottinger Merge pull request #12 from hardyoyo/LSO1365-fix-userbox-positioning
small tweaks to div positioning to improve readability
f7c3a76

@kosarko kosarko added a commit to kosarko/DSpace that referenced this pull request May 29, 2015

@kosarko kosarko changed the log level to debug
fixes issue #12
f9a5e8a

@lap82 lap82 pushed a commit to 4Science/DSpace that referenced this pull request Jul 13, 2016

Luigi Andrea Pascarelli Merge pull request #12 from CSUC/patch-1
fixed a comma and a column in the addon sql file
4c9dcf2

@hardyoyo hardyoyo added a commit to hardyoyo/DSpace that referenced this pull request Feb 28, 2017

@hardyoyo hardyoyo Merge pull request #12 from hardyoyo/DP-47-prefix-solr-cores
[DP-47] prefix solr cores
53e8900
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment