Danny Ayers wrote:
> On 8/8/05, Stefano Mazzocchi <stefanom_at_mit.edu> wrote:
>
>
>>>initial notes -
>>>http://dannyayers.com/archives/2005/08/07/longwell-blog-view/
>>
>>We are aware of the facets-as-URI limitation of longwell1, you might
>>want to try out the 2.0 from svn (this is the longwell that powers
>>piggy-bank and doesn't have that limitation).
>
>
> Thanks - hopefully I'll have chance in the next few days to move to
> that version. Any particular reason it's not fed into the Longwell
> release?
Longwell1 has features that Longwell2 still doesn't have, for example
the ability to configure what is considered a facet and what is not and
what is to be considered a primary object and what is just corrollary
data. Longwell2 was designed as a merge between Longwell1 and Knowle, so
that it would be able to fall back to a useful representation if the
system didn't know anything about the ontologies it was working with
(which is something that we expected to happen in a piggy-bank situation).
Longwell2 will be released once it matches longwell1 functionality,
meaning that if you *do* know more about the data, you can use that
information to further customize and make your view a little more useful
than just the standard 'one-size-fits-all' views that currently
longwell2 has.
In order to achieve this functionality, we'll integrate Ryan's work on
Fresnel. The original roadmap was to release a longwell2 with fresnel
support at the end of the summer, but I'm not sure if we can keep up
with that schedule.
>>>Does anyone happen to have a bridge to Redland?
>>
>>Nope, no idea on how to use redland from java.
>
> There is a Java binding, not tried it myself.
Needless to say, patches are welcome :-)
>>>I've a load of data in
>>>that I'd rather like to see in Longwell too.
>>
>>dump it out and load it up.... I know it would be nice to be able to
>>point longwell to an existing triple store but since triple stores don't
>>support fulltext-searching, it's very tricky to get the lucene indexes
>>in longwell synchronized with a backend triplestore.
>>
>>that part of the architecture is something I really dont' know how to
>>fix... I think I'll have to wait for full-text extensions to sparql.
>
>
> Ok, thanks. I keep running into the store sync issue, but this is the
> first time non-RDF data (the Lucene index) has been involved. Hmm,
> right, and it doesn't exactly line up against SPARQL regex.
Yup.
I think Erik (hatcher) also ran into this problem while working on
sychronizing kowari and lucene indexes.... one architectural vision
would be to add full-text search potentials to the triple store and
avoid the synchronization issue alltogether.
Another one, more general and probably less intrusive for the triple
stores, is have the ability to register listeners to the triple store
itself, and get some code called back whenever there is some event
taking place (all major content repositories work this way).
The best way would be to be able to have an API such as:
void registerHook(Query query, Listener listener);
where a given listener is called by the triple store everytime a
statement is added/changed/removed that belongs to a particular result
space of the given query.
With that, we could do things like:
1) update the lucene indexes
2) invalidate caches at the webapp level
3) trigger synchronization between different stores
4) send notification events
...
the JSR 170 API (java content repository) has a pretty established API
for this aspect and it's extremely useful.
--
Stefano Mazzocchi
Research Scientist Digital Libraries Research Group
Massachusetts Institute of Technology location: E25-131C
77 Massachusetts Ave telephone: +1 (617) 253-1096
Cambridge, MA 02139-4307 email: stefanom at mit . edu
-------------------------------------------------------------------
Received on Mon Aug 08 2005 - 17:44:28 EDT