Gender and Living are "Fact" Types

[EssyGreen]

Living is currently both an attribute of a Person and also a Fact Type. Since it must have a date in order to be of any value I believe the living fact type is more accurate and the living attribute/flag is misleading and confusing.

Gender is currently only an attribute of a Person which means that it's validity cannot be cited and assessed as a "Fact". This means that sources which do not specify a Gender or conflicting Genders in different sources cannot be reconciled/assessed ("Concluded"). Therefore the Gender should be a "Fact" type.

PS: We could also do with more specific "Unknown" Gender types e.g. "Indeterminate" and "Unspecified" to distinguish between say a birth where the gender was not recorded vs a birth where the gender was medically unclear (see the use of "X" for this in Australian records).

[jralls]

+1 on Gender.

Living is used as a privacy flag in a lot of genealogy programs, and means "Living at the time these data were published". It might better be named "private", which is better reveals the intent.

[EssyGreen]

Living is used as a privacy flag in a lot of genealogy programs [...] It might better be named "private", which is better reveals the intent.

I'm happy with "Private"

[EssyGreen]

It has been pointed out elsewhere (#144) that:

For data exchange, I would think the data producer would be responsible for removing "private" data prior to making an exchange, and that only "public" data would be included in the exchange

If this is so, then the Living flag is a Fact Type and not a privacy flag and hence could have a date associated with it i.e. it becomes the equivalent of "Person X was known to be alive on this date". As such it would be like any other type of Conclusion being made by the researcher.

[jralls]

For data exchange, I would think the data producer would be responsible for removing "private" data prior to making an exchange, and that only "public" data would be included in the exchange

If this is so, then the Living flag is a Fact Type and not a privacy flag and hence could have a date associated with it i.e. it becomes the equivalent of "Person X was known to be alive on this date". As such it would be like any other type of Conclusion being made by the researcher.

Sorry, you're confusing the flag (which we agreed should be renamed "private") and the fact type, which nobody suggested should be removed.

That aside, the discussion in #144 was not about data on persons which shouldn't be shared with the public (though it might be shared among a trusted group of collaborators), it was about a strawman you raised in a discussion about having particular note types:

Or suppose the app wants to hide general/private notes to some users but make the rationale notes always available.

[EssyGreen]

you're confusing the flag (which we agreed should be renamed "private") and the fact type, which nobody suggested should be removed.

Ah yes sorry I forgot that living was already a Fact Type ... so what I should have said is if the intention is that there is no private data in the file then the Private flag by definition is superfluous.

the discussion in #144 was not about data on persons which shouldn't be shared with the public

The discussion was about sources (which may contain Persons)

[stoicflame]

I'd be okay with removing the living flag. We'll reach out to RootsMagic, Legacy, TMG, etc. to see how they feel about it.

[jralls]

We'll reach out to RootsMagic, Legacy, TMG, etc. to see how they feel about it.

While you're at it, see if you can get some of them to get involved directly.

[stoicflame]

While you're at it, see if you can get some of them to get involved directly.

Working on it.

We've had them in to meet with us on multiple occasions to discuss some of this stuff. They've got good stuff to contribute, and I wish they'd participate out on the forums here.

They seem willing, but the sense I get is that they don't have the time or resources to slog through all the comments in an attempt to get up-to-date on the issues. They feel like they need to understand the whole thread in order to contribute. We're working through some ideas to lower the entry barrier.

[jralls]

They feel like they need to understand the whole thread in order to contribute.

I sympathize. It took me a couple of weeks of reviewing the old issues to get a feel for where you'd come from, and we've covered a lot of ground in the almost 6 months since RootsTech, not all of it productive.

Maybe they'd be more comfortable with a forum or mailing list.

[stoicflame]

Maybe they'd be more comfortable with a forum or mailing list.

Yeah. Maybe. When I suggested it to them, they didn't get too excited.

[jralls]

Sounds like they don't really want to commit the resources to participating. You can bet that they'll commit resources to complaining about the results later, though. ;-(

[EssyGreen]

I suspect there is also an element of not wanting to risk leaking out their competitive strategies.

[stoicflame]

Sounds like they don't really want to commit the resources to participating. You can bet that they'll commit resources to complaining about the results later, though. ;-(

Indeed.

I suspect there is also an element of not wanting to risk leaking out their competitive strategies.

Oh there is definitely some of that, too.

It's funny. You talk to these guys one-on-one and they're happy to open up and share. You get them all in a room and it's like pulling teeth to get them to say anything.

[EssyGreen]

LOL. Not surprising really when their livelihood depends on them having one-up on the others.

[stoicflame]

Closed with 1b7ac55.

[jralls]

Umm, you were supposed to replace it with private. There does need to be a flag on Person to exclude the data from certain exports and reports -- or public display in the case of web trees.

[ghost]

John,

I really don't know what you are referring to. I do not recall anything that sounds like "gender and living" involved in the activities I looked at. Can you be more clear so that I understand? If I have done something improper, I certainly did not intend to do so

--- Original Message ---

From: "John Ralls" notifications@github.com Sent: May 13, 2013 4:21 PM To: "FamilySearch/gedcomx" gedcomx@noreply.github.com Subject: Re: [gedcomx] Gender and Living are "Fact" Types (#175)

Umm, you were supposed to replace it with private. There does need to be a flag on Person to exclude the data from certain exports and reports -- or public display in the case of web trees.

---

Reply to this email directly or view it on GitHub: https://github.com/FamilySearch/gedcomx/issues/175#issuecomment-17841579

[jralls]

John, I really don't know what you are referring to.

Not you, Ryan ( @stoicflame ). It's about his 1b7ac55 commit.

If you follow the hyperlinks in the comment you're replying to you'll see that they're comments earlier in the issue from Sarah ( @EssyGreen ) and me saying that private is important and doesn't carry the baggage that living did. In his change, Ryan removed living but didn't replace it with private.

I think your confusion might result from your having subscribed to this issue and then having gotten and email of my comment from Github and thinking that it's addressed to you personally. That's not the case. There are several people subscribed, and comments posted here are for everyone to read. Click the link at the bottom of the email (it's safe!) to see all of the comments in context.

[stoicflame]

Umm, you were supposed to replace it with private. There does need to be a flag on Person to exclude the data from certain exports and reports -- or public display in the case of web trees.

Ah. Sorry, I guess I missed that.

I'm kind of scared about defining a "private" flag because that means I have to explain to implementations what they're supposed to do with it. It seems like an app-specific thing. One app might say "private" meaning "don't show this" and another might say "private" and mean "don't share it with others", etc.

Can't we just let implementations not export private data?

[jralls]

Can't we just let implementations not export private data?

We can, but that's a bit of a limitation when one is using GedcomX to collaborate or to transfer one's database to another program. I agree that what "private" means is somewhat application-specific, but what isn't? Users who care about that (and there are enough of them that every genealogy program I know about offers some sort of "private" flag) take that behavior into consideration when selecting software.

[stoicflame]

If we put it in there, I don't know how to define the property better than this, do you?

name	description	data type	constraints
private	Whether the data has been identified as "private".	boolean	OPTIONAL. The definition of "private" is application-specific and outside the scope of this specification.

[mikkelee]

I'm a bit iffy on "private" flags, to me they seem like the evil bit. Once the material is exported, it's exported. I'd prefer that implementers advice their users and provide sane defaults when exporting to third parties.

Websites can decide to not show possibly-living persons (such as many do now, even in the absence of a Gedcom restriction notice), or only show to approved users.

Applications can export a subset of the tree, as determined by the user.

If we put it in there, I don't know how to define the property better than this, do you?

Me neither. Perhaps "Whether the user has identified the data as private." This way an application can use GedcomX for its internal storage, and strip entities with the private flag when exporting.

[jralls]

If we put it in there, I don't know how to define the property better than this, do you? OPTIONAL. The definition of "private" is application-specific and outside the scope of this specification.

How about OPTIONAL. User has flagged this Person's data for limited distribution or display. Actual behavior is application-specific and outside the scope of this specification.

[jralls]

Once the material is exported, it's exported.

Roger. Depends upon to whom you're exporting. If it's to yourself or your cousin with whom you're collaborating, you want to include the private people. If it's me, you probably don't. When you do share with your cousin you probably don't want the private flags stripped.

[mikkelee]

Sorry, didn't mean strip the flags, but exclude the persons with the flags. But yes, agreed. This way enforcement is outside the spec, and can be as simple as the application having a checkbox "include private persons in export" or something more complicated if an implementer desires.

[stoicflame]

38cb676