Consulta Pública Análise das Contribuições João Lima.

Apresentação em tema: "Consulta Pública Análise das Contribuições João Lima."— Transcrição da apresentação:

1 Consulta Pública Análise das Contribuições João Lima

2 Contribuições Apresentação [ 1+1*] Parte 1 - Modelo de Referência Parte 2 - LexML URN [12] Parte 3 - XML Schema [ 2] Parte 4 - Coleta de Metadados Parte 5 - Serviço de Resolução de URN Parte 6 - Vocabulários Controlados [ 1] [ 16+6 = 22 ] (*) 1 Contribuição com texto consolidado (Peter) que agrega mais 6 novas contribuições

3 Contribuição #1 de: Marcio Nunes Iorio Aranha Oliveira onde: Documento Apresentação Contribuição Inserção, como princípio regente do Projeto LEXML, da disponibilização de acesso gratuito às normas e julgados referenciados ao público em geral. Inserção, como princípio regente do Projeto LEXML, de disponibilização de acesso gratuito ao sistema de redirecionamento centralizado. Em acréscimo ao qualificativo de acesso gratuito ao sistema e aos dados de redirecionamento do sistema, propõe-se que a vinculação institucional à iniciativa esteja expressamente restrita a órgãos e a entidades da Administração Direta ou Indireta dos níveis federal, estadual e municipal, ao menos nos primeiros anos de estabilização do sistema.

4 Contribuição #1 (cont.) Justificativa: O projeto LEXML, conforme já enunciado no documento de referência, busca adensar o direito de acesso à informação inscrito no art. 5º, XIV, da Constituição Federal de 1988. Para que o conjunto de prescrições de ciência de informação e informática se institucionalizem em um projeto perene e compartilhado, é necessária que integre a conceituação do projeto LEXML, após a referência aos seus objetivos gerais e específicos, um tópico sintético referente aos “princípios regentes” do Projeto LEXML, que traduzissem a postura do grupo responsável pela continuidade da iniciativa, bem como dos integrantes institucionais que se aliem a uma iniciativa eminentemente pública como essa. A inserção de princípios de acesso gratuito e vinculação, ao menos inicial, a instituições públicas de produção e disponibilização de bases normativas e de julgados é requisito necessário à qualificação pública do projeto. O cidadão que acessasse o sistema e que fosse, porventura, redirecionado a normas de acesso pago, dificilmente veria na iniciativa um projeto de organização e preservação da informação eletrônica pertinente a normas de conduta social. Normas, por princípio, são de acesso geral e gratuito para os seus destinatários, a não ser que integrantes de subsistemas de controle de interesse técnico e restrito. O caráter nacional que se pretende dar ao projeto é, ao menos inicialmente, incompatível com o subsídio a produções normativas monetarizadas.

5 Contribuição #1 (cont.) Análise Inclusão do Tópico “2.3 Princípios do LexML” (após o tópico “2.2 Objetivo Específico”) contendo: Acesso gratuito ‘para consultas ao acervo LexML; Restrição de participação na Rede LexML a órgãos e a entidades da Administração Direta ou Indireta dos níveis federal, estadual e municipal.

6 Novo Texto

7 Contribuição #2 de: Claudson dos Santos Melo, onde: Parte 3 – XML Schema 6. Estrutura de Acórdão em LexML Contribuição: No inteiro teor de um Acórdão incluir os elementos ementa e decisão. Justificativa: Já que temos o relatório e o voto (fundamentação legal). É interessante então permitir a inclusão da ementa e da decisão do acórdão também.

8

9 Contribuição #2 (cont.) Análise Dúvidas Melhor reposicionar a ementa? AcordaoTexto e Decisão é a mesma coisa?

10 Contribuição #3 de: Peter de Padua Krauss onde: Parte 3 – XML Schema 7. Tratamento do Texto Contribuição: assunto: tags Texto e TextoSimples reduntantes As tags Texto e TextoSimples poderiam ser eliminadas. Justificativa: elas "poluem" consultas com XPointer por exemplo; editores de XML devem identificar automaticamente os critérios de edição de cada tag; não ajuda no XSLT; cria um passo a mais antes de avaliar como HTML padrão.

11 Situação Atual

