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(a)slashmail.org>
To: "Discussion about the Wikimedia genealogy project."
<wikimedia-genealogy(a)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(a)zoho.com>
To: "wikimedia-genealogy(a)lists.wikimedia.org"
<wikimedia-genealogy(a)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(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikimedia-genealogy