Hi Jean, On Sat, Aug 25, 2012 at 9:26 AM, Jean Weber <[email protected]> wrote: > 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? -- David Nelson -- Unsubscribe instructions: E-mail to [email protected] Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.libreoffice.org/global/documentation/ All messages sent to this list will be publicly archived and cannot be deleted