12 Contribuição #3 (Cont.) Análise (I) Transforma elementos em tipos TextoType  * TextoSimplesType  Apenas um (II) Criar um elemento para conter o nome dos agrupadores.

13 Situação Proposta

14 Contribuição #4 de: Cristiane Ferreira de Souza onde: Parte 6 – Vocabulários Controlados Contribuição Vocabulário controlado para assunto Justificativa Muito importante também é o controle do vocabulário para assuntos ou palavras-chave. A recuperação apenas pelo texto integral, pode gerar a recuperação de itens não relevantes.

15 Contribuição #4 Análise Inclusão de Parágrafo na “Seção 1 – Introdução” alertando que a atual versão considera apenas os vocabulários controlados relacionados à identificação do documento (referenciados pela URN). No futuro, haverá um estudo para resolver a questão do “vocabulário de assunto”, essencial para a recuperação da informação. Esse estudo poderá sugerir (a) a criação de um vocabulário unificado a partir dos existentes (ex: UMLS (Medicina)) (b) trabalhar a compatibilização entre vocabulários utilizando a extensão do SKOS para mapeamento entre vocabulários. (c) utilização da abordagem Folksonomia (qualquer pessoa cadastrada pode rotular recursos).

16 Novo Texto

17 Contribuição #5 de: Peter de Padua Krauss onde: Parte 2 – LexML URN Seção 10.1 – Indicação do Descritor Contribuição Na seção 10.1, "Indicação do Descritor", não exigir data completa, a sintaxe canônica pode prescindir do mês e do dia, ::= ";"... ::= |

18 Contribuição #5 (Cont.) Justificativa O escopo da LexML parte 2 deve ser orientado ao universo de uso, e é conhecido que a maior parte dos usos previstos, tanto para referência como para registro, está no universo das normas que respeitam a Lei Complementar nº 95, principalmente normas estatutárias. Além disso, existe um grande volume de normas municipais, bem maior do que federais e estaduais, onde URNs canônicas serão, na prática, gerenciadas pelos municípios se as regras sintáticas da URN canônica forem simples e consistentes com a praxis. Para o "escopo relevante" não existem atos não-numerados, e basta o ano para garantir a sua unicidade. ARGUMENTOS: para conquistar aderência a LexML é necessário simplicidade, pragmatismo e compatibilidade com as tradições de uso. (Continua...)

19 Contribuição #5 (Cont.) Simplicidade e pragmatismo: Não cabe penalizar a sintaxe canônica da URN LexML com as exceções (redações que não respeitaram a Lei Compl. nº 95). As exceções (atos cuja data com mês e ano é necessária para identificação única) por sua vez, na sintaxe proposta acima, ainda seriam tratáveis, havendo a opção de complmentação com mês e ano. Não cabe tratar a URN como um "repositório de metadados", a sua função precípua na LexML é a identificação única de normas. (data completa é redundante como elemento de identificação). Os softwares de extração de dados (que colhem a URN a partir do conteúdo da norma) geram a URN canônica de forma mais CONFIÁVEL (regular expression mais simples e confiável) se não forem requisitados dia e mês. Em casos onde o texto da norma possui indicação sobre publicação (DOU), essa data poderia gerar ambigüidade ou falha, mas como o ano é o mesmo em 99% dos casos, seu uso isolado não seria ambiguo. Pragmatismo e compatibilidade com as tradições: Não apenas juristas, mas também jornalistas, comentaristas, etc. podem optar, tradicionalmente, por grafar as citações de norma (ex. "conforme a Lei 123 de 2006") com apenas o ano, dada a dificuldade de obtenção da data completa e redundância que ela representa na citação. Para a conversão, manual ou automática, do texto livre em texto marcado com a URN, nestes casos, possu-se disponível apenas a informação relativa ao ano, não há informação relativa a dia e mês. Em diversas aplicações (de conversão da citação literal em URN) será interessante que possam utilizar representação das URNs em sintaxe canônica, evitando custos de resolução/validação maiores.

20 Contribuição #5 Análise Situação atual URN Referência: pode informar apenas ano URN Canônica: data completa Situação sugerida URN Canônica: data completa ou apenas Ano Vantagem Mais simples Desvantagem Em alguns casos a data completa é importante  decreto não numerado URN Canônica com dois formatos  Provedores de dados com níveis de detalhamento diferente para a mesma informação. A epígrafe, montada pela imprensa nacional, considera a data completa.

