Gender and Living are "Fact" Types #175

Closed
EssyGreen opened this Issue Jun 28, 2012 · 25 comments

Comments

Projects
None yet
4 participants

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).

Contributor

jralls commented Jun 28, 2012

+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.

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"

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.

Contributor

jralls commented Jul 10, 2012

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.

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)

Owner

stoicflame commented Jul 10, 2012

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.

Contributor

jralls commented Jul 10, 2012

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.

Owner

stoicflame commented Jul 10, 2012

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.

Contributor

jralls commented Jul 10, 2012

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.

Owner

stoicflame commented Jul 10, 2012

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.

Contributor

jralls commented Jul 11, 2012

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. ;-(

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

Owner

stoicflame commented Jul 11, 2012

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.

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

Owner

stoicflame commented May 8, 2013

Closed with 1b7ac55.

stoicflame closed this May 8, 2013

Contributor

jralls commented May 13, 2013

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

ghost commented May 14, 2013

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:
#175 (comment)

Contributor

jralls commented May 14, 2013

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.

Owner

stoicflame commented May 14, 2013

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?

Contributor

jralls commented May 14, 2013

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.

Owner

stoicflame commented May 14, 2013

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.

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.

Contributor

jralls commented May 14, 2013

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.

Contributor

jralls commented May 14, 2013

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.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment