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
I fully agree that a genealogy website needs structure
(parent/child/sibling/event etc), though there should be room for free-form
narrative as part of any individual's page.
Familypedia has been using Semantic MediaWiki and Semantic Forms (which
will, we trust, be upgraded eventually by our host so that it has the
current name "Page Forms") since 2009. It has over 60,000 articles about
individuals and tens of thousands of subpages automatically displaying
people's ancestry trees or descendant tables for four generations (subject
to data availability). Example at
http://familypedia.wikia.com/wiki/Charlemagne/tree It can do complex-looking
searches such as tabulating (in a way that allows sorting by a particular
column) all Familypedia people born in Pennsylvania whose father was stated
to be born between 1849 and 1875:
http://familypedia.wikia.com/wiki/Semantic_MediaWiki/demo_query-subquery And
it has pages for several thousand places (villages, counties, nations, etc)
automatically tabulating the people who had events such as birth and
marriage at the place.
However, I also agree with one or more correspondents that such a wiki
should be able to handle GEDCOM files. Familypedia people have tried, with
little success.
So on the Demo wiki I've asked for semantic extensions to be made available
and I will start agitating for programmers to work out how to import GEDCOM
files and siphon their data into individuals' pages with minimum
duplication. A tall order, but several big genealogy websites have ways of
doing it, generally by alerting the contributor to apparent duplications and
offering to merge the individuals' pages. The WikiTree experts may be able
to help there. Probably WeRelate people can too.
Robin F. Patterson, Plimmerton, Porirua City, New Zealand
http://familypedia.wikia.com/wiki/User:Robin_Patterson
(I hope you folks are pleased that I cut off all of the earlier stuff; I
hope other contributors will similarly trim so as to leave little apart from
the points they are answering.)
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. Sam recently wrote:
---- On Thu, 07 Sep 2017 17:46:43 -0700 Sam Wilson <sam(a)samwilson.id.au> wrote ----
I'm not sure I agree that genealogical research is *uniquely*
structured. It's no more sturctured than, say, writing histories of
companies, or political parties, or railways... I mean that there are
always requirements for strucutred data in any research, but that we
don't bother with bespoke tools for most of them. I think primarily
because the ultimate desired output is readable, linear prose, with
images, figures etc. — I think this is my usual goal with genealogy too.
I view the aim to be something more structured than a collection of pages of unstructured prose, as might be appropriate for histories of railways or Pokemon characters, or for an encyclopedia. It certainly would be nice to have a biography of an ancestor in well-written prose, with photos and maybe circles and arrows and graphs. I do see a need to allow for free form prose and graphics about people so that such biographies can be constructed and preserved.
However the bulk of family history and genealogy doesn't, and often can't, get to that level of knowledge and detail. As we go back in time, less and less information is available. Genealogists are used to dealing with this, and have been using structured data and tools to support the research and analysis since long before computers.
That's why I think the project should produce a system that at its core has structured data, but allows supplementation with free prose where that can be supplied. At the core, every person has a mother and a father, and very often has other relationships such as siblings and children. Every person was born somewhere on some day and died (or will die) somewhere and some time. These are things that are key to researching, establishing, and convincing one another that particular people are related,
The project can serve varying needs, but a major need is to serve as a repository and presentation of the relationship data and the reasons those presented relationships are correct. With hardly any conflict, it can also support producing and reading biographies.
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.
Tell us more about CRUD data interfaces.
Mack
Sent from my HTC
----- Reply message -----
From: wikimedia-genealogy-request(a)lists.wikimedia.org
To: <wikimedia-genealogy(a)lists.wikimedia.org>
Subject: Wikimedia-genealogy Digest, Vol 5, Issue 5
Date: Fri, Sep 8, 2017 8:00 AM
Send Wikimedia-genealogy mailing list submissions to
wikimedia-genealogy(a)lists.wikimedia.org
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.wikimedia.org/mailman/listinfo/wikimedia-genealogy
or, via email, send a message with subject or body 'help' to
wikimedia-genealogy-request(a)lists.wikimedia.org
You can reach the person managing the list at
wikimedia-genealogy-owner(a)lists.wikimedia.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Wikimedia-genealogy digest..."
Today's Topics:
1. Re: Is the delivery of software fundamental to this project?
(Amgine)
2. Re: Is the delivery of software fundamental to this project?
(Sam Wilson)
3. tiny URL (Sam Wilson)
----------------------------------------------------------------------
Message: 1
Date: Thu, 7 Sep 2017 17:30:43 -0700
From: Amgine <amgine(a)wikimedians.ca>
To: wikimedia-genealogy(a)lists.wikimedia.org
Subject: Re: [Wikimedia-genealogy] Is the delivery of software
fundamental to this project?
Message-ID: <8219628e-99cb-f046-5250-c4289f381c91(a)wikimedians.ca>
Content-Type: text/plain; charset=utf-8
Thanks for the response Sam! Again I am replying to a digest, and
apologize...
> Date: Thu, 07 Sep 2017 15:37:20 +0800
> From: Sam Wilson
>
> I certainly agree with you about the NIH syndrome within the Wikimedia
> world. (I think it's getting better though, and I think a lot of it is
> part of the general PHP/web-dev community too, and not specific to
> MediaWiki.) I really don't think we need yet another software solution
> for genealogy! However... :-)
> I think I basically take as my starting point "base MediaWiki". As in:
> there's a great flexibility in a website that is basically just freeform
> text boxes into which you can put whatever. At its heart, a wiki is free
> and open and really easy to just jump into and start putting content up.
> That's why we love 'em! And I think it's a good platform for genealogy:
> we can write whatever we need to, and collaborate with others, and it's
> not constrained by any software-imposed structure.
Genealogy data is not free-form. It is extremely structured, rather like
Wiktionary's data. To represent that data in wiki syntax will require
extensive templating and modules, resulting in the kind of
professional-only-contributors you find at Wiktionary - and the
unpleasant work-arounds required as pages bump up against the
limitations of Mediawiki (e.g. [[wikt:en:water]].) I've been working
with that project for a dozen+ years, and it is now so beginner-hostile
I do not feel qualified to make more than the most-minor edits, and most
of those assisted by js gadgets.
I would hate to see a genealogy project go down that path.
Since most genealogy practice works with CRUD data interfaces, and this
has been extremely successful in helping people of all ages and
technical experience begin their personal genealogies on their desktops,
I think we should focus on that for the actual genealogy work. We can
leverage Wikisource and commons for documents/sources; for example
transcription of government census, voter rolls. Other elements might
also better be 'outsourced', like geolocation names in temporal context.
But just in case you are missing the free-form text box, WebTrees allows
hand-editing of GED textual representation, either of a whole entry or
any single object. Each edit pop-up and record includes a link to edit
as Raw GED. (I do not believe WebTrees actually store entries in GED
format, so your edits will round-trip into database representations much
as Parsoid does for MW syntax.)
Amgine
------------------------------
Message: 2
Date: Fri, 08 Sep 2017 08:46:43 +0800
From: Sam Wilson <sam(a)samwilson.id.au>
To: wikimedia-genealogy(a)lists.wikimedia.org
Subject: Re: [Wikimedia-genealogy] Is the delivery of software
fundamental to this project?
Message-ID:
<1504831603.958760.1099016000.0B14F984(a)webmail.messagingengine.com>
Content-Type: text/plain; charset="utf-8"
Hm, yes, I really do see the multiple sides to this! :-) It's very
interesting. Thank you for going into it all.
I'm not sure I agree that genealogical research is *uniquely*
structured. It's no more sturctured than, say, writing histories of
companies, or political parties, or railways... I mean that there are
always requirements for strucutred data in any research, but that we
don't bother with bespoke tools for most of them. I think primarily
because the ultimate desired output is readable, linear prose, with
images, figures etc. — I think this is my usual goal with genealogy too.
Perhaps that's where I'm understanding things wrong.
Wikipedia might be a pain to edit (although, I think it's getting
easier) but it *is* easy to read. I think it's worth keeping the
audiences in mind when talking about different approaches to a genealogy
project.
We could look at setting up a demo Webtrees site too, if we want. :-)
The other thing, of WeRelate's approach of forcing Gedcom structures
into MediaWiki, I still feel is a bit clunky... I'm very open to being
convinced though! I have the beginnings of some code here that was about
syncing trees off werelate into a modern WeRelate extension; it could be
resurrected.
—sam
On Fri, 8 Sep 2017, at 08:30 AM, Amgine wrote:
> Thanks for the response Sam! Again I am replying to a digest, and
> apologize...
> > Date: Thu, 07 Sep 2017 15:37:20 +0800
> > From: Sam Wilson
> >
> > I certainly agree with you about the NIH syndrome within the Wikimedia
> > world. (I think it's getting better though, and I think a lot of it is
> > part of the general PHP/web-dev community too, and not specific to
> > MediaWiki.) I really don't think we need yet another software solution
> > for genealogy! However... :-)
> > I think I basically take as my starting point "base MediaWiki". As in:
> > there's a great flexibility in a website that is basically just freeform
> > text boxes into which you can put whatever. At its heart, a wiki is free
> > and open and really easy to just jump into and start putting content up.
> > That's why we love 'em! And I think it's a good platform for genealogy:
> > we can write whatever we need to, and collaborate with others, and it's
> > not constrained by any software-imposed structure.
>
> Genealogy data is not free-form. It is extremely structured, rather like
> Wiktionary's data. To represent that data in wiki syntax will require
> extensive templating and modules, resulting in the kind of
> professional-only-contributors you find at Wiktionary - and the
> unpleasant work-arounds required as pages bump up against the
> limitations of Mediawiki (e.g. [[wikt:en:water]].) I've been working
> with that project for a dozen+ years, and it is now so beginner-hostile
> I do not feel qualified to make more than the most-minor edits, and most
> of those assisted by js gadgets.
>
> I would hate to see a genealogy project go down that path.
>
> Since most genealogy practice works with CRUD data interfaces, and this
> has been extremely successful in helping people of all ages and
> technical experience begin their personal genealogies on their desktops,
> I think we should focus on that for the actual genealogy work. We can
> leverage Wikisource and commons for documents/sources; for example
> transcription of government census, voter rolls. Other elements might
> also better be 'outsourced', like geolocation names in temporal context.
>
> But just in case you are missing the free-form text box, WebTrees allows
> hand-editing of GED textual representation, either of a whole entry or
> any single object. Each edit pop-up and record includes a link to edit
> as Raw GED. (I do not believe WebTrees actually store entries in GED
> format, so your edits will round-trip into database representations much
> as Parsoid does for MW syntax.)
>
> Amgine
>
>
>
> _______________________________________________
> Wikimedia-genealogy mailing list
> Wikimedia-genealogy(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikimedia-genealogy
------------------------------
Message: 3
Date: Fri, 08 Sep 2017 15:23:19 +0800
From: Sam Wilson <sam(a)samwilson.id.au>
To: Wikimedia Genealogy <wikimedia-genealogy(a)lists.wikimedia.org>
Subject: [Wikimedia-genealogy] tiny URL
Message-ID:
<1504855399.1836036.1099264352.238D7AF9(a)webmail.messagingengine.com>
Content-Type: text/plain; charset="utf-8"
I made a tiny URL for the Meta-Wiki page:
http://tinyurl.com/wikigenealogy — just recording the fact here in case
anyone else needs such a thing. (I know tiny URLs are bad, but I wanted
a thing to put on a piece of paper! :-) )
One day we'll be able to use https://w.wiki but I dunno when...
------------------------------
Subject: Digest Footer
_______________________________________________
Wikimedia-genealogy mailing list
Wikimedia-genealogy(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikimedia-genealogy
------------------------------
End of Wikimedia-genealogy Digest, Vol 5, Issue 5
*************************************************
On 2017-09-08 05:00, wikimedia-genealogy-request(a)lists.wikimedia.org wrote:
> Message: 2
> Date: Fri, 08 Sep 2017 08:46:43 +0800
> From: Sam Wilson <sam(a)samwilson.id.au>
> To: wikimedia-genealogy(a)lists.wikimedia.org
> Subject: Re: [Wikimedia-genealogy] Is the delivery of software
> fundamental to this project?
>
> Hm, yes, I really do see the multiple sides to this! :-) It's very
> interesting. Thank you for going into it all.
>
> I'm not sure I agree that genealogical research is *uniquely*
> structured. It's no more sturctured than, say, writing histories of
> companies, or political parties, or railways... I mean that there are
> always requirements for strucutred data in any research, but that we
> don't bother with bespoke tools for most of them. I think primarily
> because the ultimate desired output is readable, linear prose, with
> images, figures etc. — I think this is my usual goal with genealogy too.
> Perhaps that's where I'm understanding things wrong.
>
> Wikipedia might be a pain to edit (although, I think it's getting
> easier) but it *is* easy to read. I think it's worth keeping the
> audiences in mind when talking about different approaches to a genealogy
> project.
>
> We could look at setting up a demo Webtrees site too, if we want. :-)
>
> The other thing, of WeRelate's approach of forcing Gedcom structures
> into MediaWiki, I still feel is a bit clunky... I'm very open to being
> convinced though! I have the beginnings of some code here that was about
> syncing trees off werelate into a modern WeRelate extension; it could be
> resurrected.
>
> —sam
If I understand your argument correctly, you are proposing biography
articles, with or without genealogy data (possibly implicit in
templates.) That would certainly be more readable, both at the wikitax
and as an article.
That is not at all what I had envisioned this project would be about.
In that use case, wiki would certainly be possible. I suspect the
'clunky' model of WeRelate - however implemented (see Familypedia) - is
pretty much inevitable.
Amgine
I made a tiny URL for the Meta-Wiki page:
http://tinyurl.com/wikigenealogy — just recording the fact here in case
anyone else needs such a thing. (I know tiny URLs are bad, but I wanted
a thing to put on a piece of paper! :-) )
One day we'll be able to use https://w.wiki but I dunno when...
Thanks for the response Sam! Again I am replying to a digest, and
apologize...
> Date: Thu, 07 Sep 2017 15:37:20 +0800
> From: Sam Wilson
>
> I certainly agree with you about the NIH syndrome within the Wikimedia
> world. (I think it's getting better though, and I think a lot of it is
> part of the general PHP/web-dev community too, and not specific to
> MediaWiki.) I really don't think we need yet another software solution
> for genealogy! However... :-)
> I think I basically take as my starting point "base MediaWiki". As in:
> there's a great flexibility in a website that is basically just freeform
> text boxes into which you can put whatever. At its heart, a wiki is free
> and open and really easy to just jump into and start putting content up.
> That's why we love 'em! And I think it's a good platform for genealogy:
> we can write whatever we need to, and collaborate with others, and it's
> not constrained by any software-imposed structure.
Genealogy data is not free-form. It is extremely structured, rather like
Wiktionary's data. To represent that data in wiki syntax will require
extensive templating and modules, resulting in the kind of
professional-only-contributors you find at Wiktionary - and the
unpleasant work-arounds required as pages bump up against the
limitations of Mediawiki (e.g. [[wikt:en:water]].) I've been working
with that project for a dozen+ years, and it is now so beginner-hostile
I do not feel qualified to make more than the most-minor edits, and most
of those assisted by js gadgets.
I would hate to see a genealogy project go down that path.
Since most genealogy practice works with CRUD data interfaces, and this
has been extremely successful in helping people of all ages and
technical experience begin their personal genealogies on their desktops,
I think we should focus on that for the actual genealogy work. We can
leverage Wikisource and commons for documents/sources; for example
transcription of government census, voter rolls. Other elements might
also better be 'outsourced', like geolocation names in temporal context.
But just in case you are missing the free-form text box, WebTrees allows
hand-editing of GED textual representation, either of a whole entry or
any single object. Each edit pop-up and record includes a link to edit
as Raw GED. (I do not believe WebTrees actually store entries in GED
format, so your edits will round-trip into database representations much
as Parsoid does for MW syntax.)
Amgine
I certainly agree with you about the NIH syndrome within the Wikimedia
world. (I think it's getting better though, and I think a lot of it is
part of the general PHP/web-dev community too, and not specific to
MediaWiki.) I really don't think we need yet another software solution
for genealogy! However... :-)
I think I basically take as my starting point "base MediaWiki". As in:
there's a great flexibility in a website that is basically just freeform
text boxes into which you can put whatever. At its heart, a wiki is free
and open and really easy to just jump into and start putting content up.
That's why we love 'em! And I think it's a good platform for genealogy:
we can write whatever we need to, and collaborate with others, and it's
not constrained by any software-imposed structure.
Certainly, I see the attraction with software like Webtrees that
provides lots of structure, but I guess it feels a bit different to the
open wiki way of things. I think WeRelate tries to walk the line between
fully-wiki and fully-structured, and does it pretty well. I've attempted
a couple of times to work on its code and bring it up to date, but
decided it would take more time than I've got, and there isn't a
community of developers working on it.
Anyway, that's all stuff we need to talk about more I'm sure! In the
meantime I've set up a demo wiki:https://tools.wmflabs.org/genealogy/wiki/Main_Page
that we can install various things on if we want to talk about them in
more concrete terms.
— Sam.
On Sat, 2 Sep 2017, at 09:31 PM, Amgine wrote:
> Sorry about the digest response. Footnotes at bottom of msg.
>
>> Message: 1 Date: Thu, 31 Aug 2017 13:50:29 -0400 From: James Mason
>> <jrm(a)slashmail.org> To: "Discussion about the Wikimedia genealogy
>> project." <wikimedia-genealogy(a)lists.wikimedia.org> Several
>> different systems have been put forward as candidates to be "the"
>> Wikimedia genealogy project. Of those, several have been in
>> existence for a number of years and are in regular use. Yet I have
>> seen very little on the question of why any of those may or may not
>> have been chosen as a starting point.
>>
> ... In the WMF-sphere there is a strong opposition to NMH/NFH (Not
> Made Here/Not From Here) solutions, even standing the middle of a
> wheel graveyard. Witness Flow when there are literally hundreds of drop-
> in forum/communication systems which can be implemented modularly such
> as PHPBB. My personal choice of using WebTrees[1] was specifically to
> allow an unlimited number of contributors to work on a single GED, and
> allow an unlimited number of GEDs to be hosted/displayed. It is not a
> wiki. It has some wiki-like characteristics. It could become a wiki. I
> doubt it is currently ready to scale. On the other hand, it would
> work extremely well as an interim, and is able to import/export
> standard and non-standard GED.
>
>> Message: 2 Date: Fri, 01 Sep 2017 08:15:04 +0800 From: Sam Wilson
>> <sam(a)samwilson.id.au> To: wikimedia-genealogy(a)lists.wikimedia.org
>> Subject: Re: [Wikimedia-genealogy] Is the delivery of software
>> fundamental to this project? ... WeRelate ... Wikidata as a central
>> repository ... My personal approach these days is ...
>>
> To painfully refactor: WeRelate has content and community, and other
> good/bad things. Wikidata, if possible, requires creating a new
> genealogy data standard [mandatory reference to
> https://xkcd.com/927/]. Federation seems a good approach. I am less-
> keen on thinking about forking a community, although forking their
> content has some interesting possibilities. Wikidata has been pretty
> much useless or a disaster for sister projects other than interwiki
> links - and even that has semantic issues. (imo: this is due a lack of
> interest/resources in supporting non-wikipedia efforts, not that
> Wikidata cannot do a stellar job.) So, much against my philosophy, I
> can agree there is a need for software development: a decentralized
> federation for node searching/sharing/indexing, self-healing?
> Preferably with a platform agnostic api, so multiple GUI and engines
> can be built. But I would rather work with the very large pile of
> genealogy wheels than start something entirely new. Amgine [1] On
> Github: https://github.com/fisharebest/webtrees Official:
> https://www.webtrees.net/ Wiki: https://wiki.webtrees.net/
>> _________________________________________________
> Wikimedia-genealogy mailing list
> Wikimedia-genealogy(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikimedia-genealogy
Sorry about the digest response. Footnotes at bottom of msg.
> Message: 1
> Date: Thu, 31 Aug 2017 13:50:29 -0400
> From: James Mason <jrm(a)slashmail.org>
> To: "Discussion about the Wikimedia genealogy project."
> <wikimedia-genealogy(a)lists.wikimedia.org>
>
> Several different systems have been put forward as candidates to be
> "the" Wikimedia genealogy project. Of those, several have been in
> existence for a number of years and are in regular use. Yet I have seen
> very little on the question of why any of those may or may not have been
> chosen as a starting point.
...
In the WMF-sphere there is a strong opposition to NMH/NFH (Not Made
Here/Not From Here) solutions, even standing the middle of a wheel
graveyard. Witness Flow when there are literally hundreds of drop-in
forum/communication systems which can be implemented modularly such as
PHPBB.
My personal choice of using WebTrees[1] was specifically to allow an
unlimited number of contributors to work on a single GED, and allow an
unlimited number of GEDs to be hosted/displayed. It is not a wiki. It
has some wiki-like characteristics. It could become a wiki. I doubt it
is currently ready to scale.
On the other hand, it would work extremely well as an interim, and is
able to import/export standard and non-standard GED.
> Message: 2
> Date: Fri, 01 Sep 2017 08:15:04 +0800
> From: Sam Wilson <sam(a)samwilson.id.au>
> To: wikimedia-genealogy(a)lists.wikimedia.org
> Subject: Re: [Wikimedia-genealogy] Is the delivery of software
> fundamental to this project?
>
> ...
> WeRelate
> ...
> Wikidata as a central
> repository
> ...
> My personal approach these days is ...
To painfully refactor: WeRelate has content and community, and other
good/bad things. Wikidata, if possible, requires creating a new
genealogy data standard [mandatory reference to https://xkcd.com/927/].
Federation seems a good approach.
I am less-keen on thinking about forking a community, although forking
their content has some interesting possibilities. Wikidata has been
pretty much useless or a disaster for sister projects other than
interwiki links - and even that has semantic issues. (imo: this is due a
lack of interest/resources in supporting non-wikipedia efforts, not that
Wikidata cannot do a stellar job.)
So, much against my philosophy, I can agree there is a need for software
development: a decentralized federation for node
searching/sharing/indexing, self-healing? Preferably with a platform
agnostic api, so multiple GUI and engines can be built.
But I would rather work with the very large pile of genealogy wheels
than start something entirely new.
Amgine
[1] On Github: https://github.com/fisharebest/webtrees Official:
https://www.webtrees.net/ Wiki: https://wiki.webtrees.net/
I read your conversations, and I see your points.
If we had something to work with, and uncover the faults, then us
'watchers' can be having a small share in helping you! Mack
Irving "MACK" Baxter "Time Indefinite
he has put
8971 Pardee Hollow Road in the hearts of
men..."
Wayland, NY 14572
Ecclesiastes 3:11
* Home Ph*. 585-*534-9852 Text-* G-Voice # --
*585**-204-0504*
On Sat, Sep 2, 2017 at 8:00 AM, <
wikimedia-genealogy-request(a)lists.wikimedia.org> wrote:
> Send Wikimedia-genealogy mailing list submissions to
> wikimedia-genealogy(a)lists.wikimedia.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.wikimedia.org/mailman/listinfo/wikimedia-genealogy
> or, via email, send a message with subject or body 'help' to
> wikimedia-genealogy-request(a)lists.wikimedia.org
>
> You can reach the person managing the list at
> wikimedia-genealogy-owner(a)lists.wikimedia.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Wikimedia-genealogy digest..."
>
>
> Today's Topics:
>
> 1. Re: Is the delivery of software fundamental to this project?
> (James Mason)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 01 Sep 2017 11:57:52 -0400
> From: James Mason <jrm(a)slashmail.org>
> To: sam(a)samwilson.id.au
> Cc: "Discussion about the Wikimedia genealogy project."
> <wikimedia-genealogy(a)lists.wikimedia.org>
> Subject: Re: [Wikimedia-genealogy] Is the delivery of software
> fundamental to this project?
> Message-ID: <a3565c2b902568905123b9f06f9df49c(a)slashmail.org>
> Content-Type: text/plain; charset="utf-8"
>
> I'm concerned that we're trying to find a perfect media-wiki software
> solution - but there aren't enough people listening to know if we've
> arrived. In any case - the real truth is you never get to perfect. I
> think we find something that's good enough to start - hopefully a user
> community starts to gel around that - then we evolve over time to
> something better (but probably never perfect).
>
> I certainly have a personal preference for WeRelate - I think it gets a
> number of important things right - but the dated wiki base is becoming a
> problem. A key to understanding WeRelate is that DallanQ started with
> the idea of maintaining the semantics of an uploaded GEDCOM. With that
> in mind - I think most everything you find on the site starts to make
> sense.
>
> The WR software is freely available - have you considered starting from
> that base instead? Is there something that's fundamentally wrong - such
> that attempting to evolve a WR 2.0 on new wiki base software - isn't a
> reasonable way to go?
>
> -jrm
>
> On 2017-08-31 20:15, Sam Wilson wrote:
>
> > This is a really good point.
> >
> > I'm certainly not keen to develop yet another software system for
> genealogy (although, I've tinkered with doing so and am using such software
> as one of my main research systems at the moment... oops). But I think
> there's space for multiple options.
> >
> > As far as existing systems go, I would say that WeRelate is the best:
> it's a wiki, and so very flexible; it's big and has an active user base;
> it's properly licenced. The reason I don't currently use it personally is
> that its software is very out of date and so hard to work with (it's
> basically a fork of MediaWiki from ten years ago), and I feel like the
> software tries to do things (such as citation management) that I don't
> believe should be part of genealogy software.
> >
> > The other thing I feel might be possible is Wikidata as a central
> repository (and I know you say it can't because of notability, but I'm not
> so sure; there's more to be discussed here I think). The problem then is
> that there's nowhere for the 'other' genealogy data to go, apart from
> notable individuals who can go on Wikipedia.
> >
> > My personal approach these days is that everyone should host their own
> wikis, and pull what data they can from Wikidata and link where they can to
> Wikipedia.
> >
> > All up, I really do think that some software development, on some front,
> is required. (Hmm... but then, I'm a software engineer, so everything does
> rather look like a code-shaped nail to me!)
> >
> > --Sam.
> >
> > On Fri, 1 Sep 2017, at 01:50 AM, James Mason wrote:
> >
> >> Several different systems have been put forward as candidates to be
> "the" Wikimedia genealogy project. Of those, several have been in
> existence for a number of years and are in regular use. Yet I have seen
> very little on the question of why any of those may or may not have been
> chosen as a starting point.
> >>
> >> It now sounds like more effort is being invested in a project to
> develop another such system - but I wonder how it can succeed. Since there
> isn't clarity about why any of the existing projects were not selected -
> how can another hope to be "more" successful. I'm not trying to throw cold
> water on the good intentions of people who wish to design or implement such
> software - but neither would I want to see their efforts come to naught.
> >>
> >> I wonder if the better approach is to try to select a reasonable
> interim system? With the dual goals of beginning to accumulate a genealogy
> database AND serving as an example against which new software ideas can be
> compared? Or perhaps - taking the approach of creating something rather
> more like Wikidata - intended more as a centralized genealogy data
> repository usable by a variety of consumers (I know LDS was working on
> something like this - but I don't know where it stands at present). (FYI -
> I assume that Wikidata proper really can't be such a database - on the
> basis of notability requirements - however limited).
> >>
> >> Please forgive me if my remarks are hopelessly out of step with what
> others may be thinking... :) !
> >>
> >> -jrm
> >>
> >> James Mason; Nashua, NH, USA
> >>
> >> _______________________________________________
> >> Wikimedia-genealogy mailing list
> >> Wikimedia-genealogy(a)lists.wikimedia.org
> >> https://lists.wikimedia.org/mailman/listinfo/wikimedia-genealogy
> >
> > _______________________________________________
> > Wikimedia-genealogy mailing list
> > Wikimedia-genealogy(a)lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikimedia-genealogy
>