21 Diário Oficial

22 Contribuição #6 de: Peter de Padua Krauss onde: Parte 2 – LexML URN Seção 10.5 – Esclarecimentos Sobre os Números de Identificação do Ato Contribuição: Na seção 10.5, "Esclarecimentos Sobre os Números de Identificação do Ato", é sugerido que o id-documento possa conter o ano da norma. Mudança de texto: restringir mais rigidamente os casos onde a "participação do ano no id-documento" seja válida. Sugestão de restrição: se o ano pode ser separado do id- documento através de uma expressão regular, então o ano deve ser removido (ou aproveitado na composição do descritor).

23 Contribuição #6 (Cont.) Justificativa Esse tipo de procedimento (permissivo) pode dar margem a erros e ambigüidades. A sintaxe URN não é trivial de ser obtida para cada documento específico. O "mapeamento do título da norma na URN da norma" é um procedimento delicado que demanda atenção, independente do fato de o id-documento conter ou não conter o ano. Dessa forma não há porque supor que esse detalhe não demande atenção.

24 Contribuição #6 (Cont.) Análise Aprovação, utilizando a seguinte restrição Incluir uma restrição informando que nos casos das autoridades “federal”, “estadual” ou “municipal” (autoridades convencionadas para normas de hierarquia superior) não deve ser considerado o ano no número de identificação.

25 Contribuições sobre Fragmento Contribuição #7 trocar ‘:’ por ‘#’ Contribuição #8 definição de “fragmento” mapeado para o padrão W3C xpointer. Contribuição #9 posição do elemento fragmento transposto para o final, trocando “:” para “!”

26 Contribuição #7 de: Peter de Padua Krauss onde: Parte 2 – LexML URN (Seção 6.3 – Estrutura do Nome Específico e Seção 11 – Fragmento) Contribuição assunto: fragmento codificado em conformidade com sintaxe URI A referência a fragmentos é formalmente definida na seção 3.5 da RFC 3986. De acordo com essa RFC, e com a tradição de uso, o fragmento é declarado sempre no final da string e após o caracter "#".RFC 3986 O principal motivo de não utilizar essa convenção de sintaxe URI para fragmentos na versão 0.7 do texto "Parte 2 ? LexML URN", é, aparentemente, a distinção entre: ação de posicionar para o ponto desejado - posicionar o texto em um ponto na barra de rolagem, quando da visualização do documento integral; ação de recuperar o fragmento desejado - apenas uma parte do documento normativo é fornecido (recuperado) pelo URN resolver. Ambas as ações podem ser realizadas pelo URN resolver: no primeiro caso (posicionar) a ação só é possível em serviços do tipo N2R (ver RFC 2483), quando o texto da norma se encontra em um browser. No segundo caso (ação de recuperar) o URN resolver está sendo informado que é desejado um output diferente do documento em sua íntegra.RFC 2483 A função precípua da designação de fragmentos de normas é a possibilidade de citar (remissão) porções específicas da norma. Essa função é cumprida em ambos os casos: posicionar e recuperar(!). Ademais, como fica esclarecido acima, a URN deve "delegar ao URN resolver" as decisões relativas a posicionar ou recuperar; não caberia à URN expressar ou antecipar essa decisão. O texto da seção 11, "Elemento " e todos os demais trechos relativos ao tema, deveriam sofrer as devidas alterações para compatibilizarem-se com a sintaxe padrão (URI) de fragmento.

