Planeta Globo.com

Transitioning from a web of links and a sequence of words to a web of content, meaning and knowledge is probably the next great moving that we are going to see on the next two or maybe three years.

I was chatting with a friend, how can we bring knowledge to the web, how can we use the web to make a really efficient human driven search engine, last week a few former Googlers made some noise about a totally new SE named cuil, I tried some queries on that page, but it does work almost like google, you must be pretty much binary to retrieve some interesting information, in another words, nothing has changed since 90’s on this area. This problem is around researcher’s minds for a long time, trust, influence, authority when applied to the web are essentially people based issues.

The propose is the content being an asset with information about what it really means running against the link/words algorithms with no explicit meaning and a simple assumption “yes … we know you’re a good reference because you have a lot of links”.

Make yourself a question, how to ask something? How do I ask for information?

You ask your close friend: “Sunday night guitar red cap TV?” when you really want to know about the Sunday night TV show where a girl with a funny red cap playing a guitar. Things does change when you bring meaning to it, thats what a human being does.

Indeed, Google is still leading this running, with several fields under extreme research, articles about Data Mining, Collective Intelligence and AI being published denotes the new approach.

Yes … things are about to change

Como varias pessoas próximas a mim ja sabem eu deixei a RedHat em abril deste ano por motivos pessoais, o trabalho remoto mesmo tendo suas vantagens não conseguiu despertar em mim a mesma proatividade e cumplicidade que eu teria trabalhando com pessoas reais durante o dia-a-dia. Trabalhar em uma empresa em que eu pudesse estar fisicamente locado com um time e desenvolvendo um software incremental foram os motivos que me levaram a globo.com.

Dentro da gcom trabalhamos usando a metodologia Scrum, temos varios casos de sucesso e uma boa reputaçao no mercado brasileiro com a adoção desta metodologia. Mas o sucesso dos projetos não vem apenas do uso de uma metodologia agil, pessoas com otimas noções de negócio e tecnologia fazem o barco andar de forma gloriosa. Tive a sorte de participar logo no primeiro contato na empresa com profissionais que valorizam a qualidade de seu código, alem de entregar algo rápido e funcional também olham para o como fazer melhor, refatorar um algoritmo que não ficou bom em uma primeira abordagem, ou seja fazemos software.

Sempre brinco pelos corredores, que hoje em dia que as empresas se preocupam mais em vender a imagem que fazem o negocio de uma forma diferente das demais e deixam totalmente de lado as boas praticas de desenvolvimento que foram esculpidas durante anos de tentativas, erros e evoluções. Nasce ai o Scrume, a desculpa de usar a metodologia e/ou a abordagem agile com pessoas que não levam à paixão seu trabalho. Conversas que tive com o Philip calçado e artigos como “The Decline and Fall of Agile” veem apenas confirmar esta visão, anos de evolução sendo deixadas de lado por modismos.

Se você pensar de uma maneira racional, software vem sendo desenvolvido ao longo dos anos possibilitando avanços significativos em vários campos como biologia, astronomia e finanças para não me alongar, a não adoção do “scrum” não fez projetos como linux ou colocar o homem na lua com um tubo de 8088 por exemplo ser fadado ao fracasso. Ocorreram erros, acertos e em alguns momentos pessoas precisaram se sobrepor para trazer o bom senso a tona.

Concordo plenamente que a adoção do scrum por exemplo, aumenta a visibilidade dos problemas que ocorrem no desenvolvimento de features por termos um feedback rápido do cliente ou da organização, mas não é tendo apenas essa abordagem que fara seu projeto ser bem sucedido.

Os projetos hoje que dão certo, estão envoltos em uma gama de outros fatores que equilibram essa equação. Fica meu conselho, não é trazendo um evangelista e adotanto Scrum para sua empresa que fará seus projetos darem certo, mas se e somente se as pessoas envolvidas acreditarem no que estão fazendo.

