Digest response to James Mason and Robert Shaw, for which I apologize.
Message: 1 Date: Fri, 08 Sep 2017 14:09:10 -0400 From: James Mason jrm@slashmail.org To: "Discussion about the Wikimedia genealogy project." wikimedia-genealogy@lists.wikimedia.org I'm not quite sure what is meant by the remarks that GEDCOM structures - imposed on a Wiki - lead to something clunky. Are we talking about UI design, code implementation, maybe both?
Wow, I just wrote a 7 paragraph response to this, which is way too long and complex. Here is a brief synopsis:
The basic solutions are all a kluge - a way to work around the underlying structure of Mediawiki. This makes them slow to render on save, and usually both brittle and high maintenance. Basically you are storing data inside text which is parsed to html and then stored in a database - so no one can work with just the data directly.
A different solution is to write a Mediawiki extension to do everything a genealogy software does except the presentation layer, except it also has to at least do Create and Update so you still have some presentation. Which means you basically invented another genealogy wheel. If we are going to do this much work to bring genealogy data to Mediawiki we could save effort by reversing - add a free form text article to a genealogy software - which would then retain the benefits of data manipulation and surfacing.
So maybe a semantic MediaWiki basis would allow for WeRelate to be implemented without reliance on hacking the base code? Thereby less clunky?
The semantic relationships should allow for bi-directional relationships, but I have avoided SMW after my first experiments with it because it is mind-bendingly difficult for me to grasp. You could ask the good SMW folks in IRC at irc://chat.freenode.org/semantic-mediawiki (browser IRC client at http://webchat.freenode.net/?channels=semantic-mediawiki)
Amgine
Message: 2 Date: Fri, 08 Sep 2017 16:27:43 -0700 From: Robert Shaw rsshaw@zoho.com To: "wikimedia-genealogy@lists.wikimedia.org" wikimedia-genealogy@lists.wikimedia.org Subject: [Wikimedia-genealogy] Structuring of genealogical information So there may be a range of ideas about what the project might produce (if it produces anything), one aspect of which is how the information about a person should be kept and presented.
...snippage...
Genealogists need to have the core data about their subjects, and since computers arrived they mostly have been transferring that core data about in some form of file, which is most always some dialect of GEDCOM. The widespread use of it, inadequate as it is in some ways, is highly useful to genealogists. Thus import and export in that format is needed, and structuring of the core person data in the contents of the system itself needs to be fundamental in the approach.
I might quibble about some of the details, but over all I have strong agreement with what you said Robert Shaw. There are multiple optional standards which improve on GEDCOM, but GEDCOM is the most-widely used dumbed-down exchange format. We should be aware the LDS and related groups are migrating away from it for storage - they are using richer proprietary representations, but also GEDCOMx - but as the de facto standard, with hundreds of common extensions, it is pretty much central to any data discussion.
But the biggest point of supporting a public standard is to avoid having to maintain that standard in-house. We could import/export GEDCOM, but actually use Gramps XML[1], and also export .gw and .tmg (and/or others.) By avoiding trying to maintain a standard we may reduce the costs associated with starting up and reinventing such a complex data standard, and we would avoid censure for being standard-agnostic for import/export.
Taking a quick turn through Packagist I see gedcom, gecomx, and webtrees libraries, as well as several self-contained units like Sam's and SilverStripe-genealogist.
Amgine
[1] https://gramps-project.org/wiki/index.php?title=Gramps_XML project repo https://github.com/gramps-project/gramps
It is starting to sound like a good way forward would be to work on updating WeRelate. This is sort of how I'm currently understanding things:
* A non-wiki (even non-MediaWiki) solution is unlikely to gain traction within the Wikimedia world, I think. Even though it might be a technically better way to go (i.e. use a tool that's built for the job). * Other structured data in Wikimedia is being done with Wikibase (i.e. Wikidata, structured-data-on-Commons, and the nacent structured support for Wiktionary). This would probably be the way to go if it weren't for the prevalence of Gedcom in genealogy. * There is an existing community, and good (open) licencing at WeRelate. This is similar to the Wikitravel/Wikivoyage situation, perhaps? And it's far better to work with existing systems than to strike out separately. * There are perhaps some flaws in the design and implementation of WeRelate, but some of these are in the process of being solved (such as the storing XML and wikitext in the same page data, which it sounds like will be a candidate for moving to multi-content revisions, once they're a thing). * Semantic MediaWiki can probably do most of this (and is, as can be seen with Familypedia). I guess I'm thinking that we shouldn't go down this path, because it already exists. I'm getting the idea that WeRelate is more widely used? Also, SMW has something of a reputation for creating very complicated wikis (i.e. the templates etc.), where with WeRelate that complexity is moved to MediaWiki-side code (i.e. PHP & JS) and so is more easily testable and upgradeable.
By the 'clunkiness' of WeRelate, and of the Gedcom schema in general, I really just meant all those edge cases where these things don't allow us to express things as elegantly as possible. Of course, that's *always* the case with software! I admit to the all-to-common programmer's foible of aiming for perfection and in doing so disregarding things that are quite good enough. :-) For example, having a while 'Family' namespace in WeRelate has always annoyed me, as it seems that it's a function of not being able to store the semantics of links in MediaWiki, and diffuses the places in which information is stored.
Anyway, I'm going to have a poke around with https://github.com/werelate/wiki and see what I can come up with. Perhaps set up the demo wiki as a demo of WeRelate software (although, I suspect we need to get it running on PHP 5.5 at least, first). Or a second demo.
— Sam.
On Sat, 9 Sep 2017, at 11:43 AM, Amgine wrote:
Digest response to James Mason and Robert Shaw, for which I apologize.
Message: 1 Date: Fri, 08 Sep 2017 14:09:10 -0400 From: James Mason jrm@slashmail.org To: "Discussion about the Wikimedia genealogy project." wikimedia-genealogy@lists.wikimedia.org I'm not quite sure what is meant by the remarks that GEDCOM structures - imposed on a Wiki - lead to something clunky. Are we talking about UI design, code implementation, maybe both?
Wow, I just wrote a 7 paragraph response to this, which is way too long and complex. Here is a brief synopsis:
The basic solutions are all a kluge - a way to work around the underlying structure of Mediawiki. This makes them slow to render on save, and usually both brittle and high maintenance. Basically you are storing data inside text which is parsed to html and then stored in a database - so no one can work with just the data directly.
A different solution is to write a Mediawiki extension to do everything a genealogy software does except the presentation layer, except it also has to at least do Create and Update so you still have some presentation. Which means you basically invented another genealogy wheel. If we are going to do this much work to bring genealogy data to Mediawiki we could save effort by reversing - add a free form text article to a genealogy software - which would then retain the benefits of data manipulation and surfacing.
So maybe a semantic MediaWiki basis would allow for WeRelate to be implemented without reliance on hacking the base code? Thereby less clunky?
The semantic relationships should allow for bi-directional relationships, but I have avoided SMW after my first experiments with it because it is mind-bendingly difficult for me to grasp. You could ask the good SMW folks in IRC at irc://chat.freenode.org/semantic-mediawiki (browser IRC client at http://webchat.freenode.net/?channels=semantic-mediawiki)
Amgine
Message: 2 Date: Fri, 08 Sep 2017 16:27:43 -0700 From: Robert Shaw rsshaw@zoho.com To: "wikimedia-genealogy@lists.wikimedia.org" wikimedia-genealogy@lists.wikimedia.org Subject: [Wikimedia-genealogy] Structuring of genealogical information So there may be a range of ideas about what the project might produce (if it produces anything), one aspect of which is how the information about a person should be kept and presented.
...snippage...
Genealogists need to have the core data about their subjects, and since computers arrived they mostly have been transferring that core data about in some form of file, which is most always some dialect of GEDCOM. The widespread use of it, inadequate as it is in some ways, is highly useful to genealogists. Thus import and export in that format is needed, and structuring of the core person data in the contents of the system itself needs to be fundamental in the approach.
I might quibble about some of the details, but over all I have strong agreement with what you said Robert Shaw. There are multiple optional standards which improve on GEDCOM, but GEDCOM is the most-widely used dumbed-down exchange format. We should be aware the LDS and related groups are migrating away from it for storage - they are using richer proprietary representations, but also GEDCOMx - but as the de facto standard, with hundreds of common extensions, it is pretty much central to any data discussion.
But the biggest point of supporting a public standard is to avoid having to maintain that standard in-house. We could import/export GEDCOM, but actually use Gramps XML[1], and also export .gw and .tmg (and/or others.) By avoiding trying to maintain a standard we may reduce the costs associated with starting up and reinventing such a complex data standard, and we would avoid censure for being standard-agnostic for import/export.
Taking a quick turn through Packagist I see gedcom, gecomx, and webtrees libraries, as well as several self-contained units like Sam's and SilverStripe-genealogist.
Amgine
[1] https://gramps-project.org/wiki/index.php?title=Gramps_XML project repo https://github.com/gramps-project/gramps
Wikimedia-genealogy mailing list Wikimedia-genealogy@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikimedia-genealogy
wikimedia-genealogy@lists.wikimedia.org