27 Contribuição #7 (Cont.) Justificativa Entendendo que após o caracter "#" da URI temos um XPointer (http://www.w3.org/TR/xptr-framework), estamos considerando os fragmentos como "volumétricos" e não meramente "pontuais".http://www.w3.org/TR/xptr-framework Convém lembrar que o recurso de posicionar o texto só é limitado a "uma única posição" por questões tecnológicas: o padrão XPointer, por fazer uso do XPath, não proibe a declaração de múltiplas posições (operador "|" do XPath proporciona a união de elementos), e, além disso, oferece recursos para a referência não-pontual, tais como o operador "range-to". Se considerarmos que as decisões sobre output são de responsabilidade do URN resolver (vide especificação de serviços na RFC 3986), concluiremos que não é correto sobrecarregar a sintaxe da URN LexML com descrições adicionais de fragmento. Deve-se fazer uso da sintaxe já prevista pelos padrões URI e XPointer.RFC 3986 Ao considerarmos o fragmento um "elemento externo porém previsto" na URN LexML, estamos evitando a mistura de conjuntos de caracteres: antes do "#" temos o conjunto "aceitos-lex", após o "#" temos "aceitos-XPointer". Isso não impede a LexML de intervir sobre a sintaxe do fragmento, declarando que identificadores (shorthand pointer) na forma "art2,art5" ou "[art2,art5]" recebam um tratamento especial, antes de serem repassados para o XPointer processor.

28 Contribuição #7 (Cont.) Análise Situação Atual: ::= [ ":" ] Situação Proposta: ::= [ “#" ] Detalhe Ao clicar em uma “URI com fragmento” é realizado o GET apenas da parte anterior ao caractere “#” (i.e. o browser não requisita o identificador do fragmento ao web-server)

29 Contribuição #8 de: Peter de Padua Krauss onde: Parte 2 – LexML URN Seção (11 – Fragmento) Contribuição: Assunto: Fragmento mapeado como XPointer Sugere-se fixar semântica de XPointer à especificação de fragmento. Na seção 11, "Elemento ", acrescentar, após os exemplos, o texto

30 Contribuição #8 (Cont.) A semântica desses fragmentos é fixada pela semântica XPointer no seguinte mapeamento (esboço de algoritmo para mapeamento da sintaxe LexML-fragmento em sintaxe XPointer): 1. todo id-particao é convertido para "id('strIdParticao')" 2. todo intervalo-ids é convertido para "id('strId1')/range-to(id('strId2')))" 3. o conjunto com mais de um fragmento (separado por virgula) é convertido em um conjunto separado por "|" (pipe). 4. a string resultante é convertida para "xpointer(strResultante)" Como resultado da aplicação do mapeamento ao fragmento "art5_par2" teríamos "xpointer(id('art5_par2'))". Já para o terceiro exemplo, teríamos xpointer(id('art6')/range-to(id('art10')))|id('art12')|id('art20')/range-to(id('art30')))) A semântica de XPointer é fixada pela norma W3C "XPointer xpointer() Scheme", http://www.w3.org/TR/xptr-xpointer http://www.w3.org/TR/xptr-xpointer A URN com fragmento estabelece a recuperação de um fragmento da norma (trechos), ao passo que a URN sem fragmento estabelece a recuperação do documento completo (íntegra). A "URN com fragmento" não deve ser confundida com "URN com indicação de posicionamento na rolagem", caracterizada pelo uso do caracter "#" no final da URN (ex. "urn:lex:br:etc#fragmento"). Neste caso, o fragmento é também um XPointer, mas não afeta a recuperação de dados, e a sua resolução é efetuada externamente (tipicamente em um browser).

31 Contribuição #8 (Cont.) Dar ao fragmento uma semântica mais sólida, baseada em normas W3C, já prevista nas suites XML. Dar um encaminhamento mais bem definido e pragmático para a resolução de fragmentos, baseado na reutilização de bibliotecas XPointer. No texto, realçar o fato de que a identificação de fragmento é um recurso útil para a recuperação de dados, ou seja, especifica a porção do documento que se deseja recuperar, e que não é um recurso de navegação, como o caso do posicionador de texto na rolagem, "#". Atenção: essa sugestão não é incompatível com a anterior (sintaxe URI), pode-se integra-las deletando os comentários sobre "#" acima. Eu pessoalmente gostaria que as duas fossem apreciadas e aceitas em conjunto. Os comentários sobre "#" só foram inclusos para o caso de a sugestão anterior (fragmento URI) ser descartada.

32 Contribuição #9 de: João Holanda onde: Parte 2 – LexML URN (Seção 6.3 – Estrutura do Nome Específico e Seção 11 – Fragmento) Contribuição: A urn continuaria sendo constituída por 3 partes: obra complexa, obra individual e fragmento de obra. Mas a ordem seria diferente da atual, que situa o fragmento entre a obra complexa e a obra individual. A proposta seria a seguinte: @ !fragmento Justificativa: O fragmento refere-se à obra individual. Desse modo, a urn ficaria mais clara se a referência ao fragmento viesse após a obra individual. nota: a proposta de se adotar o caractere '!' depende da aprovação de uma outra proposta que elimina sua utilização para definição da obra individual.

