libby: natural langauge processing of freetext and describing the result in an rdf graph; and then comparing various RDBMS and Sparql queries
libby: aim practical query application where user enters query, the app summarises and gives them options to refine query (with these new queries derived from the data so you know there's anwsers)
libby: you start with data with significant words annotated with types and the run machine learning tools over it
libby: aim practical query application where user enters query, the app summarises and gives them options to refine query (with these new queries derived from the data so you know there's anwsers)
libby: you start with data with significant words annotated with types and the run machine learning tools over it
libby: adaptive, work-centered User interface technology
libby: problem-vantage-frame ontology
libby: seems sort fo vaguely in the same area (pdf)
libby: generate lots of nice different UI components from the same data
libby: working to an open source release of this at the end of this quarter
libby: problem-vantage-frame ontology
libby: seems sort fo vaguely in the same area (pdf)
libby: generate lots of nice different UI components from the same data
libby: working to an open source release of this at the end of this quarter
libby: want to connect non-rdf databasesa to the semweb without custom code for each one
logger: See discussion
logger: See discussion
ldodds: AndyS interested in hearing about commonly needed functions/extensions, so can be included in distro
danbri: geo, geo, geo...
ldodds: potential for other engine authors to implement same functions/extensions
danbri: geo, geo, geo...
ldodds: potential for other engine authors to implement same functions/extensions
libby: biomedical images, multidimensional, very large images, many pixels; cannot do image recognition. Want to capture as much metadata as possible automatically, e.g. the microscope; contextual data
ldodds: Project website
oD: Because people are busy doing research, the idea is to make it as simple as possible to add metadata and to automate this process where possible. e.g. by extracting information such as the type of microscope used from the image header or what the image submitter was working on that day.
logger: See discussion
ldodds: Project website
oD: Because people are busy doing research, the idea is to make it as simple as possible to add metadata and to automate this process where possible. e.g. by extracting information such as the type of microscope used from the image header or what the image submitter was working on that day.
logger: See discussion
libby: goal: seamless access to legacy relational stores using jena
libby: part is 4.3m article headers -> 200million triples
libby: lots of data. queries need to be performant
libby: compared jena, kowari and sesame; perferred jena because - relational database, good support, can see the raw data in database; schemagen; and most importantly scalable in loading and query
libby: 5000 triples eems like a good batch size for loading
libby: problem: making sure non-rdf programmers can use the rdf code ok - java interface hierarchy for everything; costs are that flexibility is lost
libby: solution RESTful xml api as a partial solution
libby: performance testing queries. no types; no uri, lieral filtering - performance non-scalable. Better when rdf:typed (need to see slides for the detail here; had to do with the query planner treating them differently; worth experimenting with different variations on teh same query)
libby: currently working on adding non-journal content; also enabled other develeopers to use rest API; also replication; starting on queuing rather than batching; sparql merging with external named graphs
libby: demo with amazon using rdf version of amazon api and some sameas statements; and then query using named graphs and sparql.
libby: "Jena is a good choice for a commercial triplestore"
ldodds: Posting about Amazon/Ingenta data mashup demo from talk
libby: lots of data. queries need to be performant
libby: compared jena, kowari and sesame; perferred jena because - relational database, good support, can see the raw data in database; schemagen; and most importantly scalable in loading and query
libby: 5000 triples eems like a good batch size for loading
libby: problem: making sure non-rdf programmers can use the rdf code ok - java interface hierarchy for everything; costs are that flexibility is lost
libby: solution RESTful xml api as a partial solution
libby: performance testing queries. no types; no uri, lieral filtering - performance non-scalable. Better when rdf:typed (need to see slides for the detail here; had to do with the query planner treating them differently; worth experimenting with different variations on teh same query)
libby: currently working on adding non-journal content; also enabled other develeopers to use rest API; also replication; starting on queuing rather than batching; sparql merging with external named graphs
libby: demo with amazon using rdf version of amazon api and some sameas statements; and then query using named graphs and sparql.
libby: "Jena is a good choice for a commercial triplestore"
ldodds: Posting about Amazon/Ingenta data mashup demo from talk
libby: "hot potato" task management system using Jena
libby: excira, the company that made stargazer
libby: only used internally so far
libby: excira, the company that made stargazer
libby: only used internally so far