Usando a Ontologia OWL Time

Informações de tempo como horário de início ou duração de um programa, a data em que uma nova série começa a ser transmitida ou é encerrada, o ano em que um filme ou artista ganhou um prêmio, dentre outras informações temporais

são bastante comuns de serem requisitadas. A partir de necessidades como estas, juntamente com os dados operacionais categorizados como ―Unidade de Tempo‖, tornou-se essencial que a CoreKTV também fornecesse meios de estabelecer a descrição temporal associada ao conteúdo multimídia.

Entretanto, como a descrição de informações de tempo é bastante comum em diversos outros domínios, após elencar os conceitos que deveriam ser fornecidos na Ontologia Núcleo, buscou-se encontrar uma ontologia que apresentasse objetivos semelhantes e, com isso, equivalência de conceitos. Desta forma, fica reforçada uma das premissas da Web Semântica, na qual a reutilização e extensão de conhecimento e, com isso facilitar a integrabilidade entre sistemas.

A ontologia OWL Time (W3C; 2006) foi desenvolvida pelo Grupo de Trabalho para Desenvolvimento da Web Semântica, e se propõem a descrever conteúdo e propriedades temporais de páginas e serviços da Web. Ela fornece um vocabulário para expressão de fatos sobre relações topológicas entre instantes e intervalos, juntamente com informações sobre data, horário e duração. A sua utilização junto à CoreKTV passa por reuso de dois conceitos básicos: o de descrição de data e duração de intervalo de tempo, além de propriedades que estabelecem a conexão com conceitos relacionados à conteúdo multimídia da CoreKTV. Assim, temos o uso das seguintes classes:

 DateTimeDescription:representa a descrição de uma data com horário;  DurationDescription: representa a descrição de um intervalo de tempo ou

seqüência temporal.

Além da definição das classes, também foram estendidos os campos de year, month, day, hour, minute e second, correspondendo aos atributos de ano, mês, dia, hora, minuto e segundo, respectivamente. Com isso, a partir da reuso dessas classes e atributos, ou propriedades de dados, foram definidas as seguintes propriedades, cujas finalidades estão na ligação entre os conceitos definidos pela CoreKTV e as duas classes descritas acima.

1. hasDuration: possui a classe MMContent como domínio e DurationDescription como contradomínio.

2. hasAwardYear: possui a classe Award como domínio e a classe DateTimeDescripntion como contradomínio.

3. hasAwardDate: possui a classe Award como domínio e a classe DateTimeDescripntion como contradomínio, considerando apenas o campo year.

4. hasDepictedDate: possui a classe MMContent com domínio e a classe DateTimeDescription como contradomínio.

5. hasDepictedYear: possui a classe MMContent com domínio e a classe DateTimeDescription como contradomínio, considerando apenas o campo year.

6. hasFinishDate: possui a classe MMContent com domínio e a classe DateTimeDescription como contradomínio.

7. hasFinishTime: possui a classe MMContent com domínio e a classe DateTimeDescription como contradomínio, considerando apenas os campos hour, minute e second.

8. hasLocalOffsetTime: possui a classe GeographicArea como domínio e a classe DurationDescription como contradomínio.

9. hasLocalTime: possui a classe MMContent com domínio e a classe DateTimeDescription como contradomínio.

10. hasProductionDate: possui a classe MMContent com domínio e a classe DateTimeDescription como contradomínio.

11. hasProductionDate: possui a classe MMContent com domínio e a classe DateTimeDescription como contradomínio, considerando apenas o campo year.

12. hasReleaseDate: possui a classe MMContent com domínio e a classe DateTimeDescription como contradomínio.

13. hasReleaseYear: possui a classe MMContent com domínio e a classe DateTimeDescription como contradomínio, considerando apenas o campo year.

14. hasStartDate: possui a classe MMContent com domínio e a classe DateTimeDescription como contradomínio.

15. hasStartTime: possui a classe MMContent com domínio e a classe DateTimeDescription como contradomínio, considerando apenas o campo year.

4.4 Componente Semantic Integration

O componente chamado Semantic Integration, mostrado na Figura 18 representa o ponto de início da integração entre a plataforma tradicional da TVDI e a infraestrutura do Konwledge TV. A sua principal função é realizar a captura de

dados e informações que sejam processadas e utilizadas em diversos serviços e aplicações baseadas em conhecimento, desenvolvidas a partir da plataforma do KTV. Para isso, ele está inserido no núcleo comum do middleware Ginga, conforma arquitetura ilustrada na Figura 44, e mantém comunicação direta com os componentes de sintonização e provedor de informações de serviço.

Apesar de não estar presente na norma que descreve uma arquitetura sugerida para o middleware Ginga, a criação deste componente tornou-se essencial para a construção da infraestrutura semântica no modo cliente-servidor. Tal necessidade foi levantada a partir de dois pontos: (i) atualmente, não há especificação no Ginga de unidades capazes de fornecer semântica às informações obtidas do fluxo, com isso, foi necessário especificar agentes que se comunicam com demais componentes do middleware para captar dados; (ii) as restrições físicas existentes no terminal tornam inviável embarcar toda a infra-estrutura do KTV, tornando necessária a definição de uma unidade de processamento inicial, o Semantic Integration, no ambiente do Set-Top-Box. A arquitetura do componente foi desenvolvida a partir do guia de desenvolvimento de componentes do projeto GingaCDN (LAVID; 2010), disponível para implementação no modelo FlexCM (MIRANDA FILHO et. al.; 2007).

Figura 44 - Componente Semantic Integration na arquitetura do middleware

Ginga

Conceitualmente, o componente Semantic Integration é constituído por duas unidades básicas denominadas de agente Provedor e Monitor, responsáveis por

estabelecer a comunicação com os demais componentes do middleware para obtenção dos dados. Eles são os responsáveis pela recuperação de todas as informações relacionadas ao conteúdo e aos usuários.

A integração entre o componente e o ambiente de componente é realizada pela interface ISemanticAgent, que também é responsável por fornecer métodos comuns para encapsulamento das informações em arquivos XML, além de representar o meio de comunicação entre o componente e quem faz chamadas aos seus métodos. Os cabeçalhos da API do Semantic Integration podem ser encontrados no Apêndice B desta dissertação e também representam parte das contribuições deste trabalho.