33 Contribuição #9 (Cont.) Análise Situação Atual:  [ ":" ] [ @ ] Situação Proposta:  [ @ ] [ “!" ]

34 Contribuição #10 de: Peter de Padua Krauss onde: Parte 2 – LexML URN Gramática EBNF Assunto: correções menores na ortografia das BNFs Sugestões: na seção 6.2 (e apêndice A), o elemento referencia mas parece que o correto seria na seção 9.2 (e apêndice A), na definição do elemento falta acrescentar parêntesis: ::= ( | | ) [";" ] | ( "publicacao.oficial;" [";" ] ) ou, se for o caso de realçar o fato de serem o sequenciador e a publicação oficial mutuamente exclusivos, ::= ( | | ) [ (";" ]) | ("publicacao.oficial;" Justificativa: Garantir a consistência das BNFs.

35

36 Contribuição #10 (cont.) Análise Pela aprovação.

37 Contribuição #11 de: Peter de Padua Krauss onde: Parte 2 – LexML URN (Seção 10.6 – Identificador de Componentes de um Documento) Contribuição: Assunto: Identificação de componentes através de XPointer A convenção adotada no texto seção 10.6, "Identificador de Componentes de um Documento", não é clara quanto à definição de como estabelecer univocamente o que é componente (referenciável como componente) e o que é fragmento (referenciavel como fragmento), ou seja, se isso depende de o original ter sido publicado em partes separadas (arquivos ou cadernos separados) ou não. Outros problemas parecem surgir com a distinção entre fragmento e componente: 1. uma tabela ou figura no interior da articulação, é componente ou fragmento? E se a tabela ou figura forem apresentados apenas no final da articulação, mas antes das assinaturas? 2. e "retificacao" (sec. 10.6.4) são conceitos que se confundem, e podem acarretar ambiguidades (no uso e/ou no registro das URNs). 3. há risco de incompleteza no registro de URNs canônicas: não bastaria o registro da norma, requer o registro formal (na base do URN resolver) das URNs das componentes. Pode-se supor que regras para o tratamento do material sejam adotadas como convenção. Por exemplo: "todo anexo ou apêndice é um componente" estaria implicita no texto atual da LexML Parte 2.

38 Contribuição #11 (Cont.) Sugere-se portanto fixar as seguintes (outras) convenções: documentos que acompanham a norma (ex.: anexos) são PARTE INTEGRANTE da norma (mesmo XML); partes (TABLEs, IMGs, notas, etc.) que foram grafadas no interior da articulação devem permanecer localizadas no interior da articulacao, caso contrário, são registradas como anexo (explicito ou implícito) no final da norma. Partes com designação usual recebem identificador padrão: tabelas ("tab123"), figuras ("fig123"), mapas ("map123"), anexos ("anexo123"), e apêndices ("ap123"). Com essas convenções simples podemos tratar de forma simples qualquer "componente": componentes com ID são referenciáveis univocamente por shorthand pointer: são pré- processados conforme sugerido para o tratamento de fragmentos (vide mapeamento de IDs e ranges). havendo necessidade de referenciar titulos de elementos como se fossem IDs, e dentro da sintaxe LexML (minúsculas e espaço codificado como ponto), pode-se adotar uma sintaxe adicional no pre-processamento, para simplificar a referência a títulos e sub- títulos. componentes sem ID padrão definido, podem ser referenciadas pelos esquemas XPointer (element e xpointer).

39 Contribuição #11 (Cont.) Com o uso do XPointer, e a adoção das convenções simples sugeridas, os problemas ficam resolvidos: 1. a semântica e a resolução (das componentes) ficam claras e mapeáveis para um esquema sólido: 1. o padrão XPointer é maduro: as implementações de resolução serão mais confiáveis. 2. é bem revisado: não corremos o risco de criar uma sintaxe inconsistente, inclusive com URIs. 3. torna o texto da LexML Parte 2 mais simples: basta citar o XPointer, não precisamos especificar detalhes. 2. não há mais confusão entre fragmento e componente: tudo é fragmento. 3. não há mais confusão entre e "retificacao". 4. o esquema de referência é uniforme: tudo é referenciável como XPoienter. 5. não há risco de incompleteza no registro de URNs canônicas: o que vale é o documento, o resto depende apenas de o URN resolver ter sido abastecido do XML da norma e/ou metadados que permitam verificar a disponibiloidade dos identificadores requisitados.

