First a bit of status - As I was working on updating the RDF documentation (you can find the 1.2 version at spdx.org/rdf/terms), I found that the Ruby based tools that generate the HTML pages do not seem to work on a new laptop I recently migrated to. I suspect this is due to a change in some of the dependent libraries, but I have not had a chance to debug.
This prompted me to start thinking about some alternative ways to generate the documentation. Now the topic suggestion: Should we change how we manage and document the RDF/XML terms? Here are some alternatives I know of: A: Continue maintaining the documentation as a master HTML file which generates the web pages, the text used in the specification appendix + generates OWL schemas for the web sites. This would require fixing the Ruby issues. It would be really really helpful if someone with more Ruby expertise than myself (which turns out to be a pretty large population) could help. B: Just maintain a straight HTML page of the terms and drop the Ruby tools generation. We would lose the schema files. C: Move to Protégé as the master for storing and maintaining the terms. The web version (http://webprotege.stanford.edu/) has some collaboration features and the desktop version can be used to output various formats. Bill has already done some good work investigating this approach. To output documentation there are a few alternatives: C1: Use the existing owldoc plugin to generate the documentation for the web and just put a link in the specification documentation to the website. Attached is an example using a different project I just pulled down from Protégé. C2: Write a custom plugin to Protégé to output the documentation for the website and specification. C3: Use Protégé to maintain the terms, but manually create the HTML and documentation pages (option B above) >From my perspective, A is probably the path of least resistance, however, I do like the idea of using Protégé for a collaborative method to maintain the terms. Option C1 is the second easiest, but we lose the documentation in the appendix. C2 would meet all our needs, but there is a lot of work to write this. I don't have enough bandwidth to do it myself, but perhaps with some help... Gary ------------------------------------------------- Gary O'Neall Principal Consultant Source Auditor Inc. Mobile: 408.805.0586 Email: <mailto:[email protected]> [email protected]
_______________________________________________ Spdx-tech mailing list [email protected] https://lists.spdx.org/mailman/listinfo/spdx-tech
