On 1/6/12 6:36 AM, Augusto Herrmann wrote:
On Wed, Jan 4, 2012 at 12:51 PM, Kingsley Idehen<[email protected]> wrote:Augusto,Awesome! See: 1. http://linkeddata.uriburner.com/describe/?url=http%3A%2F%2Fvocab.e.gov.br%2F2011%2F03%2Fvcge%23imigrantesCool! Thanks.2. http://linkeddata.uriburner.com/fct/rdfdesc/usage.vsp?g=http%3A%2F%2Fvocab.e.gov.br%2F2011%2F03%2Fvcge%23imigrantes -- listed named graph IRIs showcases fact that we processed N3 and the Microdata with identical results .Sounds great, but things are not as good as it looks. The server is configured to perform HTTP content negotiation. I believe the Linked Data URI Burner sends an Accept header on its request that causes conneg to serve the RDF file instead of HTML. No wonder the results are identical! The only triple in RDFa in the HTML representation there is the one I mentioned before. Marking up the tree is still in our todo list. At the moment, the tree data is loaded from a JSON source and the DOM tree is constructed in javascript and a JQuery library named jstree. Another error we identified is that the slug identifier is used as an id for the DOM node. However, as the vocab is polyhierarchical, nome terms appear more than once. So we need to change that, as no DOM nodes should share the same id. Thanks for the feedback! I hadn't thought of using URI Burner on it before. Best regards, Augusto Herrmann
What about the Microdata in the HTML? Is that as sparse as the RDFa re. triples embedded in the HTML?
Re. URIBurner, note its ability to produce both RDFa and Microdata from the RDF it negotiates. Ditto JSON-LD :-)
-- Regards, Kingsley Idehen Founder& CEO OpenLink Software Company Web: http://www.openlinksw.com Personal Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca handle: @kidehen Google+ Profile: https://plus.google.com/112399767740508618350/about LinkedIn Profile: http://www.linkedin.com/in/kidehen
smime.p7s
Description: S/MIME Cryptographic Signature
