Hi Jean,
In my experience, some metadata (such as the date a file was last
modified) often does NOT correspond with actual changes in content.
For example, if I edit the author listed on the Properties page of a
file in Alfresco -- not in the file itself, but in Alfresco -- then
the last modified date changes, but the file itself and -- most
importantly from the user's POV -- has NOT changed. So a file that was
last updated in content a year ago could show a "last modified" date
of today, thus totally misleading anyone thinking of downloading it.
It is true that, associated with any one content item (doc, image,
etc.), there are "internal Alfresco system-generated attributes", and
"file internally-contained attributes" (notably meta data fields).
So, notably on http://media.libreoffice.org:8081/, it would be
important to display a detailed and appropriately-defined set of meta
data.
That is one reason why I am unconvinced with the idea that USEFUL info
like update dates can be automatically presented to users through the
Alfresco interface, instead of being manually updated on the wiki.
This problem is not unique to Alfresco, of course; it also occurs with
the ODFAuthors site and probably all other CMS as well.
Well, again, part of the solution would be to make use of the file's
meta data, both the "user-defined" properties that the documentation
team would have to define, and the properties automatically generated
by the LibreOffice components (Writer, Impress, etc.) when a file is
created or modified.
This works fine from the viewpoint of the CMIS browser behind
http://media.libreoffice.org:8081/, which will happily display that
information.
But I'm not sure about the software behind http://libreoffice.org
(SilverStripe) or the TDF wiki (http://wiki.documentfoundation.org,
which uses MediaWiki). Are they able to extract and display the
properties of ODF files? To the best of my knowledge, they can't per
se. And I'm not aware whether there are any plugins for SilverStripe
and MediaWiki that give them this functionality.
So you *might* be stuck with a choice: either make
http://media.libreoffice.org:8081/ the principal tool for
browsing/downloading content on the Alfresco platform, in which case
the problem can be overcome. Or, alternatively, if you want the wiki
and LibO main site to be the main download points, you'd have to go
with just using links from http://media.libreoffice.org:8081/ and
would have to maintain tables with manually-updated information.
However, solution #1 depends on reasonably-meticulously maintaining
document properties (the meta data) up to date... See below for more
comments about that.
Some metadata, like file size, is fine. Other metadata, such as
Description and Author, depends on accurate information being put into
the Properties of the file itself (from which Alfresco extracts it) or
that info being amended in Alfresco after the file is uploaded. In my
experience, the Properties of the file are frequently not filled in
correctly, even when writers, editors, and publishers have been given
instructions on what to do. (I am often guilty of this omission
myself.)
So I don't think this metadata issue is at all compelling as a major
reason to use Alfresco, even though it's certainly not an argument
against Alfresco.
Of course, the quality of information you will get from Alfresco (or
any ECM system or CMS) partly depends on the discipline with which
people maintain the information.
It will also partly depend on the quality of configuration and
capability of the ECM software, whether it's Alfresco or any other
product.
It is true that Alfresco has excellent capability as regards support
for document meta data, whereas I'm not sure whether the same is true
for SilverStripe, MediaWiki and Plone.
Proper use and maintenance of meta data fields could save a *great*
deal of manual work on 3 different sites. This will certainly true if
one uses Alfresco.
Instead of manually updating info on the wiki and LibreOffice main
site, you could simply ensure that the same information is
meticulously recorded in the file meta data.
Perhaps one possibility would be to have someone in the team
fulfilling a dedicated librarian role, and spending time checking and
rectifying meta data, etc. This could logically be part of the
Alfresco administrator job, for instance.
At the moment, you, Jean, are very disciplined about maintaining
version and publication date info on the wiki. Is it more just a
question of where one places that work (on Alfresco, or on the wiki,
or on the LibO main site), and which positioning of the work brings
the largest return of added value and saved labor?