I was looking for some documentation about using TDB and Pellet
reasoser on Jena without pet peeves, didn’t found anything usable at all, so after a few
attempts I was still fighting against an ambiguity error,
whenever Joseki tries to build a dataset, the following exception pops up

18:18:49 WARN  Configuration        :: Failed to build dataset from
description (service name: reason): cannot find a most specific type
for file:///joseki-config.ttl#dataset_reason, which has as
possibilities: ja:RDFDataset ja:InfModel.
com.hp.hpl.jena.assembler.exceptions.AmbiguousSpecificTypeException:
cannot find a most specific type for file:///Users/fmeyer/projects/semantic/
servicos/joseki/joseki-config.ttl#dataset_reason, which has as possibilities:
ja:RDFDataset ja:InfModel.
 at com.hp.hpl.jena.assembler.assemblers.AssemblerGroup$PlainAssemblerGroup.
 open(AssemblerGroup.java:104)
 at com.hp.hpl.jena.assembler.assemblers.AssemblerGroup$ExpandingAssemblerGroup.
 open(AssemblerGroup.java:70)
 at com.hp.hpl.jena.assembler.assemblers.AssemblerBase.open(AssemblerBase.java:41)
 at com.hp.hpl.jena.assembler.assemblers.AssemblerBase.open(AssemblerBase.java:38)
 at org.joseki.DatasetDesc.newDataset(DatasetDesc.java:65)
 at org.joseki.DatasetDesc.initialize(DatasetDesc.java:60)
 at org.joseki.Configuration.processModel(Configuration.java:112)
 at org.joseki.Configuration.(Configuration.java:83)
 at org.joseki.Dispatcher.setConfiguration(Dispatcher.java:130)
 at org.joseki.Dispatcher.initServiceRegistry(Dispatcher.java:100)
 at org.joseki.Dispatcher.initServiceRegistry(Dispatcher.java:93)
 at org.joseki.RDFServer.init(RDFServer.java:79)
 at org.joseki.RDFServer.(RDFServer.java:64)
 at joseki.rdfserver.main(rdfserver.java:85)

We just need to define a GraphTDB as a subclass of a Model as follow to fix this issue

@prefix ja:     <http ://jena.hpl.hp.com/2005/11/Assembler#> .
@prefix tdb:     </http><http ://jena.hpl.hp.com/2008/tdb#> .
 
## Initialize TDB.
 
[] ja:loadClass "com.hp.hpl.jena.tdb.TDB" .
tdb:DatasetTDB  rdfs:subClassOf  ja:RDFDataset .
tdb:GraphTDB    rdfs:subClassOf  ja:Model .
 
## ---- A whole dadaset managed by TDB
< #dataset_reason> rdf:type      ja:RDFDataset ;
  ja:defaultGraph < #inf_graph> .
 
< #dataset> rdf:type      ja:RDFDataset ;
  ja:defaultGraph < #def_graph> ;
  .
 
< #inf_graph> rdf:type  ja:InfModel ;
    ja:reasoner [
        ja:reasonerClass
            "org.mindswap.pellet.jena.PelletReasonerFactory" ;
       ] ;
    ja:baseModel < #tdbGraph> .
 
< #def_graph> rdf:type  ja:InfModel ;
    ja:baseModel < #tdbGraph> .
 
< #tdbGraph> rdf:type tdb:GraphTDB ;
    tdb:location "DB" ;
    .

What if a debugger could allow you to simply step BACKWARDS? Instead of all that hassle with guessing where to put breakpoints and the fear of typing “continue” one too many times… What if you could simply go backwards to see what went wrong? This is the essence of the “Omniscient Debugger” — it remembers everything that happened during the run of a program, and allows the programmer to “step backwards in time” to see what happened at any point of the program. All variable values, all objects, all method calls, all exceptions are recorded and the programmer can now look at anything that happened at any time

HomePage: http://www.lambdacs.com/debugger/debugger.html

Article: http://www.lambdacs.com/debugger/Article.html

Video: http://video.google.com/videoplay?docid=3897010229726822034&q=engedu+debugging