Download
1 / 57
570 likes | 725 Views
Consulta Pública. Análise das Contribuições João Lima. 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
E N D
Consulta Pública Análise das Contribuições João Lima
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
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.
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.
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.
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.
Contribuição #2 (cont.) • Análise • Dúvidas • Melhor reposicionar a ementa? • AcordaoTexto e Decisão é a mesma coisa?
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.
Contribuição #3 (Cont.) • Análise • (I) Transforma elementos em tipos • TextoType • <p>* • TextoSimplesType • Apenas um <p> • (II) Criar um elemento para conter o nome dos agrupadores.
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.
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).
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, • <descritor> ::= <datasOuAno> ";" ... <datasOuAno> ::= <datas> | <ano>
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...)
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.
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.
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).
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.
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.
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 “!”
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 "#". • 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. • 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 <fragmento>" 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.
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". • 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. • 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.
Contribuição #7 (Cont.) • Análise • Situação Atual: • <documentoComplexo> ::= <documento> [ ":" <fragmento> ] • Situação Proposta: • <documentoComplexo> ::= <documento> [ “#" <fragmento> ] • 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)
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 <fragmento>", acrescentar, após os exemplos, o texto
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): • todo id-particao é convertido para "id('strIdParticao')" • todo intervalo-ids é convertido para "id('strId1')/range-to(id('strId2')))" • o conjunto com mais de um fragmento (separado por virgula) é convertido em um conjunto separado por "|" (pipe). • 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 • 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).
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.
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: <documentoComplexo>@<documentoIndividual>!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.
Contribuição #9 (Cont.) • Análise • Situação Atual: • <documento> [ ":" <fragmento> ] [ @ <docIndividual> ] • Situação Proposta: • <documento> [ @ <docIndividual> ] [ “!" <fragmento> ]
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 <seq-regional> referencia <numero> mas parece que o correto seria <numeral> • na seção 9.2 (e apêndice A), na definição do elemento <tipo-documento> falta acrescentar parêntesis: • <tipo-documento> ::= ( <tipo-norma> | <tipo-jurisprudencia> | <tipo-projeto-norma> ) [";" <nome-subtipo-sequenciador > ] | ( "publicacao.oficial;" <nome-periodico-oficial> [";" <nome-secao-periodico-oficial> ] ) • ou, se for o caso de realçar o fato de serem o sequenciador e a publicação oficial mutuamente exclusivos, • <tipo-documento> ::= ( <tipo-norma> | <tipo-jurisprudencia> | <tipo-projeto-norma> ) [ (";" <nome-subtipo-sequenciador > ]) | ("publicacao.oficial;" • Justificativa: • Garantir a consistência das BNFs.
Contribuição #10 (cont.) • Análise • Pela aprovação.
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: • 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? • <versao> e "retificacao" (sec. 10.6.4) são conceitos que se confundem, e podem acarretar ambiguidades (no uso e/ou no registro das URNs). • 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.
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).
Contribuição #11 (Cont.) • Com o uso do XPointer, e a adoção das convenções simples sugeridas, os problemas ficam resolvidos: • a semântica e a resolução (das componentes) ficam claras e mapeáveis para um esquema sólido: • o padrão XPointer é maduro: as implementações de resolução serão mais confiáveis. • é bem revisado: não corremos o risco de criar uma sintaxe inconsistente, inclusive com URIs. • torna o texto da LexML Parte 2 mais simples: basta citar o XPointer, não precisamos especificar detalhes. • não há mais confusão entre fragmento e componente: tudo é fragmento. • não há mais confusão entre <versao> e "retificacao". • o esquema de referência é uniforme: tudo é referenciável como XPoienter. • 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.
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)
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: • 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), • qual o elemento sintático principal, <documento> (sem alias)? • qual o papel do <documentoIndividual>? 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?
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).
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”.
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
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.
Contribuição #13 (Cont.) • Análise • Pela aprovação. • Obs.: • O evento é um elemento essencial no Modelo de Referência do LexML (FRBRoo).
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;<data>@versao.eficaz.em;<data>@versao.consultada.em;<data> • Exemplo: • urn:lex:br:federal:lei:2008-04-11;11501@versao.originalurn:lex:br:federal:lei:2008-04-11;11501@versao.vigente.em;2008-04-12
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.
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
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:
