Add record matches information to documents connected to each profile to the API

I am also using the Geni API and miss support Record match.
Hope it will be included in the future!

To be a bit more specific: I might presume that you both are referring to 'confirmed' matches. (Might seem obvious to me, but I thought it worth making explicit.)
Akin to the current API support for getting the documents associated with (tagged to) a profile.

Aside: I don't think I'd be a supporter of allowing the API to 'confirm' proposed Smart-xxx matches. I can see allowing confirmed matches to be treated similarly to other 'tagged' documentation.

Yes, I meant "confirmed matches"!

And I agree that adding an API for confirming the matches would probably cause more harm than good.

I hate confirmed matches of two main reasons: They are way too dominating on the profiles and secondly profiles in other trees are absolutely not classified as sources, they are even downing real sources attached to the profiles.

The good thing I can say about confirmed record matches is that it's a quick way to add a reference - but agree with Bjørn about their overweening page imperialism.

I mainly use matches to church books. Matches to other trees are normally not useful.

If they are dominating on profile pages, that's just a criticism of Geni.com's page layout not of the function itself.

Addition:

The alternative to matches (which I otherwise have to use) is to write the match references in the description text in the profile.

I know there are a source section in the geni database, where they really should belong, but adding them there are much too cumbersome to do it normally.

I am using the source section to its fullest. Confirmed record matches are shown alongside regular sources, and that’s why I also want them exposed in the API.

Profile matches (smart match) is not a source, and should is not be included in API. In addition confirmed matches of any kind take of way to much space on the main profile page.

There are two kinds of matches. The primary ones, they are brown and the matches with MH and other familytree sites.

The confirmed record matches with other family sites should be public by API, because on other family sites they are also public. And some automatic checking is very wise. Otherwise we will have too many false matches.

And of course the matches should be on a subpage or viewable by API, but only on request by the user or script.

If it not viewable by API, then the about field will be used for it by scripts and managers. In the manual "Geni for Dumbies" dutch version is that the spot where it should be. Otherwise is it not viewable by all the users and API.

I must say I did not understand this question or request at first. But now I have created an IMHO about it.

If Geni would include smart matches to sources it would give away information a pro user is paying for.

Thanks, Jeroen!

Just to make absolutely sure we are talking about the same thing...
On my great grandmother's profile, for example:

Hanna Henrietta Erikson

I have confirmed three church book pages , while there are five matches with MH trees.

It's the confirmed church book matches I'm primarily talking about.

Is it the non-confirmed matches that only Pro users should see?

We are discussing the same point, but we should make a list what kind of matches we want to be added to the API and which not.

The smart matches are only fullly viewable by Pro users.

Church book pages are record matches so that is a good example that should included in the API and should be public for basic users and search engines like Google.

On the last question of Kenneth Ekman I can not give a yes or no answer.

It is the (non-confirmed) smartmatches that only the Pro users see completely and can use,

Ok, thanks, Jeroen. Good that we are aligned. This is what I thought too.

The next step is to make a RFC. An official Request for Change so Geni staff understand that this a serious request and is supported by several pro users and curators.

Ok, sounds good. I work with software development so if you want me to review something, I would be happy to help.

I will use MH as a short of MyHeritage. And this discussion is getting very technical.

I have checked it out and the information about the confirmed record matches as it is in the userinterface on Geni is the same for the basic user as the pro user as for the curators. But the links in the record matches are links to MH and if you are not logged in there or don;t have a data.
The curators and the pro users with the full rights on MH see the same on MH on the MH.

The problem is that if you don't have a full data plan subscription on MH the links to the datarecords are a dead end. A basic user or the Geni API will hit the paywall.

IMHO proof is very important and the the documents are copy right free so that is not the problem. The problem is that the documents are found by a smartmatch that is copyrighted search engine and the direct links it has found also.

So still the discussion is what information should be included in the Geni API and remember it is not the MH API that is under discussion.

The big problem is that the two websites Geni and MH are highly intergrated.

Yes, I realize this, but I assume we could still show the information about the church book, the name, the place, the page number, which is useful also without an MH subscription, right? The links might only work for users with an MH data subscription, but the rest is in my view, the most important part.

And, we only talk about confirmed matches, right, so the algorithm that picked the proposed links shouldn't matter, as a human has confirmed it?

So I see that this discussion unfortunately came to an end more than 2 years ago with seemingly no progress or resolution.

Unless anyone has an update of some kind?