Código Natural/Identificação taxonômica/Casos de uso

De Documentação
< Código Natural‎ | Identificação taxonômica
Revisão de 10h19min de 5 de maio de 2024 por Peter (discussão | contribs) (Criou página com 'Estruturas taxonômicas consensuais, e que sejam estáveis dentro de certa escala de tempo, não são tão raras. Existe alias, com as técnicas modernas de estatística, IA e taxonomia numérica, aliadas a um maior potencial de se medir as características de um objeto (desde informações IoT até DNA anulando risco de ambiguidade na atribuição de uma classe), uma tendência ao crescimento das taxonomias estáveis. == Biologia == ... == Química == ... == Organiza...')
(dif) ← Edição anterior | Revisão atual (dif) | Versão posterior → (dif)

Estruturas taxonômicas consensuais, e que sejam estáveis dentro de certa escala de tempo, não são tão raras. Existe alias, com as técnicas modernas de estatística, IA e taxonomia numérica, aliadas a um maior potencial de se medir as características de um objeto (desde informações IoT até DNA anulando risco de ambiguidade na atribuição de uma classe), uma tendência ao crescimento das taxonomias estáveis.

Biologia

...

Química

...

Organizações do SchemaOrg

É muito comum em Big Data a adoção de uma visão unificada dos dados de uma grande empresa, que pode conter, por exemplo, mais de um sistema de CRM para a gestão dos seus clientes.

A classificação dos clientes B2B de uma empresa, conforme SchemaOrg.

O primeiro passo nesse caso é estabelecer em UML qual a estratégia semântica de unificação. Pode-se optar por exemplo por não misturar B2C com B2B, e optar por classificar os clientes B2B conforme o o primeiro e segundo níveis do padrão SchemaOrg, ou seja, conforme sch:Organization. Pode-se também reservar para o sistema interno, de RH por exemplo, a classe InternalOrganization, para mapear subsidiárias e departamentos.

Optou-se também por adotar, como medida de apoio à transição do ID convencional (inteiro de 32 bits) para o hInt de 64 bits, a classe Other. Nela os clientes com cadastro indefinido ou onde caberiam outras classificações, ficam de "quarentena". Na representação base16h seria necessário mais de um dígito para o primeiro e segundo níveis, de modo que uma opção mais amigável (1 dígito por nível hierárquico) é a base32nvu:

  • 0 - InternalOrganization (classe para a gestão interna de departamentos e empresas controladas)
  • 1 - (supor classe reservada)
  • 2 - Airline
  • 3 - Consortium
  • 4 - Corporation
  • ... (até 10 outras classificações futuras do SchemaOrg, ou obtidas na Wikidata)
  • Z - Other (classe temporária para a gestão de cadastros incompletos)
    • Z1 - Generic partner (para distinguir de terceirizados ou franquiados ainda indefinidos - sem especialização)

Devido à ambiguidade nos domínios, a empresa precisa definir qual a subclasse canônica, quando o SchemaOrg oferecer mais de uma alternativa. Por exemplo "Dentist" pode ser subclasse de "LocalBusiness" ou de "MedicalOrganization", no exemplo foi adotada a classe "MedicalOrganization".

Foram consumidos até aqui 15 dos 25 bits reservados à classificação (cada dígito base32 consome 5 bits - caberiam mais 2 dígitos), totalizando 25+32=57 bits informativos no esquema hInt64 de identificação das instâncias. Contador "por classe" de máximo 32 bits, pois, para usar o esquema hCount16_48, com 48 bits no contador, a classificação não poderia passar de 11 bits — acima poderíamos eliminar o terceiro nível para ficar com 10 bits.

Para a expressão final do ID de cada instância pode ser utilizado o código híbrido base32-decimal (ex. B5-123 seria a Pharmacy 123), ou base32 com ponto para destacar dígitos do contador (B5.3R).