Job Opening - Tucson, AZ

Fedora Triple-stores, Kowari, RDF.

A new Ldap security filter has been released

Re: Fedora Triple-stores, Kowari, RDF.

Stewart,

We are currently employing MPTStore for our eSciDoc project, which makes
reasonable use of the triple store. Our experience with Kowari has been
painfull and frustrating. MPTStore is quite the opposite, but we share
your concerns regarding conformance to standards like Sparql. 

One very promising replacement for Kowari seems to be Mulgara
(http://www.mulgara.org/). The Topaz people have gained a lot of
experience with that product, so maybe it is worth the effort to get in
touch with them. 

Best,
Matthias.

> -----Original Message-----
> From: fedora-commons-users-bounces@... 
> [mailto:fedora-commons-users-bounces@...] 
> On Behalf Of Stewart Wallace
> Sent: Monday, June 04, 2007 3:29 AM
> To: fedora-commons-users@...
> Subject: [Fedora-commons-users] Fedora Triple-stores, Kowari, RDF.
> 
> All,
>  
> forgive a fairly open-ended inquiry but I am trying to get an 
> idea of the status of the RDF/triple-store option for 
> accessing a Fedora repository.  I see on the sourceforge site 
> that Kowari is listed as "no longer under development".  The 
> MPTStore alternative has more limited search options and 
> apparently neither of these yet supports Sparql which I 
> gather is likely to be the query-language of choice down the 
> track (maybe that's questionable).  Also, there seem to be 
> significant developments in store for Fedora 3.0 in this area.
>  
> More generally, I'm struggling to find examples of large, 
> public, websites or other digital resources based on RDF.  
> Are there any projects out there making significant use of 
> the triple-store as a primary access mechanism (NSDL might be one)?
>  
> Here at the Dictionary of Sydney project we want to present 
> complexly inter-related concepts and resources to do with the 
> history of the city - I suspect RDF is an appropriate 
> mechanism but uncertainty around its implementation and the 
> lack of projects and support (particularly here in Australia) 
> gives me concerns that we may find ourselves on a bleeding 
> rather than a leading edge.
>  
> Any thoughts you have regarding this or information on other 
> projects you are aware of would be greatly appreciated .  I'm 
> also wondering if there is an anticipated release date for 3.0.
>  
> Thanks
>  
>  
> 
> Stewart Wallace
> Project Manager, Dictionary of Sydney
> Mob: 0417 420 155
> www.dictionaryofsydney.org 
> <file:///C:/Documents%20and%20Settings/swallace/Application%20
Data/Microsoft/Signatures/www.dictionaryofsydney.org> 
> 
> ______________________________________________________________
> _________________________________
> This email and any files transmitted with it are intended 
> solely for the use of the addressee(s)
> and may contain information that is confidential or subject 
> to legal privilege. If you receive this
> email and you are not the addressee (or responsible for 
> delivery of the email to the
> addressee), please note that any copying, distribution or use 
> of this email is prohibited
> and as such, please disregard the contents of the email, 
> delete the email and notify the sender
> immediately.
> ______________________________________________________________
> _________________________________
> 	
> 

-------------------------------------------------------

Fachinformationszentrum Karlsruhe, Gesellschaft für wissenschaftlich-technische Information
mbH. 
Sitz der Gesellschaft: Eggenstein-Leopoldshafen, Amtsgericht Mannheim HRB 101892. 
Geschäftsführerin: Sabine Brünger-Weilandt. 
Vorsitzender des Aufsichtsrats: MinDirig Dr. Wolfgang Stöffler.

Re: Fedora Triple-stores, Kowari, RDF.

Re: Fedora Triple-stores, Kowari, RDF.

Hi, Stewart
> More generally, I'm struggling to find examples of large, public, 
> websites or other digital resources based on RDF.  Are there any 
> projects out there making significant use of the triple-store as a 
> primary access mechanism (NSDL might be one)?
I'm with the NSDL, and one of the developers of MPTStore.   We do not 
really expose much in terms of RDF in our public services at the current 
time, but it plays an important part in our backend object model, which 
essentially forms a large graph.   We make extensive use of both simple 
and moderately complex RDF/graph queries in our infrastructure, which 
has been using MPTStore for the last eight months or so. 

Here is a copy of a presentation we gave at the Open Repositories 
conference back in January, which should explain our situation in a bit 
more detail:
http://www.slideshare.net/cwilper/mptstore-a-fast-scalable-and-stable-resource-index

If you would like any additional information, I would be happy to answer 
your questions on or off this list

  -Aaron

Re: Beginner's question - dealing with resourcesin a tree structure

Hi Peter,

This type of structure will definitely fit inside Fedora, using the
relationship index to store connections between objects. The best place
to get started is Richard Green's "Dummies Guide to Fedora" at
http://www.hull.ac.uk/esig/repomman/downloads/D-D4-iterative-dev-v01.pdf
Richard's RepoMMan project has implemented something very similar to
what you describe, though I'm not certain how they are currently storing
relationships.

You may also be interested in our collection content model, which could
easily be adapted for directories:
http://wiki.dlib.indiana.edu/confluence/display/INF/Collection+Content+M
odel

---- Ryan Scherle
---- Digital Library Program
---- Indiana University

> -----Original Message-----
> From: fedora-commons-users-bounces@...
> [mailto:fedora-commons-users-bounces@...] On Behalf
> Of Peter
> Sent: Thursday, May 31, 2007 7:39 AM
> To: fedora-commons-users@...
> Subject: [Fedora-commons-users] Beginner's question - dealing with
> resourcesin a tree structure
> 
> Gentlepeople,
> 
> I am looking into Fedora to store digital assets that are typically
> organized in a tree structure (a classic directory structure if you
> want).
> 
> Would that fit into the Fedora object model - a directory would be a
> Fedora
> object containing a collection of other Fedora objects some of which
> are
> directories and some of which have another type.
> 
> Would that work and allow for the typical directory/asset operations
> like
> e.g. enumerate all objects contained in this directory, add/remove an
> object
> from its directory, etc. Or would you suggest storing the structure
> outside
> Fedora?
> 
> Thanks,
> 
> Peter
> 
> 
>
-----------------------------------------------------------------------
> --
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Fedora-commons-users mailing list
> Fedora-commons-users@...
> https://lists.sourceforge.net/lists/listinfo/fedora-commons-users

generating global repository reports

Hi, everyone,

I'm wondering what the best method of doing reporting on general
repository stuff like the total number of objects ingested, or the
total number of children objects from a given object. It would seem
issuing iTQL queries would be the best choice, since there's an
aggregate count() function I can use to avoid actually transferring
unnecessary data, but it seems that iTQL might go the way of the dodo
when Fedora switches away from Kowari.

Should I just use iTQL in the meantime, and expect to transition to
something else in a later version of Fedora, or is there a better way?

Along those lines, I have another question. I wrote the following
simple iTQL query to get a global object count:

select count(select $object from <#ri> where $object <rdf:type>
<fedora-model:FedoraObject>)from <#ri> where $s $p $o

Oddly, this query returns a float (at least, it has .0 at the end),
and it's one higher than running "select count(*) from dobj" in the
relational store. Am I doing anything wrong?

Thanks for whatever guidance anyone can provide,

Michael Della Bitta

rdf ontologies for internal object metadata

Hi,

Are there any rdf ontologies in use for describing how the datastreams
in a fedora digital object relate to the object?

or should i create my own custom one?

there is a 'rels-int' section in the fedora foxml reference example,
for 'inner object relationship metadata' (as opposed to the rels-ext
sectionf for object to object relationship metadata).
Is there any update on how this might be used natively?

Do these issues tie in at all to the cmda being discussed right now?

--

-- 
cheers,
ben

Re: generating global repository reports