tag:blogger.com,1999:blog-3018115029736777901.post8054629661030428713..comments2023-07-23T11:59:15.770+01:00Comments on futureArch, or the future of archives...: building castles 1: the problemSusan Thomashttp://www.blogger.com/profile/04962583988591861531noreply@blogger.comBlogger6125tag:blogger.com,1999:blog-3018115029736777901.post-91454607058331642112009-11-18T17:34:44.876+00:002009-11-18T17:34:44.876+00:00Thanks for your comment - its nice to have active ...Thanks for your comment - its nice to have active discussion on the blog! :-)<br /><br />It sounds like you're building a repository - management as well as serving the content. I wasn't clear in my statement of the problem, but essentially what I'm after (for the moment) is an interface to copies of the items. The real things are managed elsewhere - and thus when you say "A web server simply serves content, it doesn't manage it" it is OK, because management is happening outside of this less ambitious application - that is why I asked about Fedora. In this instance I suspect just some way of addressing and resolving the content is enough.<br /><br />I agree regards RDF & triples - this is essentially the "middle one" - each "resource" being RDF. I've already got a script that builds a bunch of RDF resources out of the EAD (for each file, component and the collection) and the next bit is to shove that into a triple-store and run to queries to see if I've done it right! :-)<br /><br />For what it is worth, I've experience of both DSpace & Fedora... :-)pixelatedpetehttps://www.blogger.com/profile/01298274275234137603noreply@blogger.comtag:blogger.com,1999:blog-3018115029736777901.post-48262279793091943232009-11-18T15:16:51.269+00:002009-11-18T15:16:51.269+00:00A web server simply serves content, it doesn't...A web server simply serves content, it doesn't manage it. Some web application servers do both, but not usually in a way specific to the needs of archives. Fedora does. So does Dspace [http://www.dspace.org/], which might be an alternative.<br /><br />More at:<br />http://www.fedora-commons.org/about/features<br /><br />Fedora would be capable of handling the storage, meta-data, search and administration side of your problem. After some setup work your code would only have to 'talk' to Fedora via it's API and tell it what to do. It would require dramatically less code than building from scratch, and the end result should be much more stable, manageable and extensible long term.<br /><br />Specific to your issues, Fedora should be able to maintain the links between your analogue and digital data more easily (than say building the same thing with a relational database such as MySQL) because it would allow the construction of a custom data structure within Fedora using RDF that mirrors the structure of your analogue data. Fedora calls this it's 'Content Model Architecture'. <br /><br />It also defines relationships between data more flexibly because it can store data as triples (the subject–predicate–object structure used by RDF and the rather still-born semantic web) and searches are defined using SPARQL, which performs a similar function to SQL but is designed for searching by complex relationships. A bit like a graph database. As the actual documents can be stored in Fedora maintaining data integrity across files stored in a file system wouldn't be an issue.<br /><br />I'm sure there are also advantages in terms of data consistency checking, backup and repository restore after data corruption and a load of other stuff that I don't know about yet.<br /><br />On the other hand Fedora is non-trivial to learn (I'm only just starting), requires a good deal of custom code, and might be overkill if your needs a very simple and unlikely to need to expand further later. At least that's my take, as a prospective new recruit to the Fedora world. <br /><br />Jeremy.Anonymoushttps://www.blogger.com/profile/10057101526003231711noreply@blogger.comtag:blogger.com,1999:blog-3018115029736777901.post-81651253882567736992009-11-18T11:04:59.137+00:002009-11-18T11:04:59.137+00:00More seriously, I am curious to know what I gain u...More seriously, I am curious to know what I gain using Fedora in your outline as opposed to, say, a Web server?pixelatedpetehttps://www.blogger.com/profile/01298274275234137603noreply@blogger.comtag:blogger.com,1999:blog-3018115029736777901.post-47365400959870163462009-11-18T11:04:10.659+00:002009-11-18T11:04:10.659+00:00Substitute your language/application server of cho...Substitute your language/application server of choice in place of python/django. But you're right, this isn't a solution that's viable without writing some code somewhere along the lines as Fedora had no user interface of it's own. <br /><br />Caveat. I'm planning a similar approach on a project here in the UK in the near future, the suggested combination is based on research rather than first hand experience (yet).Anonymoushttps://www.blogger.com/profile/10057101526003231711noreply@blogger.comtag:blogger.com,1999:blog-3018115029736777901.post-76646198590927787902009-11-18T10:40:04.760+00:002009-11-18T10:40:04.760+00:00Nice idea - thanks! Was all sounding plausible unt...Nice idea - thanks! Was all sounding plausible until you mentioned Python... ;-)pixelatedpetehttps://www.blogger.com/profile/01298274275234137603noreply@blogger.comtag:blogger.com,1999:blog-3018115029736777901.post-50765226567257467312009-11-18T07:06:42.304+00:002009-11-18T07:06:42.304+00:00Convert all the born digital antique documents to ...Convert all the born digital antique documents to PDF (but keep, and serve, the originals too). Set up a server running Fedora [http://www.fedora-commons.org/] then load all you files and data into that. Build an HTTP based public API for your Fedora repository coded in Python, running on Django and serving EAD/ISAD/others wrapped in XML and supporting the functionality you need, inc. storing user contributions & feedback. Use Python/Django to then also build an XHTML wrapper around the API for your web based user interface. Publish your API. Done.Anonymoushttps://www.blogger.com/profile/10057101526003231711noreply@blogger.com