40 Contribuição #11 (cont.) Análise “documentos que acompanham a norma (ex.: anexos) são PARTE INTEGRANTE da norma (mesmo XML); “ [ pela rejeição ] Por convenção, o XML Schema do LexML definiu que todo anexo será representado como um XML independente (obs.: reconhecemos a existência dos anexos dependentes e independentes) O identificador Uniforme (URN) acompanha essa diretriz “partes (TABLEs, IMGs, notas, etc.) que foram grafadas no interior da articulação devem permanecer localizadas no interior da articulacao, caso contrário, são registradas como anexo (explicito ou implícito) no final da norma. “ O XML Schema já permite esta configuração. O que estiver após a estrutura prevista dos documentos (Normas, Proposições, Julgados) será tratado como um anexo em um arquivo XML próprio. [ pela rejeição ] “Partes com designação usual recebem identificador padrão: tabelas ("tab123"), figuras ("fig123"), mapas ("map123"), anexos ("anexo123"), e apêndices ("ap123"). “ [pela aprovação parcial] Os anexos constituem componentes, não precisando de ids pois já possuem URN própria Criar IDs para tabelas, figuras e mapas (e outras entidades que venham aparecer)

41 Contribuição #12 de: Peter de Padua Krauss onde: Parte 2 – LexML URN (Seção 9.3 – Relações entre Documento e Autoridade nos alias; Seção 14 - Referências) Contribuição: Assunto: inclusão de seção "URNs canonicas" no Parte 2 As seções 9.3, "Relações entre Documento e Autoridade nos alias", e a seção 14, "Referências", descrevem possibilidades de grafia de uma "URNs alternativas", que não correspondem exatamente ao que foi registrado no URN resolver como "URN canônica da norma". Seria interessante retomar, em uma seção independente da Parte 2, as conclusões e definições relativas à URN canônica, ou seja, aquilo a string que permite identificar univocamente cada norma. Sugestões de itens a serem lembrados: 1. qual o objetivo da URN canônica? identificação unívoca da norma ou "identificação unívoca + registro de metadados"? (se datas de assinatura, publicação, vigência, etc. são obrigatórios na norma canônica, então estaremos criando um banco de metadados mais que identificando univocamente), 2. qual o elemento sintático principal, (sem alias)? 3. qual o papel do ? ele deve ser "preenchido completamente" na sintaxe canônica, ou seus elementos utilizados apenas nos casos em que se fizerem necessários, para destacar variantes de um mesmo documento?

42 Contribuição #12 (Cont.) Justificativa: maior clareza dar um "fecho" ao conceito de "URN canônica" esclarecer com mais clareza o que é elemento de identificação unívoca (e se torna URN canônica), e o que são elementos secundários na sintaxe da URN. desvendar com mais clareza quando devem ser utilizadas versão, visão e forma, na definição de URN canônica, e como isso não cria duplicidade (documentos de conteúdo igual porém com URNs distintas).

43 Contribuição #12 (Cont.) Análise Situação Atual O termo “urn canônica” não foi citado na texto da Parte 2. O termo “urn de referência” é citado em vários pontos. Proposta Passar a utilizar o termo “urn canônica” como a urn associada ao documento individual pelo provedor de dados. Deixar claro no texto que:  Os elementos da especificação do documento individual (versão, visão e forma) compõem a “urn canônica” e que todos eles possuem valores default.  A “urn canônica” é definida pela informação que consta da Epigrafe do documento. Os apelidos de um documento podem gerar “alias” que poderão ser utilizadas em “urns de referência”.

