You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
From an ontological (Basic Formal Ontology) at the #43, the main point could be described as "metadata about aggregated collection of humans" with reference key 1:1 compatible with P-Codes (which at the moment uses 1603:16:{unm49}:{cod_ab_level}:{unpcode}). Under this logic, a prefix different from 1603:16: would be used, but as much as possible, by the dedicated #43 prefix alone, it should be possible to make the mappings.
Both for #43 and this new topic, as soon as the numerical taxonomy is drafted, the new information becomes metadata to the main keys. However, since eventually such nodes could become very overloaded with information witch would not be mere linguistic and some types of "metadata about aggregated collection of humans" could be thematic and overly specialized, we migth need to create a default infix (like the number 1) to represent the most generic term (such as for #43, assuming NN as base, the population statistics could become 1603:NN:1:{unm49}:{cod_ab_level}:{unpcode}) and when new relevant thematic groups appears (but would still be "metadata about aggregated collection of humans'') the way to distribute the data could have different packages.
Under ideal circumstances, since #43 would be an aggregated version about this issue, whatever would be the infix "1", they could be the same. So let's say "healthcare workers" would be relevant to receive an infix like "123", under #43, the metadata would be about collection (by region), and on this topic, they would be at individual level.
Relevance of this namespace
By having a dedicated prefix designed to have data about individual humans, both sensitive and public data, non-anonymized and anonymized data, would ideally appear in a predictable way. The numeric prefix alone could allow decisions to be made (such as enforce more checks). Most of the time, the type of data here should not be public. But there are cases where is relevant to have suggested prefix for data which can be public (even if eventually over the time laws could be changed, and datasets requested to be deleted):
(generic reason) having this reduce need of users create other ad-hoc numeric prefixes and need to understand deeply how to organize ontology
Some data about individuals can be public, even if personal information (which could be used as key) should not
Examples:
politician responsible for an administrative region by Wikidata public Q ID
data about vaccinated people (Brazil do have 169 millions of individuals vaccinated, and the anonymized data is public; the dataset is over 100GB, but such type of data can exist)
(indirect need) other datasets with final user data might need to group what is individual information (such as hospital patient, or victim of a crime) and even if the key is some sort of cryptographic secure hash, "by pointing" to this namespace, would help tools to understand that is about a person.
Sometimes such data would be exchanged outside a country (for example, to have help about some sort of epidemic) so this predictability could allow both who agree what can be exchanged and which level of detail do not need to have access to the data. Also other regions could know that the biggest difference between data from outside the region and their own region could be information which can also be public (like information of region), but even other related information could also have some additional level of anonymity.
The biggest argument here is that the mere default namespace does allow automation and checks for data that not even the decision makers of what is allowed should have access. And also the way the data is stored in the end user side could also have some other special actions (like the target region giving aid monitor how the data is used or delete it after some time)
However, realistic speaking, this topic would be by far the most stricter to represent data which should have higher protection when exchanged outside the place allowed to use own data and as public documentation on how to use own data with other public resources. Considering #43 maybe some infix to differentiate for example who is doctor or police officer and who is patient or crime victim could already simplify a lot such checking: both sides (such as doctors from different world regions) would be annoyed if the rules would trow warnings all the time because a human (the doctor) have metadata about where he works (the hospital) and a contact information which would be personal identifiable information (such as email) while the patients are anonymized.
TODO: some way to encode "organizations"
Not sure how to encode this right now, but we're likely to need another 2 numeric base namespaces both for individual and collective of organizations, such as hospital. The logic could become similar to what we have here:
One infix (such as "1") to mean every type of individual (or collective without division by themes) of organizations
Have other infixes for at least most popular organizations which worth to encode (not just hospitals)
Some more specialized types (for example, type of hospitals) could become metadata
The text was updated successfully, but these errors were encountered:
- https://github.com/BFO-ontology/BFO
- https://en.wikipedia.org/wiki/Basic_Formal_Ontology
From an ontological (Basic Formal Ontology) at the #43, the main point could be described as "metadata about aggregated collection of humans" with reference key 1:1 compatible with P-Codes (which at the moment uses
1603:16:{unm49}:{cod_ab_level}:{unpcode}
). Under this logic, a prefix different from1603:16:
would be used, but as much as possible, by the dedicated #43 prefix alone, it should be possible to make the mappings.Both for #43 and this new topic, as soon as the numerical taxonomy is drafted, the new information becomes metadata to the main keys. However, since eventually such nodes could become very overloaded with information witch would not be mere linguistic and some types of "metadata about aggregated collection of humans" could be thematic and overly specialized, we migth need to create a default infix (like the number 1) to represent the most generic term (such as for #43, assuming NN as base, the population statistics could become
1603:NN:1:{unm49}:{cod_ab_level}:{unpcode}
) and when new relevant thematic groups appears (but would still be "metadata about aggregated collection of humans'') the way to distribute the data could have different packages.Under ideal circumstances, since #43 would be an aggregated version about this issue, whatever would be the infix "1", they could be the same. So let's say "healthcare workers" would be relevant to receive an infix like "123", under #43, the metadata would be about collection (by region), and on this topic, they would be at individual level.
Relevance of this namespace
By having a dedicated prefix designed to have data about individual humans, both sensitive and public data, non-anonymized and anonymized data, would ideally appear in a predictable way. The numeric prefix alone could allow decisions to be made (such as enforce more checks). Most of the time, the type of data here should not be public. But there are cases where is relevant to have suggested prefix for data which can be public (even if eventually over the time laws could be changed, and datasets requested to be deleted):
However, realistic speaking, this topic would be by far the most stricter to represent data which should have higher protection when exchanged outside the place allowed to use own data and as public documentation on how to use own data with other public resources. Considering #43 maybe some infix to differentiate for example who is doctor or police officer and who is patient or crime victim could already simplify a lot such checking: both sides (such as doctors from different world regions) would be annoyed if the rules would trow warnings all the time because a human (the doctor) have metadata about where he works (the hospital) and a contact information which would be personal identifiable information (such as email) while the patients are anonymized.
TODO: some way to encode "organizations"
Not sure how to encode this right now, but we're likely to need another 2 numeric base namespaces both for individual and collective of organizations, such as hospital. The logic could become similar to what we have here:
The text was updated successfully, but these errors were encountered: