danbri: propValue became rdf:object and rdf:value, I think.
dajobe: we were thinking of moving into the RDF Core tests area
dajobe: should auto-gen dot/SVG -> PNGs too
danbri: Or into the RDFS spec working dir as primary home, exporting to rdf-tests periodically
dajobe: maybe better to keep all the tests together under test case doc managment
danbri: Ah, the monolithic central repository approach? ;-) I think best to keep them where they're owned, since these can't be versioned separated from the RDFS spec.
danbri: ie. if RDFS spec and its examples change but the version in rdf-tests doesn't, that's OK. But vice-versa would be less good.
dajobe: I guess rdfs changing at its own rate, best to keep them there
danbri: But I don't care _that_ much
dajobe: as long as you add a "make install" that does the copy automatically
danbri: Tricky, means automating a put to CVS or HTTP server. But if using ssh-agent etc would work...
dajobe: like: install:\ncp .nt .rdf test-dir; cd test-dir; cvs commit -m "Updated test cases on `date`" .rdf .nt
danbri: yeah, I guess i was glossing over it being in the same filetree
dajobe: should auto-gen dot/SVG -> PNGs too
danbri: Or into the RDFS spec working dir as primary home, exporting to rdf-tests periodically
dajobe: maybe better to keep all the tests together under test case doc managment
danbri: Ah, the monolithic central repository approach? ;-) I think best to keep them where they're owned, since these can't be versioned separated from the RDFS spec.
danbri: ie. if RDFS spec and its examples change but the version in rdf-tests doesn't, that's OK. But vice-versa would be less good.
dajobe: I guess rdfs changing at its own rate, best to keep them there
danbri: But I don't care _that_ much
dajobe: as long as you add a "make install" that does the copy automatically
danbri: Tricky, means automating a put to CVS or HTTP server. But if using ssh-agent etc would work...
dajobe: like: install:\ncp .nt .rdf test-dir; cd test-dir; cvs commit -m "Updated test cases on `date`" .rdf .nt
danbri: yeah, I guess i was glossing over it being in the same filetree
dmiles: #! Source Tree For LogicMOO CVS
dmiles: #|Source Tree For LogicMOO That works mostly with SWI-Prolog
dmiles: #|Source Tree For LogicMOO That works mostly with SWI-Prolog
tim-gone: Out of date, applies to a few weeks ago ... list of states in llyn.py is up to date
Wanted! A hackable HTML Imagemap editor implemented in Javascript (for SVG/RDF authoring, indirectly)
em: for a good time, call 'em'
em: any language possible (but prefer java)
em: anyone that knows how to do this in jena gets extra credit points... please help
danbri: I think libby's squish stuff does substrings, datatypes (not sure if the rdf2sql rewriter can handle that; my ruby port doesn't, I think). For 'simple inferencing', I'd compute all the subproperty arcs in advance; subprop hieararchies are rarely deep...
em: re inference... simple stuff as an example... load instance data using DC, load instance data using RSS, load RSS Schema (rss:title rdfs:subPropertyOf dc:title .) and be able to search both dc:title and rss:title for a term
em: any language possible (but prefer java)
em: anyone that knows how to do this in jena gets extra credit points... please help
danbri: I think libby's squish stuff does substrings, datatypes (not sure if the rdf2sql rewriter can handle that; my ruby port doesn't, I think). For 'simple inferencing', I'd compute all the subproperty arcs in advance; subprop hieararchies are rarely deep...
em: re inference... simple stuff as an example... load instance data using DC, load instance data using RSS, load RSS Schema (rss:title rdfs:subPropertyOf dc:title .) and be able to search both dc:title and rss:title for a term
AaronSw: Share your pictures or personal information with the world, thru the magic of RDFWeb's easy to use form interface.
sandro: Looks nice. When is it shipping, again? :-)