I've started this new topic to talk about the development of a Document Management System (which is NOT a Content Management System in the same sense as many people use that term). It makes a clean break from this discussion which confused a few people.
Recently we discovered OWL, which after a a cursory examination looks to me like a very good candidate for what we need. Let's play with it and talk about it.
Hi Martin!
I am still a bit confused. Do you mean to incorporate an "OWL" like system into MOODLE as one of the modules or change MOODLE into a DMS?
I look at MOODLE like I would Blackboard (http://blackboard.com). Blackboard is wildly expensive and boggy. MOODLE is free, much more responsive to instructors needs, and robust. It is also a lot of fun because of the diversity of thought that is put into it.
Could you explain more clearly what you want to do with "OWL"? It looks interesting but, I am not clear of how you want to use it with MOODLE.
WP1
A DMS is needed to replace the current "Files" tool within Moodle, so that:
There are other niceties such as WebDAV access but this list would go a long way (and OWL goes a long way towards it).
- files can be stored in the database (rather than just on disk as now)
- files can have metadata attached to them (eg keywords, description etc)
- files can be searched for text inside them, or by metadata
- files can have versions (and records of past versions)
- files can have particular authors (and perhaps multiple authors)
- files can have access controls applied to them
- files can be shared between courses
- all users can have their own online files area
- all users can have quotas applied (so students don't start MP3 archives)
- all files in a user's file area will be available for use in quizzes, forum attachments, journals, assignments, etc
There are other niceties such as WebDAV access but this list would go a long way (and OWL goes a long way towards it).
Thanks!
I understand better now.
I was just wondering is there a way to have documents uploaded and on site but not displayed for download by students until a certain date automatically? Even different dates for different courses even if the courses share a particular file or files.
Actually I am asking this about all of moodle - resources, assignments, etc. An Instructor could set up an entire couse for a semester and then just fine tune things during the semester as necessary.
Thanks again for the MOODLE program and all your good work.
WP1
Try a forum search for "rats maze" to see my reservations on the need to deliberately hide information from students trying to learn, and then look at the winning entry in this poll about "activity locking". But this is all offtopic in this topic - it's related more to module features than the DMS itself.
One more feature, please 
- (because they are stored in the database and not on disc) files can be moved around without breaking the links to them
Stencel,
You hit a right point there!
I produce a lot of documents (as a business analyst that's my main asset). I have to store them on our Windows2000 file server. But every year a new CIO, gets in and reorganizes the IT department and the whole file and folder system. My files are moved over and over again and my links get broken. I've seen that happening for the last three years.
So I've also come to the conclusion that:
- All files and documents need to be in a central database. So I can refer to one single link, that never changes.
I've look around and haven't found a system where I can upload, retrieve and do version control on my documents from a database.
It would be great. Martin, when do we start?
Runy
What you are looking for is software that does what this does.
http://www.documentlocator.com/
This software, unfortunately, is not open source but it might serve as a good guide to the features you are looking for. I've used this package it it works great. It stores all documents in an SQL database. Documents can be very large. They can have metadata attached to them. It supports versions, checkin/checkout and locking. You can control access by person or group. Documents are secure (encrypted). It supports all document types including media files. It can produce persistent URLs for access to documents. Very complete system and it works very well. Sadly, you have to pay for it but it might be a good template for something open source.
tanxs
I think I'll have to start integrate new HTMLArea editor version, that supports fullpage editing (it could be also possible to add some document teplates as well?).
Couple of not so nice things to solve:
- Fullpage is a plugin
- Spellchecking is a plugin
How do we enable these plugins? Load them every time when editor loads or do something else. I have tried to enable plugins on editors fullmode, but without success (they really are plugins).
- Janne -
Fullpage means the whole html -page, from tags <html> to </html>.
In this basic mode editor strips out the heading part and end tags (</body>, </html>).
So this could be a useful plugin if those CMS and DMS features are included someday.
- Janne -
I see. You meant using the editor to create files in the DMS, and not only editing textareas. That would be great.
Certainly, no problem - it's just another file.
Martin,
There is a small debate, or issue at my institution about the type of server used for resource files. There is a mass storage server with mulitasking capability especially for serving video and audio files to a large number of students. However, these multitasking servers are not appropriate for running server side applications.
Here I have a question... if or when Moodle has a DMS will it be able to access files that are on a different server?
I get that feeling that when the gods put into practice the mutil-media handling features for the quiz, that may or may not be in the pipeline, these features will be effected through the use of a more advance DMS. Since I would like to be able to have quizess with say 10 or 20 audio files and not have to do that by making a lot of links to external URLS, I would very much like to know the direction or envisaged capabilities of the DMS to be.
Finally, have you any idea at all when the DMS might be put into practice?
Tim
Timothy Takemoto
Since the files will be stored in a database, yes, you can put the database on another server (though this means the data would still be coming through Moodle itself).
Note that even in Moodle today it's quite easy to browse foreign sites to find a URL, and then put that URL in a resource. In fact, there is even a site-wide resource config setting where you can set the "start page" to make it easier on teachers doing this. If you have a need for specialised servers (eg streaming media) then you should keep the data on those servers and use it this way.
Lastly, it would be a good idea to make it possible to add a resource in the DMS which is simply an external URL (eg like a bookmark)... once these were set up the DMS could be used to find/use external resources.
Dates? When it's ready.
Note that even in Moodle today it's quite easy to browse foreign sites to find a URL, and then put that URL in a resource. In fact, there is even a site-wide resource config setting where you can set the "start page" to make it easier on teachers doing this. If you have a need for specialised servers (eg streaming media) then you should keep the data on those servers and use it this way.
Lastly, it would be a good idea to make it possible to add a resource in the DMS which is simply an external URL (eg like a bookmark)... once these were set up the DMS could be used to find/use external resources.
Dates? When it's ready.
I still hope that we end up with a CMS whereMoodle can put the structure of educational material: lots of researchrs are looknig for learning objects.Most of them say that differnce between a reusable object is that a learning object is richer:
It is a molecule build from the atoms resource(s) + task(s) + scale(s). Some of activities in Moodle are combinations of tasks and scales, in the future more will combine this?
On a section you compose your learning objects:
The ideal CMS for a Moodle user would be a system that:
- can store separate sections. (A modified backup could facilitate that?)
- can store the components separate
- can import IMS content packages and store them in a section structure
- (Where go the IMS/QTI quizzes?)
I have the feeling, Martin that you are very close to the "CMS for the ordinary man in the classroom": elegant, simple, and free.. (XML in Backup must be the swiss-knife for this)
If OWL can serve this, great. The other use of OWL could be to create the workspaces for students with a good rights structure.
(My other candidate is typo3, just because we use it for our schoolwebsite, but it seems a little overkill.)
This is a much needed service and I am pleased that Moodle is looking at this.
For a while now I have needed to better manage the files we make available to students. I would like to add to Martin's excellent list of what a DMS might do:
For a while now I have needed to better manage the files we make available to students. I would like to add to Martin's excellent list of what a DMS might do:
- files can be given an expiry date (or infinity) so that they are automatically made 'not available' at a future date.
- files can have metadata attached to them (eg keywords, description, owner, purpose etc)
- all users can have their own online files area (please include group level ownership so that students collaborating on a project can have a secure files area).
- a front page block for listing 'student project areas' by name to provide a shortcut to the files area. Maybe this list could be like the 'Upcoming Events" list and provide a brief introduction to each project.
- searching and indexing facilities to eliminate or minimise duplicate files across courses (particularly where files have the same owner).
Use OWL into Moodle will be possible someday?
Best Reggards.
Jose - I am not familiar with OWL; however, if they have an API that Moodle can make use of it seems good to develop a plugin for OWL to take advantage of the Moodle 2.0 repository API. You may want to have a look at MDL-16543 and then consider adding a task to that issue for an OWL plugin. I took a quick look at OWL and it did mention WebDav which already has a plugin developed for Moodle 2.0. Let me know if you have any questions. Peace - Anthony
Hi Anthony.
I have a limitation with Moodle File Manager, so, I have installed many others Documents Repositories, I use the Door plugin for mdl, etc. to solv it.
5 years ago Martin D posted about OWL, this is the reason for use Owl, I think it's fantastic.
Do you know about posibilities of new File Manager or Repository API for MDL 2.0...
...and do you know when the 2.0 version will be a stable build?
Thanks a lot. Best Reggards.
Jose - I know that most of the work on the file repository for 2.0 has been done and is functional. Some work remains on cleaning up specific plugins for specific services. As for when Moodle 2.0 will be ready I would not even venture a guess at this point. The best I can say is when it is ready. I would hope before January 2010 but there are no guarantees. Peace - Anthony
Ah, found you my preciousss!!
MyDMS: http://dms.markuswestphal.de/about.html
PHP bing!
AdoDB, bing!
Languages, bing!
Templates, bing!
Metadata, bing!
Versions, bing!
Clean-looking, well-written code, bing bing!
MyDMS: http://dms.markuswestphal.de/about.html
PHP bing!
AdoDB, bing!
Languages, bing!
Templates, bing!
Metadata, bing!
Versions, bing!
Clean-looking, well-written code, bing bing!
Smeagol?
found you my preciousss!!
------------------------------------
Sparkles quite a bit too! Waves to come.
---Dave
That looks *Niiiiice*!
Integrated into moodle it would be awesome. Especially if you could also use it as a module in topics. Say define a sub-tree of the structure as a library for a certain course...
Oxford Beardie
Integrated into moodle it would be awesome. Especially if you could also use it as a module in topics. Say define a sub-tree of the structure as a library for a certain course...
Oxford Beardie
Yes, it wouldn't be hard to just have a new type of resource called Directory or Library that allowed this ... in fact that wouldn't be too hard even now.
STOP COMING UP WITH COOL IDEAS DAMMIT!
STOP COMING UP WITH COOL IDEAS DAMMIT!
Ooops...sorry Mate
Oxford Beardie
Oxford Beardie
Ya gotta admit...it IS a cool idea. Especially given that using that kind of system, you could share files between courses instead of having duplicate copies of needed files in each course's subfolders...
This looks really good!
I like the versioning and the related documents features. I have to look and see how the protection works - who can update; who can't.
mike
This is just way to AWESOME! Somebody send the replicator to Perth.
AdoDB, bing!
Languages, bing!
Templates, bing!
Metadata, bing!
Versions, bing!
Clean-looking, well-written code, bing bing!
Bomb, INcredible and Great.
Languages, bing!
Templates, bing!
Metadata, bing!
Versions, bing!
Clean-looking, well-written code, bing bing!
Bomb, INcredible and Great.
YES!
Adios, Windows Explorer! All my precious documents will now be organized!
Sorry if I have missed this... Is it possible that students will be able to store documents in this DMS, too?
-- Art Lader
-- Art Lader
Not tried it yet, but I think you can give various types of access - so yes, if I understand correctly, they could. It's a job for me in the summer at our establishment.
Yes, student files is one of the main reasons for this system.
Sigh... Don't know how I missed that. 
Well, Moodle is already great, but it looks like it's just going to get better and better and better and better. Frankly, I have never seen anything like this before. I am amazed.
-- Art Lader
Well, Moodle is already great, but it looks like it's just going to get better and better and better and better. Frankly, I have never seen anything like this before. I am amazed.
-- Art Lader
Yes. it will get better.
I took a look at MyDMS. And someone in their forum, said that if you use WebDav (= a protocol to be able to write files on an internet server), you could possibly in the future also edit the files. So not only download files from MyDMS but als directly write files. You don't need to upload a file anymore and students all over the world could not only be sharing files but also working together on files and projects. This is of course future stuff, but I'm exited.
Runy
link to benefits of webdav protocol combined with mydms.
So, have you put any effort into integrating it in?
I've taken some first steps at putting it in. Here are the problem areas I see:
- Database calls are coded throughout the application. This will take time to recode.
- Relies on 'register_globals = on'. I've started to fix these, and placed a hack to 'extract' the _POST, _GET and _FILES arrays.
- Uses '<?' and '<?=' instead of '<?php' and '<?php echo'. Again, I've searched and replaced all (I think) of these.
- Uses its own authorization database. This should be fairly easy to switch to Moodle's.
- Uses groups to define access rights. Moodle doesn't. This is the biggest design issue. We need to figure out how to merge rights management from Moodle to MyDMS.
The system doesn't seem to be actively developed any more, so I don't think we need to worry about missing any updates if we rewrite the code.
I'm assuming the goal would be to replace 'file.php' and the 'files' functions with this? If so, we would need to keep some of the 'files' system functions (backup, restore, zip/unzip) that aren't part of MyDMS.
Thoughts anyone?
mike
Mike,
If you pull this off you're in for a really tall Moodle hat, drinks on the house and legendary wonk status (IMHO). I talked with Martin about this last week in New York, mentioning that MyDMS seems to have been abandoned. So, finders keepers.......
Bryan
The DMS is one of the coolest additions to Moodle that are being discussed, IMO. Packed full of more features that we 'll ever need. The fun thing is that (as with the calendar), I 'll have to DO something like that for the institution that employs me anyway in the next couple of months; it's part of my work.
So, Mike, are you going to continue on this? And if yes, do you think you could use some help?
So, Mike, are you going to continue on this? And if yes, do you think you could use some help?
Seems like your development inspirations come from the same place as mine - people screaming at the door! 
I am going to continue, and I'm sure I will need help. Let me get it organized and then I'll pull you in.
But first, Martin, is this worth our efforts? Do you want this in the Moodle core?
One thing we really have to decide is on groups (not cohort groups; but organizational). The MyDMS really needs it, and I know it could be used elsewhere. We could hack our way around it in the MyDMS core, (like I had to with the questionnaire), but I'd really rather not. Do you think we could spec out the basic structure of groups, and use them as necessary?
mike
Of course, yes, I definitely want this in the core! 
The DMS is very important and so not to be rushed. I'm really glad you, Mike, and Jon feel you have some time to help integrate it. I was planning to to do it myself, but I have a full plate for the next six months or so with 1.3 and then the 2.0 restructuring.
I'd really like to be involved in this, and I'd really like to see a clean implementation that uses all the Moodle core libraries. I haven't looked into the "groups" stuff in MyDMS yet but I had two vague ideas for how it would work with Moodle
a) work with the existing groups stuff just added in Moodle 1.2
b) link with the upcoming Roles stuff (and for this I've been thinking about Xaraya's model)
The DMS is very important and so not to be rushed. I'm really glad you, Mike, and Jon feel you have some time to help integrate it. I was planning to to do it myself, but I have a full plate for the next six months or so with 1.3 and then the 2.0 restructuring.
I'd really like to be involved in this, and I'd really like to see a clean implementation that uses all the Moodle core libraries. I haven't looked into the "groups" stuff in MyDMS yet but I had two vague ideas for how it would work with Moodle
a) work with the existing groups stuff just added in Moodle 1.2
b) link with the upcoming Roles stuff (and for this I've been thinking about Xaraya's model)
Well, let me start it anyway. First pass, I want to go through and replace the authorization and database code. Then we've got something we can work with.
Using 1.2 groups will only help for student files as they pertain to a particular course/group, so that's only a small part of the solution.
However! Using roles as in Xaraya is the way I would like to go. I really like Xaraya's groups model as well.
mike
Excellent - sounds like a plan!
I realise more and more that "sidewide" roles - like isteacher() and multigroup-membership are more and more important to tune the system for a local situation, so please go on with it.
.....and all Moodledom held its breath as the king layed his sword on the shoulders of two new knights! Sir Jon and Sir Mike, stand up and go forth with Sir Eloy and others to fight the just battle.
Anyone care to save me some time and tell me what Xaraya is, and what Roles are and how they work? Any links I can go to and educate myself, or better yet, a functional demo installation?
Mike: since we have the green light, I 'm going to make an installation of MyDMS and start learning it. Awaiting instructions!
Martin: Would it be possible for us to use the CVS for this?
Jon
Xaraya is a PostNuke fork, that redesigned from the bottom up. They spent a lot of their efforts on categorization, user/group management and blocks and hooks. Its a very good re-write.
Find it at Xaraya.com.
mike
Mike,
Thanks for the explanation of Xayara.
Sorry to mention Portals again here, but this excellent site lets you compare them, including Typo3, Postnuke, and Xaraya. Drupal may also count as a DMS-CMS, and it has good vowel sounds*. Owl is there too, but Midgard is not there, and MyDMS does not get a mention.
It is only Typo 3, Xaraya ,and Postnuke that seem to be mentioned as DMS-CMS on this thread (by a Xaraya-ite, perhaps) and the latter, Xayara, comes out on top for persuasive reasons.
From a user point of view, Xaraya seems to be... not the most user-friendly. I find that my browser crashes when I open it in three window, the point size is tiny, I can't find the forums or any documentation about Xaraya is, other than something really small at the top. It is probably hot when it comes to the design.
Tim
takemoto
*Winnng Net names often included the "oo" sounds. (Yahoo, Google, Dupal, Movable Type...)
Absolutely, both of you already have full privs to cvs:/contrib so perhaps Mike wants to go ahead with a cvs:/contrib/dms
I had an interesting meeting with a group of Xaraya programmers via IRC sometime in January ... they are looking at including Moodle as a module within Xaraya so we talked about common points of development.
I had an interesting meeting with a group of Xaraya programmers via IRC sometime in January ... they are looking at including Moodle as a module within Xaraya so we talked about common points of development.
As we are in active evaluation and development in Moodle, I'd like to help too. I'm especially interesting in incorporating webdav functionality and an interface to add new content directly with the HTMLEditor widget.
But I'd like to start by taking direction from more advanced Moodlers.
Jason
Jason R. Cole, Ph.D.
Academic Technology Manager
The Center for the Enhancement of Teaching
San Francisco State University
But I'd like to start by taking direction from more advanced Moodlers.
Jason
Jason R. Cole, Ph.D.
Academic Technology Manager
The Center for the Enhancement of Teaching
San Francisco State University
I'll upload a working version of MyDMS into CVS later today. Changing the database code has been a bigger task then I originally planned. The existing code seems to rely on warnings not being thrown, and I'm not a fan of that.
When I upload, I'll start a new discussion.
mike
Hi Mike,
So, what ever happened to My 'precious' DMS?
It seems to have vanished from the face of the earth and now the talk of the town is Hive. Really cool, really expen$ive.
Hi!
I've been reading for a while the posts on the DMS project! Very Interesting!
I understand that the files will be attach to the user instead of the course so that we could use the same file in many courses.
But, how will it work if there is 2 teachers for one course? Will they share a "common" space for the course so they have both access to the files?
... just a thought...
I've been reading for a while the posts on the DMS project! Very Interesting!
I understand that the files will be attach to the user instead of the course so that we could use the same file in many courses.
But, how will it work if there is 2 teachers for one course? Will they share a "common" space for the course so they have both access to the files?
... just a thought...
Hi all,
I'm really looking forward to this new DMS.
One Don't really know it this is the right place to put this, but here it comes:
When you moodle file collection grows, it becomes quit difficult to find the right files, and most of the times you will not find interesting new files just by browsing the repository.
Where I am going to is the following: Add a dynamic 2D or even 3D navigation structure, based on file content.
Have a look at the following:
--------
http://mmtech.pentech.ac.za/knowledgeTree
username: guest
password: guest
go to any of the documents in the repository and use the button "View Link Map" at the left of your screen.
-----------
The repository you see, now contains a couple of documents and fake metadata, but will be used for documents that are used during research.
When doing research, it is often quit difficult to see relations between document.
In KnowledgeTree the option existed of linking documents together, but there was no good way of visualizing these links between the documents.
(By the way, when you double click on a node in the link map, you will go to that particular document in KnowledgeTree)
Research includes finding links between documents. Lets take 10 research papers and the resources they cited and upload all these documents into the repository.
If there where links between the research papers and their resources, you could use the "link map" to visualize what papers cite the same resources. And that is only one dimension deep.
If you would insert all the material cited by the resources of the first 10 papers, in other words you would upload a third 'level', you would probably see that there are document that are cited a lot while others are only cited once. You can see this because some documents have a lot of links to other documents while others have only one link. And this is where the power of this tools comes in. It enables you to visualize links between a large group of document, and identifies the more important once.
What I want to say is, is it maybe possible to include such link creation in the DMS or should we rather make a separate module that creates links and visualises those links.
I really think that this could help students in finding new and interesting documents.
At this moment, the linking is all manual. But I hope that in the future, the server can link documents together based on keywords or mandatory meta-data, or even on content. Than a tool like this would come in handy when browsing through a large collection of documents.
If there are people that want to discus this in a private email discussion, you are welkom, and if you feel that it is Moodle worthy, than lets create a new discussion for this.
(by the way, the JavaApplet (TouchGraph) is completely open source, so is KnowledgeTree)
I'm really looking forward to this new DMS.
One Don't really know it this is the right place to put this, but here it comes:
When you moodle file collection grows, it becomes quit difficult to find the right files, and most of the times you will not find interesting new files just by browsing the repository.
Where I am going to is the following: Add a dynamic 2D or even 3D navigation structure, based on file content.
Have a look at the following:
--------
http://mmtech.pentech.ac.za/knowledgeTree
username: guest
password: guest
go to any of the documents in the repository and use the button "View Link Map" at the left of your screen.
-----------
The repository you see, now contains a couple of documents and fake metadata, but will be used for documents that are used during research.
When doing research, it is often quit difficult to see relations between document.
In KnowledgeTree the option existed of linking documents together, but there was no good way of visualizing these links between the documents.
(By the way, when you double click on a node in the link map, you will go to that particular document in KnowledgeTree)
Research includes finding links between documents. Lets take 10 research papers and the resources they cited and upload all these documents into the repository.
If there where links between the research papers and their resources, you could use the "link map" to visualize what papers cite the same resources. And that is only one dimension deep.
If you would insert all the material cited by the resources of the first 10 papers, in other words you would upload a third 'level', you would probably see that there are document that are cited a lot while others are only cited once. You can see this because some documents have a lot of links to other documents while others have only one link. And this is where the power of this tools comes in. It enables you to visualize links between a large group of document, and identifies the more important once.
What I want to say is, is it maybe possible to include such link creation in the DMS or should we rather make a separate module that creates links and visualises those links.
I really think that this could help students in finding new and interesting documents.
At this moment, the linking is all manual. But I hope that in the future, the server can link documents together based on keywords or mandatory meta-data, or even on content. Than a tool like this would come in handy when browsing through a large collection of documents.
If there are people that want to discus this in a private email discussion, you are welkom, and if you feel that it is Moodle worthy, than lets create a new discussion for this.
(by the way, the JavaApplet (TouchGraph) is completely open source, so is KnowledgeTree)
I couldn't find the "View Link Map" button anywhere.
Hi,
At the recient Moodlemoot '05, Harvest road hive was mentioned as an integrated DMS, We (Northumbria Learning) are working with Harvest road and have seen the interface and are working with them (one of our ex-employees now works for them). Given that the Moodle community has talked about OWl and MyDMS for integration and now a commercial DMS (Hive) has come into the picture. What does anyone think would be the best way forward. Should we have both commercial and opensource systems integrated or should Moodle be absorbing an opensource DMS into its core or both?
At the recient Moodlemoot '05, Harvest road hive was mentioned as an integrated DMS, We (Northumbria Learning) are working with Harvest road and have seen the interface and are working with them (one of our ex-employees now works for them). Given that the Moodle community has talked about OWl and MyDMS for integration and now a commercial DMS (Hive) has come into the picture. What does anyone think would be the best way forward. Should we have both commercial and opensource systems integrated or should Moodle be absorbing an opensource DMS into its core or both?
All of the above.
Obviously integrating open-source repositories makes sense for Moodle, being an open source project. However, Hive is available right now and is way ahead in terms of stability and features than any open source solution I've seen. Larger institutions, companies and government implementations of Moodle that need something now will want to use something like Hive to store and manage critical documents.
Moodle 1.6 (and specially patched versions of 1.5) will have a plugin system for repositories, allowing us to incorporate all kinds of repositories in future, with controls so that the Moodle Admin can choose what appears where. The integration is quite seamless so that it appears that you never leave Moodle.
I think this approach of keeping the DMS layer semi-separate from Moodle is the best approach that allows us great flexibility.
Obviously integrating open-source repositories makes sense for Moodle, being an open source project. However, Hive is available right now and is way ahead in terms of stability and features than any open source solution I've seen. Larger institutions, companies and government implementations of Moodle that need something now will want to use something like Hive to store and manage critical documents.
Moodle 1.6 (and specially patched versions of 1.5) will have a plugin system for repositories, allowing us to incorporate all kinds of repositories in future, with controls so that the Moodle Admin can choose what appears where. The integration is quite seamless so that it appears that you never leave Moodle.
I think this approach of keeping the DMS layer semi-separate from Moodle is the best approach that allows us great flexibility.
In my opinion.....
The open source community should be developing and incorporating open source systems into its products. I see no problem with commercial vendors making their products integrate with open source systems, but when the open source community starts driving that development then you start down a very slippery slope.
Picture this.....
Last year, you argued for your institution to change from Blackboard to Moodle and used cost as a major selling point.....you were successful in the face of a lot of skeptics about open source....your institution is now happily Moodeling along....someone asks for DMS capabilities (like Blackboard now has)....now you have to tell them that yes, Moodle does have this capability, but it's going to cost and it's not cheap.
I wouldn't want to be the person who convinced the institution to switch.
Having said that, I'm not trying to convince any organization to change from a commercial LMS to Moodle. Also, I'm very happy with the features available in Moodle as it exists today and everything I'm deploying Moodle to do will function fine for years to come with the existing "open source" features, so even if all future development moves toward commercial features (which I'm confident won't happen), I'll be happy for years to come.
Now, before anyone lashes out at me for simply typing what many are already thinking please don't take this view as negative toward anyone or anything about Moodle...this is a great piece of software developed by a great community of volunteers and I'm sure it will stay that way for a long time. This is just a surprising development...at least for me.
Steve
Just to make it very clear, I said "all of the above" above. Options options options.
Anyone who wishes to help integrate open-source repositories into Moodle just needs to contact me!
Anyone who wishes to help integrate open-source repositories into Moodle just needs to contact me!
Hi Martin,
please have a look on odalis . Here (http://dialoge.net/pdf/moodle-repository.pdf) is a german document with a first easy moodle integration with some screenshots.
What is odalis? odalis is an portal framework, including a CMS and a very good search machine for files, including metadata. Files are stored in a central repository. It has a full text indexing process and a fast search function for metadata, authors, summaries and full text. With an included free thesaurus intelligent search functions are possible.
The search function works also in big systems with terrabytes of data. Several odalis server can work together.
A very good function are the small indexing tools on the clients PC's. It analyses the files in defined folders and transfers new and changed files to the server for indexing. So it is possible that trainer have folder on their home PC with data for the repository. changes are automaticly transfered to the repository. Versioning ist possible. Alternative is an individual upload of files to the repository.
The rights management can be defined for persons and groups. Existing right management definition from the network can be used.
Odalis has his own user registration process and rights management, but it can use also external databases. It works with PHP and MySQL.
I think it is possible to combine moodle and odalis easily. Perhaps it is possible to use the rights management of odalis complete in moodle.
A Demo of odalis is here.
Odalis download Page. Odalis is under LGPL licence.
please have a look on odalis . Here (http://dialoge.net/pdf/moodle-repository.pdf) is a german document with a first easy moodle integration with some screenshots.
What is odalis? odalis is an portal framework, including a CMS and a very good search machine for files, including metadata. Files are stored in a central repository. It has a full text indexing process and a fast search function for metadata, authors, summaries and full text. With an included free thesaurus intelligent search functions are possible.
The search function works also in big systems with terrabytes of data. Several odalis server can work together.
A very good function are the small indexing tools on the clients PC's. It analyses the files in defined folders and transfers new and changed files to the server for indexing. So it is possible that trainer have folder on their home PC with data for the repository. changes are automaticly transfered to the repository. Versioning ist possible. Alternative is an individual upload of files to the repository.
The rights management can be defined for persons and groups. Existing right management definition from the network can be used.
Odalis has his own user registration process and rights management, but it can use also external databases. It works with PHP and MySQL.
I think it is possible to combine moodle and odalis easily. Perhaps it is possible to use the rights management of odalis complete in moodle.
A Demo of odalis is here.
Odalis download Page. Odalis is under LGPL licence.
Und jetzt?
Any feedback on your suggestion Ralf?
I noticed we're getting Blogs in Moodle 1.6.
"Integration with some repositories " is slated for v. 1.7.
That's really a pitty.
Hi Scott,
the developers of odalis are interested in an integration of odalis and moodle.
If we find some sponsors they will beginn with it. Are you interested, contiact me via email.
Ralf
the developers of odalis are interested in an integration of odalis and moodle.
If we find some sponsors they will beginn with it. Are you interested, contiact me via email.
Ralf
Hi, Ralf!
I think odalis looks great. The distributed storage is one of the features I'm looking for.
Do you think I can find a demo site in English?
Do you know of anyone who is making an effort to integrate this to Moodle?
TIA,
Pablo
I think odalis looks great. The distributed storage is one of the features I'm looking for.
Do you think I can find a demo site in English?
Do you know of anyone who is making an effort to integrate this to Moodle?
TIA,
Pablo
Hi Pablo,
we are searching for funding the integration. Are you able to help?
Some english informations are on http://odls.net.
Ralf
we are searching for funding the integration. Are you able to help?
Some english informations are on http://odls.net.
Ralf
Hi Pablo
here is a demo of odalis with some informations for an english surface
http://try.odalis.net/index.php?odalis=odalis
Login with demo demo
Add an '&lang=en' to the url: http://try.odalis.net/page.php?&lang=en
No you can see english menus.
Under "Dokumentenablage" you find uploaded und indexed documents.
At "Suche" you can use the expert searching functions.
English informations about odalis on http://odls.net
here is a demo of odalis with some informations for an english surface
http://try.odalis.net/index.php?odalis=odalis
Login with demo demo
Add an '&lang=en' to the url: http://try.odalis.net/page.php?&lang=en
No you can see english menus.
Under "Dokumentenablage" you find uploaded und indexed documents.
At "Suche" you can use the expert searching functions.
English informations about odalis on http://odls.net
Hi, All!
What you can say about edukalibre (www.edukalibre.org) software as repository for Moodle? There are some examples with interconnection edukalibre-moodle.
Hi it is an increasing area of interest that users have their own files area and the DMS sounds very interesting indeed! Do you know when it is likley to become a reality for the standard Moodle distribution?
I was thinking that if is is a long way off would it be possible for someone over at moodle or one of the associated developers to use the existing files code and map this for each user to a folder within the users current folder where their profile images are stored?
If it is a long way of i am tempted to have a go at doing this myself to our current installation of 1.5.2. (yes i know ive not done the security upgrade to 1.5.3 yet but will be doing so next week).
Many thanks and keep up all this good work!! Ben
Hi Ben, you might try the MyFiles filemanager block we're working on, it gives each student/teacher his/her own file space.
http://cdc.humboldt.edu/moodle/course/view.php?id=3&topic=1%20alt=Blocks
If you feel like coding, some things that we have on the roadmap for filemanagner:
Integration with the html editor
integration (send file to) assignment
versioning
metadata search
WebDAV support
Some more thoughts for possible future developments Michael:
Many UK schools are now needing a facility for students to prepare an eportfolio - ie, a collection of files within a directory structure, which may or may not also contain a web site. To ease this process, it would be very useful if we could have:
- A facility to upload a whole folder structure at once; maybe using a hidden zip-upload-unzip routine? I'm no developer
- The ability for the teacher to share the documents for a whole group with the same password. This would be so that those students would have their files available to view by an examiner or employer.
Thanks for your work on this Michael, it's the hound's rounds
What's the timeline for the roadmap? We're busy preparing for the virtual flu around here and the more tools for remote education we have at our disposal, the better.
Hello Michael, many thanks for usch a quick response, this looks just what i am after, does the file_manager folder just need dropping into the blocks folder and then admin access will carry out the install? We havent done the 1.5.3 upgrade yet does this need doing before hand?
Regards, ben
Hello Michael & every body,
I practice Problem Based Learning with groups of 6 students each. I'm just beginning using Moodle for its communication facilities.
Because they exchange files and build others in collaborative manner, it would be very nice to have DMS facilies for each group :
- first : one collaborative space for each group : collaborative use of files, depose and retire files
- later : collaborative building (wevdav functionalities )
Are there other experiences in this way, can somebody return some knowledge about tools discussed before on this forum (MyDMS, myfile or other), intregrated in Moodle or separatly ?
What's the curent Moodle DMS block project state today ?
Thank you for answers.
Regards.
Daniel.
I practice Problem Based Learning with groups of 6 students each. I'm just beginning using Moodle for its communication facilities.
Because they exchange files and build others in collaborative manner, it would be very nice to have DMS facilies for each group :
- first : one collaborative space for each group : collaborative use of files, depose and retire files
- later : collaborative building (wevdav functionalities )
Are there other experiences in this way, can somebody return some knowledge about tools discussed before on this forum (MyDMS, myfile or other), intregrated in Moodle or separatly ?
What's the curent Moodle DMS block project state today ?
Thank you for answers.
Regards.
Daniel.
Hi, Michael!
I previously had some problems downloading your block (the ZIP had just the lang files) but now it worked great and I found it to be an excellent feature!!
One thought to add to the many posted here: the addition of categories is a great feature, since it lets you organize your stuff in a way more independent from the traditional computer-based directory tree. I'd love to see a further step in this block, allowing multiple categories to be assigned. There are many examples of these usage (Wiki being the major one) and proves to be extremely useful.
Suppose your work on a pizzeria. So, a folder called "pizza" could be categorized as "food" but also as "work" and both of them would be as important.
Cheers,
Pablo
I previously had some problems downloading your block (the ZIP had just the lang files) but now it worked great and I found it to be an excellent feature!!
One thought to add to the many posted here: the addition of categories is a great feature, since it lets you organize your stuff in a way more independent from the traditional computer-based directory tree. I'd love to see a further step in this block, allowing multiple categories to be assigned. There are many examples of these usage (Wiki being the major one) and proves to be extremely useful.
Suppose your work on a pizzeria. So, a folder called "pizza" could be categorized as "food" but also as "work" and both of them would be as important.
Cheers,
Pablo
So I presume MyDMS is the contrib/dms module currently available. What is the status of this project now?
I need a DMS with full access controls within the next month or two, and if this module is the up-and-coming DMS with pending official approval and inclusion in the main trunk I'd like to try to move it forward if I may.
As far as I can tell, at this point it has access controls roughly like those of traditional UNIX, with read/write/admin for "owner" and "others". I've implemented an access_control module (currently under contrib/portfolio/contrib/access_control) that I believe we could use to provide full ACLs to MyDMS in relatively short order.
What is the current plan with regard to beefing up the access controls here? Am I stepping on somebody's toes, or doing needless work? Shall I just start coding, and see where it leads us?
I see the strong cautions in the README.1ST file; what all needs to happen to mature this module so that these warnings can go away? Here are some things that I see (based on a very quick and cursory glance):
I need a DMS with full access controls within the next month or two, and if this module is the up-and-coming DMS with pending official approval and inclusion in the main trunk I'd like to try to move it forward if I may.
As far as I can tell, at this point it has access controls roughly like those of traditional UNIX, with read/write/admin for "owner" and "others". I've implemented an access_control module (currently under contrib/portfolio/contrib/access_control) that I believe we could use to provide full ACLs to MyDMS in relatively short order.
What is the current plan with regard to beefing up the access controls here? Am I stepping on somebody's toes, or doing needless work? Shall I just start coding, and see where it leads us?
I see the strong cautions in the README.1ST file; what all needs to happen to mature this module so that these warnings can go away? Here are some things that I see (based on a very quick and cursory glance):
- create mysql.sql and postgres7.sql files like normal Moodle modules use
- start using core Moodle APIs instead of digging around in $_REQUEST and so forth
- complete ACLish access controls
This thread is over two years old I dont think the DMS in contrib is going to ever become mainstream.
I'll be discussing the new repository API at the upcoming Developer's meeting on Friday.
Basically we'll have an API that interfaces Moodle files handling everywhere via a plugin to the chosen repository (or repositories). This allows us to use all the great repositories are around without needing to restrict ourselves to just one.
I'll be discussing the new repository API at the upcoming Developer's meeting on Friday.
Basically we'll have an API that interfaces Moodle files handling everywhere via a plugin to the chosen repository (or repositories). This allows us to use all the great repositories are around without needing to restrict ourselves to just one.
Hi Martin, can I ask how the repository will be integrated between courses? One of the main requests I've had is that teachers of the same department can share the same resources but link to them within their seperate courses.
For example, the English department might have a PDF file within a "repository" course that they want to be available to all students. Teacher A, from Course A, places this resource within a discussion topic. Teacher B, from Course B, places the SAME resource within a different topic. They are using the same source file, but publishing it in different ways. It saves having to download files from the teacher repository and re-upload to a seperate course all within Moodle.
Hope this makes sense
For example, the English department might have a PDF file within a "repository" course that they want to be available to all students. Teacher A, from Course A, places this resource within a discussion topic. Teacher B, from Course B, places the SAME resource within a different topic. They are using the same source file, but publishing it in different ways. It saves having to download files from the teacher repository and re-upload to a seperate course all within Moodle.
Hope this makes sense
This is exactly what we are waiting for the last two years: several teachers using the same big file, without replicating it for student views/rights.
.
The other big archive wish is the option to store and retrieve a complete course section including all the resources and activities in that section: it would boost the reuse of course designs.
.
File storing in a e-portfolio context is a complete different sport: it should follow the upcoming (exchange) standards for e-portfolio.
I fully agree with you, Ger! The section retrieval feature should exist, same for the separation between portfolio and DMS. Maybe we should state this clearly in another place (new docs.moodle? glossary term?).
Anyway, I'm waiting for Friday's meeting but I think there is one approach that is the more supported by the community, I'll write it down to try clarifying it to myself, just the skeleton of it to keep it simple.
In short, this DMS should be composed of:
Any comments?
Cheers,
Pablo
Anyway, I'm waiting for Friday's meeting but I think there is one approach that is the more supported by the community, I'll write it down to try clarifying it to myself, just the skeleton of it to keep it simple.
In short, this DMS should be composed of:
- A local Access Control List which might have some impact on Moodle's Administrator/Editing teacher/Nonediting teacher/Student profiles.
This ACL should have:- a mapping table which assigned a local resource to a remote one;
- assigned permissions;
- a table for each DMS with a map between Moodle's profiles and permissions and the DMS's ones.
- Some local metadata, the minimum possible amount of it, leaving the rest to the DMS.
- A remote DMS. I have found these to be interesting candidates. Of course, ther should be one plugin for each of them, but I think we should order them in some way. There is one of them that will shortly be available (Hive) since Martin is working on it right now.
Maybe I should've put this table in Moodle DOCs, to make it easily modifiable...Hive EPrints Edukalibre Odalis myDMS DSpace DB used Language PHP Permission structure Workflow Flexible metadata Support Languages Yes Version control Yes Yes Templates Yes Integrate 
- DB Used: every supported database
- Language: programming language used.
- Permission structure: refers to the profiles and ACLs internally used
- Workflow: does it allow workflow mode? Can I have authors separated from Editors, Publishers, Readers, etc?
- Flexible metadata: can the metadata structure be modified? Does it adhere to any standard (IMS, Dublin Core...)?
- Support: what's the size of the supporting community? Is it composed by multi-country/multi-language people? Do they answer??
- Languages: does it supporte multiple languages? Can it be easily extended? Does it comply any standard?
- Version control: is it supported?
- Templates: does it have multiple templates for the frontend design?
- Integrate: can we use the same Moodle's directory structure to put the whole DMS's code? (Useful for small hosted sites and to share config files)
Any comments?
Cheers,
Pablo
HI Pablo,
I think I agree with you on most of this. Here's some shameless self-promotion: the new generic access_control module under contrib/portfolio/contrib might be quite a bit of the ACL work that we need. (It's not tied to the portfolio module, it just lives in a subdirectory right now.)
With that said, I don't think the ACL should necessarily have any knowledge of the mapping between Moodle's DMS perspective and the remote DMS system's perspective. Doesn't that belong in a Moodle-DMS-plugin table of some sort?
But as you said, tomorrow's meeting will clear some more of this up.
I think I agree with you on most of this. Here's some shameless self-promotion: the new generic access_control module under contrib/portfolio/contrib might be quite a bit of the ACL work that we need. (It's not tied to the portfolio module, it just lives in a subdirectory right now.)
With that said, I don't think the ACL should necessarily have any knowledge of the mapping between Moodle's DMS perspective and the remote DMS system's perspective. Doesn't that belong in a Moodle-DMS-plugin table of some sort?
But as you said, tomorrow's meeting will clear some more of this up.
Hi, Matt:
From the amount of your postings in the last week, I can agree with the shameless point
Regarding the other point... I fully agree, that was my mistake. Should definitely be separated.
Till tomorrow!!!
From the amount of your postings in the last week, I can agree with the shameless point
Regarding the other point... I fully agree, that was my mistake. Should definitely be separated.
Till tomorrow!!!
Heh. 
I mention "shameless self-promo" to put a humorous face on my insistent pushing for people to be looking seriously at ACLs and DMSes. It really isn't self-promotion, though. I don't care if my code gets thrown out as long as Moodle ends up with ACLs at least as powerful as the access_control module, which I consider to be a minimally-adequate first step.
I implemented that module because I needed it right now, which is also how soon I need basic DMS functionality.
I'm excited to see how the meeting goes tomorrow, and since I have funding to be working on this I hope that some of my time in the next couple of weeks can be spent working on real, useful specs and code for Moodle's DMS-plugins architecture. But in any case, I will have to have basic, functioning DMS APIs available to the portfolio module by March, and if I have to implement some (more?) throwaway code to do that, then I guess I will.
I find myself in the role here of being an interested and highly motivated newbie-Moodledev, and I need functionality right now that Moodle will probably have within six months to a year. So I'm doing my best to make good contributions and point to them as examples, even if not as direct paths to final solutions.
I mention "shameless self-promo" to put a humorous face on my insistent pushing for people to be looking seriously at ACLs and DMSes. It really isn't self-promotion, though. I don't care if my code gets thrown out as long as Moodle ends up with ACLs at least as powerful as the access_control module, which I consider to be a minimally-adequate first step.
I implemented that module because I needed it right now, which is also how soon I need basic DMS functionality.
I'm excited to see how the meeting goes tomorrow, and since I have funding to be working on this I hope that some of my time in the next couple of weeks can be spent working on real, useful specs and code for Moodle's DMS-plugins architecture. But in any case, I will have to have basic, functioning DMS APIs available to the portfolio module by March, and if I have to implement some (more?) throwaway code to do that, then I guess I will.
I find myself in the role here of being an interested and highly motivated newbie-Moodledev, and I need functionality right now that Moodle will probably have within six months to a year. So I'm doing my best to make good contributions and point to them as examples, even if not as direct paths to final solutions.
what is the progress of DMS? just wanna know...
He, he... looks like I'm not the only one eagerly waiting for that meeting on Friday, am I? May the fork() be with you!
Cheers,
Pablo
Cheers,
Pablo
I think this is a great plan, and I've slapped together a (VERY!) preliminary spec just to get some ideas on the table.
http://docs.moodle.org/en/Document_Management_API
If I'm needlessly stepping on toes or confusing the process here, please let me know.
/me extends wrist for slapping
http://docs.moodle.org/en/Document_Management_API
If I'm needlessly stepping on toes or confusing the process here, please let me know.
/me extends wrist for slapping
so moodle is becoming an e-learning framework/application model?
Is Moodle itself intended to have a DMS user interface? As I've mentioned previously, I think it makes sense for Moodle to have its own basic DMS backend; I think it also makes sense for Moodle to have its own user interface, as well.
Assuming for the moment that Moodle will still have its own user interface, is the current Site Files interface the sort of thing we want? Though there are some things I'd change about it, it's pretty easy to use and it looks OK.
I'm sitting here thinking about how to design this plugin architecture right this very moment, so receiving feedback soon would be helpful.
Since I need this right now, I guess I'll just go ahead and work on it and hope that my work will be helpful to the overall effort whenever it happens later.
Assuming for the moment that Moodle will still have its own user interface, is the current Site Files interface the sort of thing we want? Though there are some things I'd change about it, it's pretty easy to use and it looks OK.
I'm sitting here thinking about how to design this plugin architecture right this very moment, so receiving feedback soon would be helpful.
Since I need this right now, I guess I'll just go ahead and work on it and hope that my work will be helpful to the overall effort whenever it happens later.
Here's a bunch of ruminating.
"...via a plugin to the chosen repository (or repositories)."
That "or repositories" bit is very interesting, because it means you could set Moodle comfortably atop, say, all your fileservers at once. But if we then want users to be able to do totally natural things such as copy files from one to the other, then Moodle will have to handle that, and Moodle will have a super-DMS.
So, not being intimately familiar with file repositories (knowing nothing, really), I spent a bit of time looking through the WebDAV API (since MyDMS appears not to HAVE an API). There wasn't anything too surprising in there -- it's just the same old mkdir, move, copy, lock sort of stuff that we do with files all the time. So it makes sense to me to have Moodle APIs that behave like the standard UNIX commands when it makes sense (which will be most of the time):
Ooooo...or can any particular instance of a plugin be "mounted" anywhere in the tree, as in UNIX? Wheeeeeeee! Would this be helpful and useful, or just confusing and unnecessarily complex? Is this just to help me NOT feel like a Winders(TM) person?
Yeah...it makes sense that a given plugin instance could be "mounted" anywhere in the super-DMS filesystem hierarchy, though of course the super-DMS won't go talking to plugin-instance A in a situation where plugin-instance B is mounted "under" it. Here's what I mean, using pseudo-regular UNIX commands for clarity:
$ mkdir /mnt/pluginA
$ mount pluginA-system /mnt/serverA
$ find /mnt/serverA
/mnt/serverA/
/mnt/serverA/users
/mnt/serverA/users/asmith
/mnt/serverA/users/mranderson
$ mount pluginB /mnt/serverA/users/Middle-School/
Note that I didn't create the Middle-School directory under /mnt/serverA/users... since we're bringing together disparate repositories here, we don't really want to create directories in them that are only used for Moodle to tie them together.
If Moodle now tries to access anything under /mnt/serverA/users/Middle-School/, the super-DMS will find that mount-point in its list and go directly to the right backend-DMS (systemB), skipping over systemA entirely. (This also means that things can keep working even if/when systemA goes down or is inaccessible.)
Now that I think about it, this sort of super-DMS thing probably doesn't really belong in Moodle since it could be very useful apart from Moodle. Maybe the super-DMS should be a different project that Moodle, in turn, uses. But maybe starting it here is fine; it can be ripped out later if it's designed modularly (as it should be), and a simple pass-through API could be dropped into Moodle at that time to use this other project's APIs.
That's enough ruminating for now.
"...via a plugin to the chosen repository (or repositories)."
That "or repositories" bit is very interesting, because it means you could set Moodle comfortably atop, say, all your fileservers at once. But if we then want users to be able to do totally natural things such as copy files from one to the other, then Moodle will have to handle that, and Moodle will have a super-DMS.
So, not being intimately familiar with file repositories (knowing nothing, really), I spent a bit of time looking through the WebDAV API (since MyDMS appears not to HAVE an API). There wasn't anything too surprising in there -- it's just the same old mkdir, move, copy, lock sort of stuff that we do with files all the time. So it makes sense to me to have Moodle APIs that behave like the standard UNIX commands when it makes sense (which will be most of the time):
- mkdir (possibly named "make_collection())
- cp (named copy(), recursive by default for directories/collections)
- mv (named move())
- rm (named remove(), with option for recursion)
- ln (named link(), maybe two functions for clarity: link_this_to() and link_to_this())
- lock (with parameter for 'shared' or not, and depth(?))
Ooooo...or can any particular instance of a plugin be "mounted" anywhere in the tree, as in UNIX? Wheeeeeeee! Would this be helpful and useful, or just confusing and unnecessarily complex? Is this just to help me NOT feel like a Winders(TM) person?
Yeah...it makes sense that a given plugin instance could be "mounted" anywhere in the super-DMS filesystem hierarchy, though of course the super-DMS won't go talking to plugin-instance A in a situation where plugin-instance B is mounted "under" it. Here's what I mean, using pseudo-regular UNIX commands for clarity:
$ mkdir /mnt/pluginA
$ mount pluginA-system /mnt/serverA
$ find /mnt/serverA
/mnt/serverA/
/mnt/serverA/users
/mnt/serverA/users/asmith
/mnt/serverA/users/mranderson
$ mount pluginB /mnt/serverA/users/Middle-School/
Note that I didn't create the Middle-School directory under /mnt/serverA/users... since we're bringing together disparate repositories here, we don't really want to create directories in them that are only used for Moodle to tie them together.
If Moodle now tries to access anything under /mnt/serverA/users/Middle-School/, the super-DMS will find that mount-point in its list and go directly to the right backend-DMS (systemB), skipping over systemA entirely. (This also means that things can keep working even if/when systemA goes down or is inaccessible.)
Now that I think about it, this sort of super-DMS thing probably doesn't really belong in Moodle since it could be very useful apart from Moodle. Maybe the super-DMS should be a different project that Moodle, in turn, uses. But maybe starting it here is fine; it can be ripped out later if it's designed modularly (as it should be), and a simple pass-through API could be dropped into Moodle at that time to use this other project's APIs.
That's enough ruminating for now.
In fact, a best thing would be to mount all your repositories in your normal filesystem tree and then point Moodle at it...but that solution comes with a myriad of other problems. (For example, all Moodle users might need to be system users or something -- eeek! 
)
(For example, all Moodle users might need to be system users or something -- eeek! )
And what about linking between plugin-instances? We could do symbolic-links, which would maybe just be text files with the super-DMS path inside them, and named "link_name.jpg", or whatever. But that would be unintuitive for most users, who will then access the repository the non-Moodle way and have a broken "link_name.jpg" there that actually contains "moodle-link:/systemG/users/sheri/original-filename.jpg".
Well, I've uploaded a first-shot at a pluggable repository architecture. I've kept it kinda under-wraps during development, because I wasn't sure how successful I was going to be. But I'm happy with it, so I hope some other folks are, too. (Especially Martin. )
I also included the first ever plugin for it! Ta-daaa! It's the "Moodle Native" repository plugin, and here are some features I haven't implemented yet:
The trash is not currently accessible at all through Moodle, BTW. Well, if you construct a URL with the ID of a "deleted" item then you'll see it show up with "trashed" in its name. And if you actually look under your Moodle data directory, everything will be in there, too.
Also, I'm not done documenting things, and I certainly have some code cleanup to do. (But not tooooo much.)
After the API is actually implemented I'll document that as well.
So that's the status.
This is all in CVS right now, and since I haven't been told to put anything anywhere else, this is a subdirectory under "portfolio". If you grab the latest portfolio.zip after its nightly processing you should find a "repository" directory under there. Just follow the installation instructions inside there.
Alternatively, you can log directly into my development system at http://moodle.yi.org:1080/mdev6/ if you like. That's the system I'm actually working on, so it might go up and down from time to time. Also, it might have cruft here and there that a normal installation won't have. You have been warned.
The best thing to do to try this out is log in, find the "Repository files" block on the main page, and start playing with it.
And let me know what you think!
)I also included the first ever plugin for it! Ta-daaa! It's the "Moodle Native" repository plugin, and here are some features I haven't implemented yet:
- locking
- links (think UNIX hard links, I think)
- backup
- logging
- administrative/periodic "trash" removal (see below)
- folders
- files
- URLs
- versioning (files and URLs, not folders by design)
- data retention ("deleted" things go into the "trash")
- full ACLs (including group and course support)
- individual, group, and course ownership of resources
- Block with links to
- owned files
- published-to-me files (by user, group, and course)
- shared-to-me files (by user, group, and course)
- all files
The trash is not currently accessible at all through Moodle, BTW. Well, if you construct a URL with the ID of a "deleted" item then you'll see it show up with "trashed" in its name. And if you actually look under your Moodle data directory, everything will be in there, too.
Also, I'm not done documenting things, and I certainly have some code cleanup to do.
(But not tooooo much.)After the API is actually implemented I'll document that as well.
So that's the status.
This is all in CVS right now, and since I haven't been told to put anything anywhere else, this is a subdirectory under "portfolio". If you grab the latest portfolio.zip after its nightly processing you should find a "repository" directory under there. Just follow the installation instructions inside there.
Alternatively, you can log directly into my development system at http://moodle.yi.org:1080/mdev6/ if you like. That's the system I'm actually working on, so it might go up and down from time to time. Also, it might have cruft here and there that a normal installation won't have. You have been warned.
The best thing to do to try this out is log in, find the "Repository files" block on the main page, and start playing with it.
And let me know what you think!
How is this different from the built-in 1.6 repository plugin (as demoed at test.moodle.com, login as hive/hive?)
Hmm. Well, I have no idea. That's certainly interesting, though. I asked Martin Dougiams during the developers' meeting what work had been done on the repository, where I could read about it, etc. He said it was "mostly in his head" at this point, and I took that to mean that I was going to have to talk directly with him to find out more. (This was back on Feb. 3rd, if I have the date right.)
And since he's working hard to get 1.6 out the door, and I needed this repository solution immediately, I just went ahead and did it.
This is definitely a bazaar. Before I did anything myself I made quite an effort (including asking the project leader) what work was going on in this space, and I came up with nuthin'...
So now I've got what I need for the portfolio module, anyway, and I'll have to look more at the hive integration effort later. (I've got to run out the door now.)
And of course there's no reason that somebody can't just write a hive plugin for the respository architecture I just submitted. *shrug* The architecture (like the API) isn't documented yet, but it will be soon.
And since he's working hard to get 1.6 out the door, and I needed this repository solution immediately, I just went ahead and did it.
This is definitely a bazaar. Before I did anything myself I made quite an effort (including asking the project leader) what work was going on in this space, and I came up with nuthin'...
So now I've got what I need for the portfolio module, anyway, and I'll have to look more at the hive integration effort later. (I've got to run out the door now.)
And of course there's no reason that somebody can't just write a hive plugin for the respository architecture I just submitted. *shrug* The architecture (like the API) isn't documented yet, but it will be soon.
Hi, Michael:
I have not been able to test Matt's module yet, but I tested Hive repository plugin and couldn't ever link to a resource ("The tree node is not set up correctly" errors). Of course, this is normal in a development site and surely will be fixed sometime.
Anyway, I think that Matt's problem (and certainly MY problem very soon) is the urgent need to integrate other repositories. Since he was in a greater hurry than me, he just went ahead with his own ideas, and I'm pretty sure his approach is very good.
If I had to integrate a repository TODAY, I would certainly do the same thing, since the "official" API isn't published yet...
I still think that Moodle's NATIVE "filesystem/repository" shouldn't be accessed through this API but be a part of the core. That would allow us to be independent from any repository, allowing changes form one to another, even data migration. So, what do you think about this posting I did yesterday? Do you think it could be possible to make your excellent MyFiles the new file manager?
Cheers,
Pablo
I have not been able to test Matt's module yet, but I tested Hive repository plugin and couldn't ever link to a resource ("The tree node is not set up correctly" errors). Of course, this is normal in a development site and surely will be fixed sometime.
Anyway, I think that Matt's problem (and certainly MY problem very soon) is the urgent need to integrate other repositories. Since he was in a greater hurry than me, he just went ahead with his own ideas, and I'm pretty sure his approach is very good.
If I had to integrate a repository TODAY, I would certainly do the same thing, since the "official" API isn't published yet...
I still think that Moodle's NATIVE "filesystem/repository" shouldn't be accessed through this API but be a part of the core. That would allow us to be independent from any repository, allowing changes form one to another, even data migration. So, what do you think about this posting I did yesterday? Do you think it could be possible to make your excellent MyFiles the new file manager?
Cheers,
Pablo
Hi Pablo,
I don't know that it will happen, but I'm hoping that the work I've done will contribute to what the "official" API turns out to be. If you download the portfolio module and look at repository/lib.php, you can see the beginnings of my work on that already. (I've done the infrastructure in OO code, but the API shouldn't need to be OO. That's the part I haven't finished doing yet - making non-OO APIs that create objects and use them appropriately.)
Why shouldn't Moodle's NATIVE filesystem/repository be accessed through this same API? The "official" API will be a part of the core, and the default native repository should be easily accessible through that API just as any other repository should be. (Why would you want different APIs?) I wrote this entire thing with the intent to create a solid, secure, flexible native repository, plugged into a base class and with [relatively] simple-to-use APIs for use throughout Moodle. This is a total replacement for the existing "file.php" way of doing things, and the design assumes (though loosly) that the native repository will always be present. It seems to me that this fulfills what you're looking for as far as data migration, etc.
It also includes a "file manager", FWIW. It's loosely based on the look 'n feel of "Site files", but with some changes that I think improve it. (Menus instead of lists of links, for example.) I intended this as a potential replacement for Site Files, since that's what I believe Martin has in mind.
I'll post more here late this evening after I return home; I can do more work on defining the API, submit into CVS, and then post the API here for further discussion.
I don't know that it will happen, but I'm hoping that the work I've done will contribute to what the "official" API turns out to be. If you download the portfolio module and look at repository/lib.php, you can see the beginnings of my work on that already. (I've done the infrastructure in OO code, but the API shouldn't need to be OO. That's the part I haven't finished doing yet - making non-OO APIs that create objects and use them appropriately.)
Why shouldn't Moodle's NATIVE filesystem/repository be accessed through this same API? The "official" API will be a part of the core, and the default native repository should be easily accessible through that API just as any other repository should be. (Why would you want different APIs?) I wrote this entire thing with the intent to create a solid, secure, flexible native repository, plugged into a base class and with [relatively] simple-to-use APIs for use throughout Moodle. This is a total replacement for the existing "file.php" way of doing things, and the design assumes (though loosly) that the native repository will always be present. It seems to me that this fulfills what you're looking for as far as data migration, etc.
It also includes a "file manager", FWIW. It's loosely based on the look 'n feel of "Site files", but with some changes that I think improve it. (Menus instead of lists of links, for example.) I intended this as a potential replacement for Site Files, since that's what I believe Martin has in mind.
I'll post more here late this evening after I return home; I can do more work on defining the API, submit into CVS, and then post the API here for further discussion.
Heh - so the file manager part of my site wasn't working between yesterday and just now. That's what I get for changing a bunch of APIs quickly and without testing. 
But it's working now. Whenever you log in and view the main site page for the first time, your home folder is created and you're presented with the file-management block that gives you access to all your own files/folders, all the system files/folders starting in / (but only the ones you can access, of course), all the files/folders published to you (read-only) and all the files/folders shared to you (read-write).
On to the rest of the API definition -- and I'll test more thoroughly this time before I post here...
But it's working now. Whenever you log in and view the main site page for the first time, your home folder is created and you're presented with the file-management block that gives you access to all your own files/folders, all the system files/folders starting in / (but only the ones you can access, of course), all the files/folders published to you (read-only) and all the files/folders shared to you (read-write).
On to the rest of the API definition -- and I'll test more thoroughly this time before I post here...
Unless I'm remembering incorrectly, I'm pretty sure Martin also said that the repository architecture he had in mind was going to be post-1.6. The overall impression I had was that nothing existed for me to look at and contribute to, the plans that do exist are in his head, and (quite rightly) he's totally preoccupied with the 1.6 release, so ...
Maybe what I've done stinks and it will die a lonely death beside the Moodle-brick road, but I hope it at least provokes some beneficial discussion and inspires us all to bigger and better things.
And, of course, I needed it right now for the portfolio module. (I have to have it integrated with the portfolio module by Friday.)
Hmm. That's tomorrow, now.
Maybe what I've done stinks and it will die a lonely death beside the Moodle-brick road, but I hope it at least provokes some beneficial discussion and inspires us all to bigger and better things.
And, of course, I needed it right now for the portfolio module. (I have to have it integrated with the portfolio module by Friday.
)Hmm. That's tomorrow, now.
Couple other features that aren't implemented yet:
- moving resources
- copying resources (you can always download and upload somewhere else )
Oy - and [un]zip, of course.
Dear Matt,
Where can I download the latest DMS version.
Could you put up a link. ??
Thanks
Garry
I've run out of time to do the careful API documentation that I wanted to do. I see what I've implemented as a start, but there's a lot more thinking and work to do.
I've included a repository-DEVELOPERS.TXT file in the repository module directory that interested people should consult; I won't repeat its brief contents here. (They mostly just tell you where to find stuff in the code, and how I've been thinking about this architecture design.)
But I will throw this list of relevant APIs here for the sake of discussion:
Functions in lib.php:
Fetch (a) repository record(s) object by ID, name, or plugin:
Methods in plugins/plugin/repository_plugin.class.php:
Process the addition of a new resource to the repository.
Process a new file:
Delete a resource:
Copy a resource:
And, of course, there all kinds of debates we should have about whether this is a good way of handing data around, etc.
Lots of these have both "$path" and "$resourceid" parameters - these are always redundant (though callers usually only supply one of the two), with $path always taking precedence over the subsequent $resourceid, $folderid, etc.
I've included a repository-DEVELOPERS.TXT file in the repository module directory that interested people should consult; I won't repeat its brief contents here. (They mostly just tell you where to find stuff in the code, and how I've been thinking about this architecture design.)
But I will throw this list of relevant APIs here for the sake of discussion:
Functions in lib.php:
Fetch (a) repository record(s) object by ID, name, or plugin:
repository_get_repository($repoid=0, $name='', $plugin='');
Fetch a specified repository object:repository_fetch_object($repoid=0);
Methods in plugins/plugin/repository_plugin.class.php:
Process the addition of a new resource to the repository.
new_resource($type=0, $path='', $resourceid=0, $interactive=false, $new_resource_data='', $new_version=false);
Process a new file:
new_file($resource='', $new_file='', $interactive=false, $source_path='');
Create a new folder:create_folder($folder='', $new_folder_name='', $interactive=false);
Read the contents of a file, folder, URL, etc.read($fileobj='', $expected_type=0, $add_parents=true);
Delete a resource:
delete_resource($path='', $fileid=0);
Rename a resource:rename_resource($path='', $fileid=0, $new_file_name='', $interactive=false);
The following are (thus far) unimplemented at all, and the parameter lists should probably change to have path, resourceid pairs instead of $source:Copy a resource:
copy_a_to_b($source='', $destination='');
Move a resource:move_a_to_b($source='', $destination='');
Link a resource:link_a_to_b($source='', $destination='');
Lock a resource:lock($resource='', $shared=true, $timeout=0);
Connect (to the remote repository host):connect($authinfo...something...);
Disconnect (from the remote repository host):disconnect();
Looking back over that list now, it seems clear to me that either "delete_resource()" and "rename_resource()" should be renamed without "_resource", or "read()" should have "_resource" added.And, of course, there all kinds of debates we should have about whether this is a good way of handing data around, etc.
Lots of these have both "$path" and "$resourceid" parameters - these are always redundant (though callers usually only supply one of the two), with $path always taking precedence over the subsequent $resourceid, $folderid, etc.
BTW, http://moodle.yi.org:1080/mdev6/ has been up-and-down a lot for the past couple of days as I've been debugging. But I'm moving on to another Moodle for live development now, so mdev6 should be stable if you want to check out the repository stuff.
Added 'copy' functionality just now. It seems to work ok for Folders and Files, but it's b0rken for URLs.
I haven't thoroughly retested everything else, so I hope I didn't break anything too badly along the way.
It might be a few days until I get back to this; my "real job" (grad school) is calling me...
Everything's in CVS under contrib/portfolio/contrib/repository/.
I haven't thoroughly retested everything else, so I hope I didn't break anything too badly along the way.
It might be a few days until I get back to this; my "real job" (grad school) is calling me...
Everything's in CVS under contrib/portfolio/contrib/repository/.
Matt,
your immediate need is probably gone now, but we have had to do the same task. What we did was use Metanode (open source - see sourceforge or www.metanode.net) federated respository. Its development was funded by a number of sources including projects for Australian local and federal Government so it has all the Dublin Core and AGLS metadata inheritability features, and keyword tagging any project would want. It is also good at crawling, link checking and syndicating data across sites - one installation aggregates data from 640 councils and presents it in a consistent format, another synchronises parts of web sites in different countries for an economics bureau - each page deals with the local economy - shared with the other nations.
The search uses several strategies to collect data and appears to be able to index all the Moodle content in courses where access is granted to the search engine. Resources (e.g. files) can be held once in the repository and shared or groups can have their own copies, but the sharing with Moodle database needs to be worked on. The access options allow groups and individual control over areas, with built-in capability for RSS, blogs and discussion boards.
One reason I mention it is because the e-library facility has built the interface for importing and exporting resources. I noticed that as a requirement you wanted to address. I'm sure the code is available, either to use the metanode code, or to make the projects closer. I believe that a single sign-on for metanode and Moodle has been developed. This system is used for supporting a Moodle environment to train the Primary Health Care workers across Australia.
I have some documents we have been working on related to portfolio and lessons from the Open Source Portfolio Initiative, where I see some architectural concerns that I think can be addressed in this project. If any of this could be relevant then feel free to query me at ebusconsultants-training at yahoo dot com. I still don't clearly understand the effect the OU mammoth will have on community development directions so I don't think I can contribute much, but this work is freely available.
your immediate need is probably gone now, but we have had to do the same task. What we did was use Metanode (open source - see sourceforge or www.metanode.net) federated respository. Its development was funded by a number of sources including projects for Australian local and federal Government so it has all the Dublin Core and AGLS metadata inheritability features, and keyword tagging any project would want. It is also good at crawling, link checking and syndicating data across sites - one installation aggregates data from 640 councils and presents it in a consistent format, another synchronises parts of web sites in different countries for an economics bureau - each page deals with the local economy - shared with the other nations.
The search uses several strategies to collect data and appears to be able to index all the Moodle content in courses where access is granted to the search engine. Resources (e.g. files) can be held once in the repository and shared or groups can have their own copies, but the sharing with Moodle database needs to be worked on. The access options allow groups and individual control over areas, with built-in capability for RSS, blogs and discussion boards.
One reason I mention it is because the e-library facility has built the interface for importing and exporting resources. I noticed that as a requirement you wanted to address. I'm sure the code is available, either to use the metanode code, or to make the projects closer. I believe that a single sign-on for metanode and Moodle has been developed. This system is used for supporting a Moodle environment to train the Primary Health Care workers across Australia.
I have some documents we have been working on related to portfolio and lessons from the Open Source Portfolio Initiative, where I see some architectural concerns that I think can be addressed in this project. If any of this could be relevant then feel free to query me at ebusconsultants-training at yahoo dot com. I still don't clearly understand the effect the OU mammoth will have on community development directions so I don't think I can contribute much, but this work is freely available.
Hi Martin, hi all!
I just want to inform you that we developed and released DOOR, and open source Learning Object Repository - not exactly a DMS, but close.
It's very simple, with the minimum implementation of IMS metadata. When you are in Moodle as teacher, you can connect to the repository and seamlessly import a LO as a resource.
It also supports Shibboleth.
I still didn't check out the new 1.6 repository system, I hope it is not a complete overlap... and I hope it can contribute to the further developments.
The link is: http://door.sourceforge.net
I am having a problem with installation. After setting up the database and starting the install I put all the information about the database etc into setup2.php and when I get to setup3.php this is the message I get:
Warning: main() [function.main]: Unable to access E:/Website/Primary/elmgrove.brighton-hove.sch.uk/door/setup/setup2.php\lib\db\adodb/adodb.inc.php in E:\Website\Primary\elmgrove.brighton-hove.sch.uk\door\lib\db\db_interface.php on line 3
Warning: main(E:/Website/Primary/elmgrove.brighton-hove.sch.uk/door/setup/setup2.php\lib\db\adodb/adodb.inc.php) [function.main]: failed to open stream: No such file or directory in E:\Website\Primary\elmgrove.brighton-hove.sch.uk\door\lib\db\db_interface.php on line 3
Fatal error: main() [function.require]: Failed opening required 'E:/Website/Primary/elmgrove.brighton-hove.sch.uk/door/setup/setup2.php\lib\db\adodb/adodb.inc.php' (include_path='.;C:\php5\pear') in E:\Website\Primary\elmgrove.brighton-hove.sch.uk\door\lib\db\db_interface.php on line 3
Any ideas please?
Hi,
I'll release as soon as possible door 1.3.1. I had a problem with my PC and I have to fix it (broken Power Supply), but I hope to release the new version today or at last tomorrow. Thanks.
Mauro
I'll release as soon as possible door 1.3.1. I had a problem with my PC and I have to fix it (broken Power Supply), but I hope to release the new version today or at last tomorrow. Thanks.
Mauro
Check http://door.sourceforge.net, I added door-1.3.1, download it and let me know if it works.
Mauro
Mauro
Hi Mauro
It comes an error:
This module cannot be added to this course yet! (No file found at: ../mod/door/mod.html)
A question, wich path i must set, to the upload folder?
Bye Andy
It comes an error:
This module cannot be added to this course yet! (No file found at: ../mod/door/mod.html)
A question, wich path i must set, to the upload folder?
Bye Andy
Sorry I didn't understand.
When did the error happen? Could you please exlpain me exactly what it happens?
Thx Mauro
When did the error happen? Could you please exlpain me exactly what it happens?
Thx Mauro
Hi Mauro
The error comes when i´m inside a course and want install a activity. I check the downloadpack, there is no mod.html inside!
Bye Andy
The error comes when i´m inside a course and want install a activity. I check the downloadpack, there is no mod.html inside!
Bye Andy
Well, by default (under module settings section) DOOR is disabled as activity (closed eye), because it's a resource. To import a learning object in your course you have to choose it from the resources combobox and not from the activities combobox.
Let me know whether it works or not.
Mauro Nidola
Let me know whether it works or not.
Mauro Nidola
About the upload folder, you can decideto use the "uploads" directory which is provided with door, just fill the textfield with: uploads.
Mauro
Mauro
Mauro it was to late for me 
sorry - it works now!
Thanks Andy
sorry - it works now!Thanks Andy
I have downloaded DOOR 1.3.1, but can't figure out your Moodle instructions below (from http://door.sourceforge.net/README_MOODLE.TXT):
- Copy the "doorconfig" directory to moodle/mod/ and rename it to "door"
I don't find any other directory in the unzipped version but "door"
- Copy lang/SELECTED_LANGUAGE/help/door to moodle/lang/SELECTED_LANGUAGE/help/door in the moodle tree
I don't find any language files in the zipped 1.3.1 package.
Thanks for your help.
Jim P.
- Copy the "doorconfig" directory to moodle/mod/ and rename it to "door"
I don't find any other directory in the unzipped version but "door"
- Copy lang/SELECTED_LANGUAGE/help/door to moodle/lang/SELECTED_LANGUAGE/help/door in the moodle tree
I don't find any language files in the zipped 1.3.1 package.
Thanks for your help.
Jim P.
Hi James
I initially had the same problem, then realised I needed to download the moodle-plugin found in the older, door-1.3 directory (not the latest door-1.3.1)
http://sourceforge.net/project/showfiles.php?group_id=162324
This seems to work fine with the latest DOOR 1.3.1, which you need to set up separately.
Having tinkered with more complex repository systems under development, such as OSLOR/Eprints and Access Control/Repository/Portfolio, I must say that the simplicity of the DOOR repository is a delight. Just the job for straight-forward resource sharing between different Moodle courses, and even different Moodle installations.
One suggestion would be for the developers to add a download link for DOORS to the Moodle Modules and Plugins database. This would expose this cool technology to a wider range of Moodle users.
A big thanks to all those involved in the development of DOORS
Geoff
I initially had the same problem, then realised I needed to download the moodle-plugin found in the older, door-1.3 directory (not the latest door-1.3.1)
http://sourceforge.net/project/showfiles.php?group_id=162324
This seems to work fine with the latest DOOR 1.3.1, which you need to set up separately.
Having tinkered with more complex repository systems under development, such as OSLOR/Eprints and Access Control/Repository/Portfolio, I must say that the simplicity of the DOOR repository is a delight
. Just the job for straight-forward resource sharing between different Moodle courses, and even different Moodle installations.One suggestion would be for the developers to add a download link for DOORS to the Moodle Modules and Plugins database. This would expose this cool technology to a wider range of Moodle users.
A big thanks to all those involved in the development of DOORS
Geoff
Thanks Geoff!
Making something simple is exactly what we had in mind to support our teaching staff.
We put the plug-in in the plug-in page, thanks for the advice!
Luca
Well I successfully installed DOOR and intagrated it with moodle but I cannot download an IMS from door so that I can upload it to moodle. The reason for not downloading is that it cannot find the /door/lib/ims/mkims.php?id=2 file
Any idea why is that happening?
Panayiotis
Any idea why is that happening?
Panayiotis
Could you please check that you have the following file:
PATH_TO_DOOR_FILES/lib/ims/mkims.php
By the way, you don't have to download the IMS from door and then upload it to moodle. The plugin for moodle does it for you. Just read the manual: http://door.sourceforge.net
Mauro
I installed Door 1.3.1 as my repsoitory and the plug-in as described elsewhere in this forum. I get to choose from the Door repository and press the select button as directed in the door handbook. Then I get this message:
You are here, PC CF101 >> Resources >> Dialogue: Sync Models
Learner instructions for a dialogue on synchronous models. Intro for discussion forum or discussion group.
Not Found
The requested URL /moodle/file.php/8/moddata\door\15\5.doc was not found on this server.
If I choose Update this Resource, I end up looking at the following message:
| The file is not a valid Learning Object |
Any help would be appreciated.
John
This is a known bugs that I solved, soon I'll release a new version of the plugin.
Replace the file PATH_TO_MOODLE/mod/resource/type/door/digest_lo.php
with the attached one.
Let me know if it works.
Mauro
Replace the file PATH_TO_MOODLE/mod/resource/type/door/digest_lo.php
with the attached one.
Let me know if it works.
Mauro
It works now, thanks.
John
First let me say that I agree a Document Management System is a good idea. I've seen documents (e.g. large MS PowerPoint presentations) loaded into many different courses. This is a waste of disk space and a real pain if you want to update it trying to find all the places its used. This is something an external DMS can help with. All you need is to have static web links in your courses which never change but always pick up the most recent version. A good DMS will also provide search facilities so that you can easily locate material to re-use. Ideally it will allow the content (not just metadata) to be searched.
Now let me say that I don't think that Moodle itself needs to be a DMS too. Just concentrate on the e-learning functionality. There are many external DMS products (commercial and Open Source) which could be used. HarvestRoad Hive, OWL amd Knowledge Tree have all been mentioned in posts to this forum. I also don't believe that any tight integration of Moodle with a DMS is essential. Cutting and Pasting web links is probably something a course builder will need to do anyway.
I've tried OWL and Knowledge Tree (KT) and have found the latter to be more to my liking. It seems easier to use/understand and coming from a Java background I would say the code is better quality. There seems to be more wrapped around it too in terms of support and documentation. I've even tweaked it to sit more comfortably alongside Moodle (or any other VLE for that matter).
Now here's one I've not seen referenced: OpenACS dotLRN. I've tried this product and its a real bitch to install but good none-the-less (Open Source too). One thing they are working on is LORS (Learning Object Repository Server). I'm not sure what format these objects are in - IMS/SCORM or whatever. The point is, if such a repository existed and could be used by Moodle then so much the better. I would want to invest some time in this direction rather than worrying about the simpler DMS issues.
I am a user of Ubunto and I tried a lot of document management system like Alfresco, RavenDB,Owl, Document Manage etc. I think rather than Owl the document manage suits more in Ubunto.
Hi Sasha,
I suggest you try OpenKM. OpenKM is an open source document management system with many features such as: workflkow, task management, document version control, etc..
There is a free version and a professional version.
You can find more information here: http://www.openkm.com
Regards!
Hey all,
I am definitely a bit late for this conversation, but I am more interested in addressing the confusion between DMS and ECM that people are having!. We put together an article displaying the differences...however is this geared more towards the management of converted documents (rather than those who have always been electronic). - http://www.nedocs.com/blog/dms-vs-ecm
Additionally, what kind of privacy protection can/does OWL provide? Perhaps it is an ideal fit for something like Moodle...but what about an organization looking to pick up a strong DMS?
Thanks!