[TGDK] Article Requires Revisions - comentários Professor Altigran

Resumo do professor Altigran sobre os comentários dos revisores

Nosso principal problema é o revisor 4, vejam abaixo:

Aspecto	Revisor 1	Revisor 2	Revisor 3	Revisor 4
Novelty	Novel solution	Novel solution	Novel problem & solution	No novelty
Relevance	Highly relevant	Highly relevant	Mostly relevant	Mostly irrelevant
Impact	Notable impact on narrow audience or small impact on broad audience	Small impact on narrow audience	Notable impact on narrow audience or small impact on broad audience	Little or no impact expected
Technical Correctness	No technical flaws	Frequent major technical flaws	Frequent minor or infrequent major technical flaws	Frequent major technical flaws
Clarity	Generally well-written; clear in large part	Difficult to understand; unclear in large part	Understandable, but various parts could be clearer	Difficult to understand; unclear in large part
Comentários	Nenhum	Nenhum	Nenhum	Nenhum
Expertise	Parcialmente familiar: leu sobre tópicos relacionados	Conhecedor: leu e trabalhou com tópicos relacionados	Conhecedor: leu e trabalhou com tópicos relacionados	Especialista: trabalhou extensivamente no tópico

Algumas outras coisas que acho que devem ser feitas:

Reestruturar a seção de trabalhos relacionados (atualmente na conclusão):

• Movê-la para antes da apresentação do framework.
• Ampliar a cobertura de trabalhos relacionados, incluindo abordagens semelhantes para KGs confiáveis.
• Comparar sistematicamente o CoaKG com outras soluções existentes para destacar a novidade e contribuição.
• Apontar lacunas claras nas abordagens anteriores e como o CoaKG as resolve.

Definir formalmente os conceitos centrais:

1. Fornecer definições precisas para contexto, metainformação, camadas (Trust, Knowledge, Decision) e Dual Open World Assumption (DOWA).
2. Explicitar como os conceitos se relacionam e são aplicados no framework.

Reforçar o detalhamento técnico do framework:

• Descrever formalmente os componentes do CoaKG (e.g., estrutura do grafo em camadas).
• Detalhar como a camada de confiança (Trust Layer) é implementada, incluindo regras e políticas.
• Apresentar um pseudocódigo ou fluxograma para as etapas principais de construção e consulta do CoaKG.

Incluir um exemplo gráfico do mapeamento de KGs para CoaKGs.

• Explicar o processo de inferência de contexto implícito com regras semânticas.
• Expandir a avaliação experimental:
• Adicionar mais exemplos práticos que demonstrem as vantagens do CoaKG em relação a outros KGs (não apenas Wikidata).
• Incluir métricas quantitativas (precisão, recall, tempo de execução) para medir o impacto e desempenho do framework.
• Testar a abordagem em casos de uso alternativos (e.g., DBpedia) para validar generalização.

Reformular o exemplo da Tabela 1:

• Usar gráficos em vez de tabelas para representar a estrutura do CoaKG, destacando as camadas e conexões.

Detalhar perguntas de competência (Competency Questions):

• Relacioná-las diretamente com os objetivos e métricas do framework.
• Demonstrar como as respostas são refinadas pelo mecanismo de consulta (Query Engine).

Demonstrar funcionalidade do motor de consulta (Query Engine):

• Disponibilizar código e documentação detalhada no GitHub.
• Mostrar como o motor responde a diferentes tipos de consultas (com e sem contexto).
• Comparar resultados do CoaKG com abordagens convencionais para destacar ganhos.

Resumir a introdução:

• Reduzir discussões sobre confiança e incerteza.
• Apresentar rapidamente o problema, a solução e os objetivos.

Melhorar clareza e gramática:

• Revisar o uso de terminologia técnica, removendo jargões desnecessários.
• Corrigir problemas de referências cruzadas, como a linha 223 mencionando "1" sem contexto.
• Revisar a formatação para garantir consistência em citações, espaçamentos e títulos.

Especificar detalhes do conjunto de dados:

• Justificar o uso de dumps antigos do Wikidata.
• Fornecer links diretos e versões utilizadas para reprodutibilidade.

Reescrever a conclusão:

• Focar em resultados concretos e limitações atuais.
• Evitar apresentar novas ideias (como integração com LLMs) sem detalhes.
• Apontar próximos passos para abordar as limitações identificadas.