Fórum do Projecto Research.IKF E!2235

Q1: (JNO, 2004.6.1) A todos os investigadores do Research.IKF-P: esta questão pretende iniciar a discussão electrónica sobre o standard de representação de conhecimento proposto no relatório da Cândida (bolseira Research.IKF em 2003) e posteriormente alterado pelo Miguel Cruz. A questão é: em termos gerais, qual é a vossa opinião sobre o modelo proposto?

• (GRL, 2004.6.1) Minha visão sobre este documento não é muito clara, pois o analisei com o sentido de fazer um mapeamento de nossa linguagem de especificação de extração de Topic Maps a partir de fontes heterogénas de informação (XS4TM? - XML Specification for Topic Maps). Eu pretendo fazer uma validação formal da linguagem XS4TM? em VDM. Por isso, as informações que retirei deste documento foram seguindo este intuito. Ainda não o analisei como sendo uma representação de conhecimento, pois adoptamos XTM como modelo, não prevendo uma alteração no modelo proposto pela ISO.

• (MCZ, 2004.06.09) Este documento pretende modelar a representação do conhecimento de forma a servir de base à implementação do “Knowledge Representation Model” na camada funcional de “Advanced Services”, tal como é visível no esquema de arquitectura global do sistema. A minha acção sobre o modelo resumiu-se a melhorar os critérios de classificação atributiva de objectos, e a fazer algumas propostas visando a melhoria de métricas de similaridade entre objectos e o acrescento de modalidade temporal e eventualmente modalidades genéricas. Em termos de implementação, não se pretende ter modalidades genéricas, mas sim identificar duas ou três modalidades com interesse para implementar. Após esta discussão pretende-se ter um documento com o modelo a adoptar. A minha opinião é de que o modelo apresentado, enriquecido com as propostas “Object Comparision Metrics – proposal II” e “Temporal Modality” é um bom modelo. (Não tive grandes cuidados com os invariantes, pelo que essa parte está concerteza incompleta no documento apresentado).

• (PFS, 2004.06.23) Depois de uma análise geral do documento, fiquei com a ideia que o modelo proposto é bastante interessante e apresenta boas potencialidades. No entanto, após a sua utilização para tentar modelar um problema específico da minha área (infocare), surgiram-me algumas dúvidas:
  • Na definição de atributos, um 'LinkType' é utilizado para referenciar instâncias de uma determinada classe, indicando-se a cardinalidade desta relação. A cardinalidade é definida por um valor mínimo e um valor máximo, ambos naturais maiores que zero. A imposição que o limite mínimo não pode ser zero impede relacionamentos potencialmente nulos entre objectos. A existência de um limite máximo também pode limitar a sua utilização em situações em que esta não esteja definido à partida. A minha pergunta é se não seria possível permitir que o limite mínimo tomasse o valor 0 e que o limite máximo fosse opcional.
  • O função 'okIDs', que testa o invariante sobre os identificares, não garante a unicidade global dos identificadores dos atributos definidos em 'AttributeDefinitions'. Apenas garante que os identificadores de atribuito utilizados em classes são únicos.
  • Para garantir coerência, a definição dos atributos passou a ser feita globalmente em 'AttributeDefinitions'. No entanto, nada é dito quanto à forma como os atributos definidos são referenciados nas classes e nos objectos. Presumo que utilizando o mesmo identificador de atributo, mas seria importante isso estar referido na documentação e formalizado num invariante.
  • A forma como a definição de atributos de uma classe foi feita, obriga a que sejam atribuídos valores aos mesmos quando se define a classe. No entanto, é possível que valores para estes atributos só tenham sentido no contexto dos objectos que instanciam a classes. Não faria mais sentido, nas classes, poder-se também especificar atributos sem valor atribuído, ou estou a ter uma visão demasiado influenciada pela programação orientada aos objectos?