44 Contribuição #13 de: João Holanda onde: Parte 2 – LexML URN Contribuição compor de forma diferente os elementos versão/visão, interpondo um novo elemento qualificando a visão. que visa proporcionar maior clareza. O elemento qualificativo de visão poderia apresentar um dos valores abaixo: "assinatura" | "iniciativa" | "julgamento" | "publicacao" | "alteracao" | "retificacao" | "republicacao" | "anulacao" | "declaracao.inconstitucionalidade" Exemplo: urn:lex:br:federal:lei:2008-04-11;11501@2008-04-12;assinatura;2008-04-11 urn:lex:br:federal:lei:2008-04-11;11501@2008-04-12;publicacao;2008-04-12 urn:lex:br:federal:lei:2008-04-11;11501@2008-04-12;retificacao;2008-07-16 Situação anterior: urn:lex:br:federal:lei:2008-04-11;11501@2008-04-12!2008-04-11

45 Contribuição #13 (Cont.) Justificativa apesar de estarem conceitualmente consistentes, os elementos visão e versão têm gerado muitas dúvidas e se mostrado de difícil assimilação dada a quantidade de eventos que podem gerar versões e visões. A idéia seria compô-los em um único elemento (considerando que a visão sempre existe no contexto da versão) acrescentado um descritor do nome do evento. nota: o caractere '!' deixa de ser utilizado para este fim.

46 Contribuição #13 (Cont.) Análise Pela aprovação. Obs.: O evento é um elemento essencial no Modelo de Referência do LexML (FRBRoo).

47 Contribuição #14 de: João Holanda onde: Parte 2 – LexML URN Contribuição passaria a ser admitida a referência a uma obra individual específica sem o prévio conhecimento de suas datas de versão/visão. Esta nova forma de codificar a versão/visão também abrangeria os atuais parâmetros do elemento propriedade ("$"). Seriam admitidos os seguintes substitutos na referência à versão/visão: @versao.original @versao.vigente.em; @versao.eficaz.em; @versao.consultada.em; Exemplo: urn:lex:br:federal:lei:2008-04-11;11501@versao.original urn:lex:br:federal:lei:2008-04-11;11501@versao.vigente.em;2008-04-12

48 Contribuição #14 (Cont.) Justificativa Facilitar a referência às diferentes versões da obra individual, sem prévio conhecimento de datas específicas de cada versão.

49 Contribuição #14 (Cont.) Análise Pela aprovação. Obs.: A urn de referência passa a ter mais opções de codificação.  Conveniência do usuário

50 Contribuição #15 de: Peter de Padua Krauss onde: Parte 2 – LexML URN ASSUNTO: princípios-base do URN Conforme o LexML v0.7 temos, na seção 6.1, "Princípios- base do Nome Uniforme (URN)", "O nome uniforme deve ser unívoco, isto é, deve identificar uma e apenas uma entidade, e é construído de modo a ser, tanto quanto possível:... princípios itemizados..." Sugere-se separar em principios gerais e específicos, e acrescentar mais dois, em particular o principio 3.2, "registrável com o mínimo de informação" (abaixo), lembrando que ele tem precedência sobre os princípios 3.3 e 3.4:

51 Proposta (Princípios) Gerais (aplicáveis a "URN da publicação", URN-referência, "URN-canônica da norma" e demais URNs propostas pela LexML) auto-explicativo para os usuários; dedutível por meio de regras simples e claras; de acordo com a definição da estrutura relativa à classe dos documentos da categoria; alinhado constantemente aos demais padrões do projeto. URN-referencia: mapeável em URNs canônicas cabíveis; * unívoco para o contexto de uso; * compatível com a prática em uso para criar referências; reduzido ao essencial, para simplificar os links com outros documentos; gerado automaticamente por analisadores das referências no texto; URN-canonica da norma (registro da norma): unívoco para o espaço das URNs canônicas; * registrável com o mínimo de informação (o suficiente para ser unívoca), * representativo dos aspectos, tanto formais quanto substanciais, do documento; em conformidade, à data de sua emissão, com a estrutura/organização da autoridade emitente e com a tipologia do documento. * indica itens acrescentados pela sugestão.

