Quoting Christophe Dupriez <[EMAIL PROTECTED]>:
> Thanks for the reference!
>
> It is really much more usable!
>
> Data in DSpace is mostly in one table (metadatavalue) which may be
> seen as / replaced by a triple store : do you think it would be
> possible to "remove a layer" to make things more integrated?
Hi Christophe:
This is a good question, and I agree it would be possible to remove that
layer - but I don't think that such tighter integration would result
in a better DSpace. A few reasons:
(1) There is a lot of metadata in DSpace (and a lot more to come) that
is not related to user discovery (technical metadata, e.g) - this
could live in a triple store - but would not benefit from it. In fact,
a lot or record-based metadata is accessed much more efficiently in a
RDBMS.
(2) Keeping a separate representation (in the triple store) allows DSpace
to enchance the discovery metadata with information not stored with
the item (subject maps, etc); indeed it allows us to combine in a
single user experience (the facetted browse in Dwell) content from
multiple DSpaces or even non-DSpace sources.
(3) The cost of maintaining the copy is very small. For example, Lucene
also contains a copy of most of the metadata (in an index optimized
for a particular type of search) - but it is easily generated and
synchronized, Search would not work very efficiently if we removed
that Lucene layer to increase integration. Dwell/Longwell works
similarly in this regard for facetted browsing.
Having said all this, I do predict that there will be considerably more
triple-store hosted data in DSpace over time (history, etc) - so we are
ceratinly believers in the technology.
Thanks,
Richard
>
> Have a nice day!
>
> Christophe
>
> Richard Rodgers a écrit :
>> Hi Christophe:
>>
>> See remarks below on Dwell...
>>
>> Thanks,
>>
>> Richard
>> On Fri, 2007-11-23 at 05:29 +0100, Christophe Dupriez wrote:
>>
>>> Hi MacKenzie, Mark and Jim!
>>>
>>> Thanks for insisting on the idea of a client based interface!
>>>
>>> DWELL:
>>> I will explore Dwell further. I tried it with
>>> http://simile.mit.edu/longwell/demo/libraries/ but it is rather
>>> slow from here.
>>>
>> That is a very old demo - Longwell's speed has improved. See
>>
>> http://dspace-test.mit.edu/dspace-longwell
>>
>> for a test server here at MIT using more recent code.
>>
>>
>>> Is the inventory of values for a given facet evaluated locally,
>>> in DSpace or in an intermediary server application?
>>>
>>
>> Dwell is a server application with an RDF triple-store backend
>> (like DSpace's database, but in RDF) - the metadata is a copy of what is
>> in DSpace - optimized for presentation in the Dwell UI.
>>
>>
>>> I understood Dwell is based on OAI-PMH but there is no "Search"
>>> request in OAI-PMH.
>>>
>>
>> Actually, Dwell is independent of how the metadata is obtained, so it
>> does not rely on OAI-PMH. We have provided an OAI-PMH exporter as one
>> way to feed Dwell. In 1.5, we are adding another way based on the event
>> mechanism, and there is already a large library of SIMILE tools for
>> turning a lot of metadata formats into the RDF Dwell expects.
>>
>>
>>> An extension has be defined for this:
>>> http://www.dlese.org/dds/services/oai2-0/odl_service_documentation.jsp
>>> but I suppose it is not part of DSpace (am I wrong?).
>>> OAI-PMH+Search(ODL) has similar capabilities than RSS and would
>>> ensure better metadata transmission.
>>>
>>> RSS:
>>> Mark+Jim advice opened my eyes on a simple fact: RSS standard(s)
>>> may be used to represent a DSpace search result set (if I add a RSS
>>> flow generation to DSpace search).
>>> The nice thing with RSS is the potential promise of "subscription"
>>> for searches where new records are regularly retrieved and
>>> highlighted.
>>>
>>> RSS clients are not completely aware of their potential for
>>> databases searches (and not only news feed) and could be improved
>>> to manage easily simple ad hoc searches and not only
>>> "subscriptions" to searches.
>>> Some of them have the three frames interface I wish for my users to
>>> browse DSpace results (like an e-mail management software).
>>> I made some experiments with RSSBandit (open-source:
>>> http://www.rssbandit.org/ ) and I think it is a possible way to go.
>>>
>>> Anybody digged in that direction?
>>>
>>> Christophe
>>>
>>> MacKenzie Smith a écrit :
>>>
>>>> Hi Mark,
>>>>
>>>>> I've been saying for some time that, nice as the DSpace user interface
>>>>> is in many respects, it is not and should not be the only way to plumb
>>>>> a DSpace archive. If it is (currently) difficult to get a particular
>>>>> search style put into DSpace, may I suggest trying a different
>>>>> approach.
>>>>>
>>>>> One could harvest metadata via the PMH responder, organize them any
>>>>> way one wishes, and search them in any desired way.
>>>>>
>>>> I can't resist pointing out that this is exactly what "DWell" does
>>>> -- the faceted browsing
>>>> and search UI that is layered over DSpace via an OAI-PMH plugin
>>>> for RDFized metadata.
>>>> See http://simile.mit.edu/wiki/Dwell or Richard Rodger's
>>>> presentation on same at
>>>> http://www.aepic.it/conf/viewpaper.php?id=212&print=1&cf=11
>>>>
>>>> I think this is an excellent approach to building better DSpace
>>>> UIs, and just leaves us
>>>> with the problem of the underlying data rigidity, which I hope we
>>>> can address by relying
>>>> more on RDF or other rich metadata that is stored in the
>>>> assetstore alongside the content
>>>> files. The current DSpace metadata tables are great for managing
>>>> content, but suboptimal
>>>> for discovering what's in the repository (assuming we can get
>>>> better discovery metadata
>>>> from outside the system, somehow).
>>>>
>>>> MacKenzie
>>>>
>>>>
>>> -------------------------------------------------------------------------
>>> This SF.net email is sponsored by: Microsoft
>>> Defy all challenges. Microsoft(R) Visual Studio 2005.
>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>>> _______________________________________________ DSpace-tech mailing
>>> list [email protected]
>>> https://lists.sourceforge.net/lists/listinfo/dspace-tech
>>>
>>
>>
>>
>>
>>
>
>
-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell. From the desktop to the data center, Linux is going
mainstream. Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
DSpace-tech mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-tech