• (RCA, 2004.06.28) Como Standard para representação do conhecimento, penso que o modelo está bem alinhado com as motivações já implicadas em outros modelos, como XTM e RDF! Não comento aqui referencias para o SOUR por perceber que este modelo entra numa perspectiva mais de comparações entre os objectos relacionados no seu modelo, seguindo para uma outra linha que não a dos modelos previamente mencionados.
  • Portanto, partindo de um modelo do tipo XTM bem utilizado pela comunidade academica e comercial (por si), e pela sua simplicidade, a expressividade deste modelo permite uma representação complexa e rica em detalhes documentais e associativos entre os seus objectos. Por outro lado, o modelo IKFP tem uma perspectiva mais abrangente de representação na medida em que são incorporados fuzzy sets para representação de incerteza, e gestão de regras para não somente representar mais também inferir sobre o conhecimento representado.
  • Em algumas vezes, nas reuniões, foi comentado que o XTM é uma instancia do IKFP. Gostaria de levantar aqui uma pequena discussão...Penso que Talvez seja, mas não tão directamente!
  • Um documento XTM traz consigo 3 conceitos gerais, tópicos, associações e ocorrências. As minhas percepções são de que:
    • Os tópicos, podem ser incorporados de forma directa para as CLASSES(IKFP), e por sua vez para OBJECTOS(IKFP), dependendo do contexto.
    • As associações, podem ser também incorporadas para CLASSES(IKFP), porem perdem valor semântico(modelo XTM). Será interessante ter esta ideia de associações no IKFP?
    • As ocorrências, podem ser as instanciações OBJETOS(IKFP), mas também dependentes do contexto.
  • As demais propriedades do modelo XTM, podem vir a ser incorporadas também segundo algumas considerações. Na linguagem que o Giovani referenciou (XS4TM? ) a representação de conhecimento é ditada pela especificação de uma ontologia (preservando conceitos do modelo XTM) para um determinado domínio de aplicação. De maneira que o produto final é um documento XTM relacionando os conceitos e associações definidas dentro da própria ontologia.
    • Um dos pontos que me chama atenção é no que diz respeito ao (Merge) dos conceitos, ou (Merge) dos OBJETOS(IKFP). O Modelo XTM tem sua própria implementação para (Merge) de conceitos. Entretanto, (Merge) no sentido de integrar informação de maneira a torna-la completa num determinado contexto, tem sentido a implicação de outras variantes para a definição de (Match) entre Objectos, e para além disto, "Workunits" “drives” que seleccionam conceitos ou objectos para aplicação de (Match), e posteriormente, (Merge) entre (objectos).
    • Por exemplo em aplicações de CRM/DBM é fundamental a criação da visão única, ou vista unificada do Cliente, pretendo ser "a visão 360 do cliente", no que tange ao seu “rastro” dentro de uma organização. Imaginamos neste contexto a situação em que o endereço do cliente provém de 3 origens distintas, mas que para a montagem do conceito Endereço final é necessário aplicar algumas "regras", para se definir o que capturar de cada origem para resultar no endereço final mais completo. Para além disto, o processo de transformação dos dados não nos interessa "apriori", mas deve ter implicação em situações de (Merge).
    • Portanto, talvez todas estas questões passem apenas pelo corpo funcional de implementação e não precisem ser incorporadas ao modelo IKFP. Por outro lado, quando se tenta relacionar varias fontes de dados para a criação de uma representação única de um contexto, não passaram ilesos critérios para unificar conceitos ou para dizer que estes são os mesmos perante uma "regra" de comparação. Penso que é este deve ser um ponto em discussão sobre o modelo IKFP.
  • Por fim, em termos do próprio extractor (de bases de dados relacionais), tomando como base o XS4TM? , o resultado final é uma base relacional (baseada em Topic Maps). Para a nossa realidade, não é bem assim, terá que ser revista uma especificação mais (IKFP oriented) para popular o modelo IKFP relacional. As demais features do gerador de topic maps, são perfeitamente adaptáveis a realidade do projecto, mas é verdade que ainda são necessárias modificações!
  • Actualmente tenho focado a atenção a primeira parte que é a especificação dos (datasources) e (dataset), integração XML e já alguns testes e prototipação em C#. A posterior penso que pode se trabalhar em cima de XS4TM? para uma especificação de Ontologia para o IKFP "XS4TM4IKFP"...ou não! Penso que também é um ponto de discussão, certo?

• (TLA, 2004.10.23) Os problemas com que me deparei durante a realização do projecto E-Learning Vertical Area foram basicamente os mesmos que os encontrados por PFS. Para colmatar essas falhas foram efectuadas as seguintes alterações ao modelo Research.IKF-P KR que levou a um novo standard (ikf-p-200408.vdm.ps) que pode ser encontrado em Research.IKF Private. A mesma informação pode ser encontrada no relatório de estágio (elearn-20041022.tgz):
  • A especificação da cardinalidade do LinkType? foi alterada permitindo agora como mínimo 0 (zero) e a definição opcional de um valor máximo. Isto permite expressar relações nulas (no primeiro caso) e relações com um número indeterminado (possivelmente infinito) de objectos.
  • Foi introduzido um conjunto mais rico de tipos básico (Ground). Agora é também possível expressar valores booleanos e datas/horas.
  • A valoração de atributos foi alterada, de forma a permitir maior expressividade à atribuição de um valor nulo num atributo. Na versão anterior do modelo isto também era possível, no entanto, a forma como era feito dependia do tipo do atributo. Por exemplo se o atributo fosse do tipo ground poderia ser ter o valor "nil" se fosse do tipo Link então teria um conjunto vazio. Com esta alteração, basta atribuir o valor "nil" ao atributo para expressar a não atribuição de valor.
  • Todos os invariantes foram redefinidos por se encontrarem incorrectos e/ou incompletos.
  • A documentação foi melhorada, encontrando-se, no entanto, incompleta.

Fórum do Projecto Research.IKF E!2235

Q3: (JNO, 2004.6.1) "Modalities of change": sugiro a leitura do relatório krenov.pdf que está na sub-directoria "Knowledge Renovator" da nossa área reservada a quem pretender colaborar nesta discussão. São de novo benvindas todas as críticas.

• ()...

Related

Research.PURe

50 Recent Changes in TWiki Web retrieved at 18:24 (GMT)

See also: RSS feed, recent changes with 50, 100, 200, 500, 1000 topics, all changes

See also the faster WebTopicList

• EdgarAlves
• EduardoAbreu
• GiovaniRubertLibrelotto
• JoseCarlosRamalho
• JoseJoao
• JoseNunoOliveira
• LuisNeves
• LuisSoaresBarbosa
• MiguelCruz
• OlgaPacheco
• PauloSilva
• PedroRangelHenriques
• RonnieAlves
• TiagoAlves
• NunoRodrigues

Related topics: TWikiUsers, TWikiRegistration

Warning

Can't INCLUDE TWiki.WebSearchAdvanced repeatedly, topic is already included.

• Forum
• ForumQ1
• ForumQ2
• ForumQ3
• IkfNews
• MenuTopics
• ProjectMembers
• WebChanges
• WebHome
• WebIndex
• WebLeftBar
• WebNotify
• WebPreferences
• WebRss
• WebSearch
• WebSearchAdvanced
• WebStatistics
• WebTopicList

See also the verbose WebIndex.