52 Contribuição #15 (Cont.) Justificativa Os princípios que se aplicam a URNs de referência não se aplicam a URNs canônicas; A hierarquização ajuda a lembrar que a LexML lida com diferentes classes de URNs, e que a cada classe podemos ter objetivos e princípios norteadores distintos. Subsidiar sugestões norteadas pela "desburocratização" (inclusão excessiva de metadados na string da URN) Sugere-se evitar, na LexML 1.0, esse tipo de falha, aparentemente presente na LexML v0.7, pois tende a acarretar dificuldade de uso, custo de implantação e manutenção, e perda de aderência à LexML (barreira para prefeituras mais pobres por exemplo). O principio 3.2, "registrável com o mínimo de informação", evita a "burocratização" trazida pelos principios 3.3 ("representativo dos aspectos formais e substanciais") e 3.4 ("em conformidade, à data de emissão, autoridade e tipologia").

53 Situação Atual

54 Contribução #15 (Cont.) Pela aprovação, com alterações “ representativo dos aspectos formais do documento;” Sob Princípios da URN Canônica “pode ser representativo dos aspectos substanciais, do documento;” Sob Princípios da URN Referência Nomes dos grupos Princípios Gerais (aplicáveis à “URN de Referência” e à “URN Canônica”) Princípios da URN Canônica Princípios da URN de Referência

55 Contribuição #16 de: Peter de Padua Krauss onde: Parte 2 – LexML URN Contribuição Assunto: revisão do elemento O elemento forma, descrito na seção 13 da Parte 2, e previsto na sintaxe de documentoIndividual, ::= "@" "!" "~" identifica a forma de expressão do recurso. A "forma default", e, via de regra, a "forma oficial", é o texto;pt-br, que não precisa estar presente na URN para satisfazer o critério de "identificação unívoca". A utilidade do elemento forma está em permitir a identificação unívoca de tipos de documento não usuais, e, via de regra, não-oficiais: traduções (para o espanhol, inglês, etc.), transcrições (para áudio por exemplo), etc. Sugere-se portanto não grafar a URN canônica sem elemento forma (portanto supondo semântica default sempre que estiver ausente). Uma importante distinção entre documentos, que não está sendo prevista pela LexML v0.7, é a distinção entre "documento assim publicado" e "documento compilada a partir dos publicados". Leis que sofrem alterações, tem o texto da modificação presente em outra Lei, de forma que, semânticamente, é falso expressar uma URN de documentoIndividual relativo à modificação como se fosse um documento concreto e oficial... Tanto que o "documento compilado" não tem valor de prova jurídica (não é oficial). O que tem existência concreta são documentos não-oficiais (muito comuns na Internet) trazendo uma "versão compilada", ou seja, uma "tradução" do texto original seguindo-se as instruções de modificação fixadas por outra Lei. PS: o que ocorre por vezes é a criação de uma nova norma apelidada de "Consolidação" que, esta sim, tem existência oficial concreta.

56 Contribuição #16 (Cont.) Resumo das sugestões: não incluir informações redundantes na URN canônica: a ausência do texto;pt-br torna a URN mais curta e simples; prever outros tipos de forma relevantes para a identificação de "variantes" do documento normativo original: texto-compilado, imagem-compilado e audio-compilado (sufixo "-compilado") para os rótulos já existentes). Justificativa: Garantir a simplicidade (string curta) das URNs no seu objetivo de "identificação unívoca" (aplicando o principio de não- redundância justificado em proposta anterior). Evitar contradição semântica no caso do texto compilado não- oficial: ele representa efetivamente o conteúdo da "nova versão da norma", mas não tem existência senão como "forma traduzida não oficialmente e não-publicada".

57 Contribuição #16 (Cont.) Análise Deixar claro na Parte 2 que o “tipo da forma” é referente ao conteúdo e não ao suporte. Nem todos os documentos oficiais são expressos no formato texto (ex.: imagem da bandeira brasileira) “transcrição para áudio” refere-se à suporte (mimetype do item) e não a forma do conteúdo. A possibilidade de existir versões não oficiais de leis traduzidas (ex. CDC em inglês no MJ) gera a necessidade de indicar a língua no qual o documento foi expresso. A distinção entre a publicação oficial e as outras publicações já faz parte da urn e a interface dá o devido destaque à publicação oficial. Os únicos eventos que geram estão “atrelados” à publicação oficial são: “publicação”, “republicação” e “retificação”. Os textos gerados a partir de outros eventos (“alteração”, “revogação”, etc.) não são oficiais. Pela não aprovação da contribuição e pela revisão do texto atual referentes a estes pontos.