Two weeks ago, I had a chance to look at some slides about ICE (cf. Familysearch, https://devnet.familysearch.org/static-files/presentations/2009/Interoperable%20Citation%20Exchange%202009-03-11.pdf ). ICE seems to have some concepts that could be useful in a structured approach to development of source types, if the concepts were "internationalized". The "Citation Element" concept in ICE is similar to a concept that has been called "citation modules" on the BetterGEDCOM wiki. It would be very interesting to have FS involved in a more long term solution, work that seems to be of interest to the majority of those working on the BetterGEDCOM wiki.
Comments on SourceTemplates.org
I have been reluctant to comment on the SourceTemplate.org (ST) pages earlier since the scope, governance, participation and organization has not been announced, and still have to be clearly defined. The project is at the moment run by Real-Time Collaboration, and BetterGEDCOM (BG) has been informed about some aspects of Real-Time Collaboration's plans. We have seen little text describing the project in a way that allows BG members to have an opinion about how ST should be run. It seems premature to present ST as a subproject of BG - will BG be the governing body of ST?
Since the proposed ST model has now been made publicly available, it is possible for me to comment on it. Real-Time Colaboration have set a deadline for comments on the model to Oct 10, one week from publication. I don't see that as very realistic. One reason is that the presented documentation is not much more than a sketch.
It is very unclear to me if Real-Time Collaboration really has an intention to develop a solution that can work internationally, although such an intention is stated on the ST.org pages, and has explicitly been requested by BG. The project will start with a US-only solution for sources and citations based on Evidence Explained. Unfortunately there were statements in the last developer meeting that makes me think that it will take very long time before the project in its current form will go beyond Evidence Explained, if ever. In any case, I have little expertise to contribute on US sources and have no use for EE source templates.
Support for international use has at least these components:
1. The model must support it. If the structures, fields, codes and rules are not designed for international use, there will be problems later. Examples of things that must be looked into are the data types and the ability to indicate the language of various information.
2. The model has to support an organizational model for development and identification of source types, templates, fields (BG Citation elements) etc, and that will allow exchange of definitions of these (without citation data). It currently only support AncestorSync's internal requirements, and is focused on products rather than independent specifications.
3. Considering the concerns expressed on the wiki about the complexity and specificity of Evidence Explained, and its lack of structure, it will be necessary to develop principles (models) for development of more general source types and citation elements (field types) for international use. Most of this can probably be developed in a second phase, but the model must support such development. It can most likely be achieved without major changes to the proposed model by allowing field type and source type definitions/references to reference more general definitions that can be used as a substitute for the primary one identified in the transferred data. Although not specific to international use, such generalization will also be important for automatic transfer of source meta data from various repositories on the internet. In addition, a somewhat more sophisticated solution for "keywords" is required.
4. International exchange of citation data will require support for several capabilities.
a. It must be possible to present the citations in a language different from that used when the data was entered. A template in the English language will often not be appropriate in a report produced in a different language.
b. It will also be necessary to allow transfer of some citation data in several different identified languages.
c. It must be possible to exchange definitions and descriptions of source types, field types etc. that will allow the receiving user to enter or modify citations according to these. The proposed model goes a long way in this direction, but can be improved. Support for translations of these definitions and descriptions, and reference to the original is required. (A UUID attached to each element in a definition would be part of this.) Transfer of definitions, independent of user data, will also be useful.
d. The generalization of field definitions mentioned above will also allow a recipient of data to use the data even if the original source type and templates are not available, i.e. is used in a another country.
e. It may seem like the proposed model claims to support "independence of citation styles". Is this what "switching source types" means? This is something that will most likely be required internationally (and domestically). However, style independence for the citation data does not seem to have any support in the current model.
5. Source types and templates etc. needs to be developed for many countries (and possibly repositories). This should be done in the relevant countries, and preferably be translated into other languages, once a model with international capabilities, and an organizational framework, have been established. Real-Time Collaborations have suggested that this work could be done by a single university. This is not very realistic if you want quality.
Although a lot of the detailed work related to support for international requirements can be postponed to a later phase the model has to support these requirements, and that work cannot be postponed. The project will therefore have to make up its mind about international support, and how that work will be governed.
GEDCOM implementation of the ST model.
A BetterGEDCOM sub project would have to create a specification that as a short term solution that would amend the GEDCOM format, using GEDCOM syntax, to carry the data in the data model. This specification must be developed in parallel to the data model, to ensure the model does not create problems for such an amendment.
The model does not cater for backward compatibility with systems that do not support EE, but only supports the old GEDCOM. There is a need to build support for this into the model – primarily in the definitions of citation data. It could be combined with features allowing cross style transfer of data.
The web page SourceData Type on SourceTemplates.org
Essentially the source data carried by these structures are not needed to create a citation. In a BetterGEDCOM context, such data have been discussed in an "Evidence" context. Also, there exists much better, and yet relatively simple solutions for carrying this type of data. I think this record type should be left out, or it should be handled by a separate project.
The page RecordManager Type
This page has little to do with standardization. In a GEDCOM context, since it is merely a way to carry product specific data values. The same functionality can be accomplished by e.g. underscore tags in GEDCOM. It would be much better if one attempted standardize the values, cf. discussions in the Requirements Catalogue of BG.
"Open Source Community Source Templates" by Randy Seaver on Oct. 5
"The SourceTemplates Initiative" by Tamura Jones on Oct. 5
And a press release from Real-Time Collaborations
Why do I have to post all these links, partly to info I am not informed about on this wiki or the BetterGEDCOM Developer meetings? Is the BetterGEDCOM wiki no longer relevant to BetterGEDCOM?