Skip to first unread message
Rafael Antonio
Nov 17, 2021, 9:00:27 AM11/17/21
to AtoM Users
EADXML is the standard but however whe can use OAI_DC metadata format it would be useful for some repositories to have a MARCXML format available.
Would you accept to implent such format? I am open to help if someone send me information about files to do it.
Regards,
Rafael Antonio
Dan Gillean
Nov 19, 2021, 9:58:07 AM11/19/21
to ICA-AtoM Users
Hi Rafael,
The short answer is: yes, we can see value in supporting MARCXML exports and via the OAI repository module for harvesting, and have had questions about supporting such a format in the past. If someone were to develop such a module against the latest development branch, meet our coding standard and community development recommendations, and be willing to implement change requests during the code review process, then it is likely we would be open to merging it and taking on the ongoing maintenance of such features.
However, there are also many other considerations for us, meaning the answer is closer to "it depends."
The AtoM project is in a somewhat strange and transitory time period. The need to move away from the deprecated Symfony 1.x framework AtoM was originally built with becomes increasingly important, but doing so requires a lot of time, effort, research, development, and money - either rewriting AtoM in a new code base or developing a long term incremental plan to move core modules out into more modular elements in new code bases. Because of this, we need to be cautious about adding new functionality to maintain while trying to develop a strategy to eventually move everything to a new code base - all while there is no guaranteed large-scale funding for this type of work.
Artefactual is going through its own changes, as we consider how to better deliver value to our clients and users, while ensuring we can remain sustainable as a company and continue to follow our core values, particularly around openness and open source. This means ensuring that we are not adding work that is not maintainable or broadly usable and of value to the wider community, as this impedes our ability to focus on value in the long run. It also means being cautious that we are careful with unpaid work we agree to take on, because we give away all our products for free and therefore offering our time and experience is the one way we manage to remain viable as a company and continue to develop and maintain these projects. Reviewing large pull requests, merging in code, adding documentation, answering forum questions about new features, and continuing to test, fix, document, and generally maintain said features through future releases are all unpaid costs requiring a lot of Artefactual time and effort, that can take away from release preparation, testing, documentation, and forum support for other features and bugs.
For these reasons, we are being a bit more cautious about how we approach community code contributions. We have some general recommendations and resources on our wiki that I would urge you to review, but I will also add a few more thoughts in light of the above. First, see:
Key things to note in here:
- We cannot guarantee that we will accept and merge all pull requests
- Pull requests should be organized into clear atomic commits
- The best contributions will reuse existing methods, functions, modules, etc whenever possible - this means that studying the existing code is a good way to prepare for new feature development
- Your fork should be prepared against our latest development branch (qa/2.x) - the easier it is to merge into our main dev branch without conflicts, the more likely we are to accept the work
- Check our coding standard and make sure you run PHP CS Fixer locally before merging
- You should budget time and resources to be able to make changes based on feedback received in the code review process
And based on the points above, I would add:
The best way to get a new feature merged into the public project and have Artefactual take on its ongoing maintenance will be to prepare your own public fork that is rebased against our latest development branch and share it with the community yourself. We would happily help to promote such an effort. If we see that others are interested and are able to use it themselves, then you have proven value, and by taking on the risk of preparing and maintaining the fork yourself, you have reduced risk for us and the public project. At this point there is proven value and uptake, and we would be very inclined to make the work more broadly available by merging it into a public release.
As for where to start? Check out the general development resources listed in the links above as a starting point. Study the existing export functionality (such as for EAD and DC XML) and the OAI module.
Long ago there were plans to support MARCXML in earlier versions, but this work was never sponsored. However, you can find some old XSLT stylesheets in AtoM for converting EAD or OAI-DC to MARCXML. I have no idea if these will still work with AtoM's EAD profile or if they remain current with the MARC XML schema, but they might be useful - see for example:
Good luck!
Dan Gillean, MAS, MLIS
he / him
--
You received this message because you are subscribed to the Google Groups "AtoM Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ica-atom-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/f7a2872d-c418-4715-830b-fe6ebb519960n%40googlegroups.com.
Rafael Antonio
Nov 19, 2021, 3:15:31 PM11/19/21
to AtoM Users
Dan
Many thanks for kindness and detailed explanation. It is better to wait for new developments and after this transitory time period.
If it was easy to adjust some fields for present OAI_DC profile it would solve it. Is there any documentation about export functionality?
Have a nice weekend.
Rafael
Dan Gillean
Nov 19, 2021, 3:46:47 PM11/19/21
to ICA-AtoM Users
Hi Rafael,
Thank you for your kind words and understanding.
One important factor to keep in mind: there is currently no money or roadmap for a next generation version of AtoM, meaning it is still years away at minimum. We at Artefactual have many thoughts and ideas, and of course there is now the AtoM Foundation who are working on developing plans for this as well, but nothing is currently guaranteed. This means we can't make any firm rules like "no more AtoM2 development" or set a firm timeline when we will shift focus to a new codebase. As a small company that gives its products away, we simply do not have the resources to build AtoM3 without significant support.
This means that it's not necessarily a bad idea right now to add new functionality such as another type of export format. Instead, I simply mean to point out that we need to balance all factors, and really compare the effort and long-term impact against the value it will provide to users in the meantime.
If you believe the value of adding MARCXML to the OAI module outweighs the effort and risk, and you believe that others will agree, then I would encourage you to pursue such development! If you can show us that value, we will happily merge the work and take on its maintenance.
Regarding export functionality documentation:
There is no developer documentation about this particular functionality in AtoM, just end user documentation as found in the user and admin manuals:
However, you could look at in the code:
We also have slides that introduce you to AtoM's codebase and development in AtoM, slides on creating a new plugin (it's a theme plugin but some of the basics apply to all Symfony plugins), database entity relationship diagrams on the wiki, and other development resources listed in my last message. I hope that together these resources might help!
Cheers,
he / him
To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/52fb8dcf-78b4-43c9-a6c1-7b342f627df8n%40googlegroups.com.
Rafael Antonio
Nov 24, 2021, 7:53:28 AM11/24/21
to AtoM Users
Dan Gillean
I send my best wishes for the sucess of AtoM Foundation that will be an important suport for everybody. ATOM became a fundamental tool for archives around the world and may be a crossfunding iniatitive could help to leverage foundation. Count on me for portuguese promotion.
Meanwhile OAI is enough for what need and I got a turnarround instead alter OAI code that will explain soon. What we have is good enough.
Regards,
Rafael Antonio
Reply all
Reply to author
Forward
0 new messages