 |
 |
Jeff (and Hugh): Thanks for the clarification. > The broader issue of comparing a relational database to a triple store has > to do with limitations of RDBs that are not present when using triples. By > nature RBS are rigidly defined with set tables and properties. In RDF there > are no real restrictions. Assuming you understand the model for the data in > the graph, you can consume more data without crosswalking or converting it > and then query against the data based on the model that it uses. > > I can see how the lack of a fixed relationship scheme would be useful. I am considering using a triple store for a project where we are annotating data and we might want to expand the types of annotations we make over time (e.g., semantic tags, machine learning results). And where the particular way we refer to the data that is being annotated might depend on the type of annotation (e.g. a data set ID, an image region). The other major difference is that nodes in Graph data almost always (or at > least should) have a persistent identifier. So 'Jane Austen', 'Austen, > Jane', and '奥斯丁, 1775-1817' would all have the same identifier and > consequently a query could be made using just that one identifier to find > related entities. This is possible in a relational database but it would > require a very well constructed table system and a extremely high level a > maintenance and quality checking in order to keep it up to date. I'm not sure the uniqueness of the persistent identifier is a big selling point (to me) of a triple store. It's possible to do what you are saying in a relational database, but it would be really bad design not to have a primary key for your author table. It seems like the strong selling point is to use the same set of persistent identifiers as someone else, so that you are speaking the same language. Otherwise your unique ID for Jane Austen is just as good as my unique ID in my relational authors table. One of my concerns, apart from making the business case for triple stores to an organization that is heavily invested in relational DB technology, is that when I've experimented with importing RDF data that has come out of a triple store into a relational DB, I have had issues with things like relations pointing to persistent identifiers that don't exist in the current namespace (perhaps this is a feature, not a bug?) and loops in relationship graphs that shouldn't have loops. Relational DBs aren't any good at finding loops, but you'd think a graph DB would be set up to detect that kind of thing. This makes me wonder if the technology is really all that mature. -Sarah > > > ________________________________________ > From: Code for Libraries <[log in to unmask]> on behalf of Sarah > Weissman <[log in to unmask]> > Sent: Friday, December 19, 2014 2:05 PM > To: [log in to unmask] > Subject: Re: [CODE4LIB] rdf triplestores > > Jeff, > > > > With graph data it is much easier to search for an author (lets say Jane > > Austen) and find not only all of the books that she authored but also all > > of the books about her, all of the books that are about similar topics, > > published in similar periods. One can then imaging hopping from the Jane > > Austen node on the graph to a node that is a book she wrote (say Pride > and > > Prejudice) and then to a subject node for the book (say "Social > > Classes--Fiction). From there you could then find all of the Authors that > > wrote books about that same topic and then navigate to those books. > > > > > When you say that it would be "easier" to discover these other relations > from the Jane Austen node, do you mean that you can query for relations in > a triplestore/graph DB more readily (efficiently?) than you can in a RDB? > It seems like the equivalent in the RDB model would be, given a piece of > data used in a FK column in a table, to query for (if you even could) what > other tables use the same FK, then query these tables, constraining to the > Jane Austen value to see whether or not they had any data, which is not a > "natural" way of using a RDB. > > -Sarah > > > On Fri, Dec 19, 2014 at 11:10 AM, Mixter,Jeff <[log in to unmask]> wrote: > > > Stuart, > > > > Since triplestores, in essence, store graph data I think a slightly > better > > question is what can you do with graph data (if you do not mind me > > rephrasing you question). > > > > From this perspective I would point to Facebook or LinkedIn as prime > > examples of what can be done with graph data. Obviously those do not > > necessarily translate well into what can be done with library graph data > > but it does show the potential. For libraries, I think one of the > benefits > > will be expanded/enhanced discoverability for resources. > > > > With graph data it is much easier to search for an author (lets say Jane > > Austen) and find not only all of the books that she authored but also all > > of the books about her, all of the books that are about similar topics, > > published in similar periods. One can then imaging hopping from the Jane > > Austen node on the graph to a node that is a book she wrote (say Pride > and > > Prejudice) and then to a subject node for the book (say "Social > > Classes--Fiction). From there you could then find all of the Authors that > > wrote books about that same topic and then navigate to those books. > > > > Our current ILS systems try t o do this with MARC records but because > they > > are mostly string based, it is very difficult to accurately provide this > > type of information to users. Graph data helps overcome this hurdle. > > > > This was a rather basic example of how end-users can benefit from graph > > data but I think it is a compelling reason. > > > > I have attached a simple image to help visualize what I was talking > about. > > In it the user would start by finding Author1 and then using the graph we > > (the library) could suggest that they might like Book2 (since it is about > > the same subject) or even Book3 (since it is by Author2 who wrote a book, > > Book2, that shared a common subject, Subject1, with the author, Author1, > > that was originally searched for. Again, this is very basic but would be > > rather difficult to do with a string base record system. > > > > If you wanted to add complexity, you could start talking about discover > of > > multi-lingual items for bilingual users (since graph data should be > > language neutral). > > > > Thanks, > > > > Jeff Mixter > > Research Support Specialist > > OCLC Research > > 614-761-5159 > > [log in to unmask] > > > > ________________________________________ > > From: Code for Libraries <[log in to unmask]> on behalf of > Forrest, > > Stuart <[log in to unmask]> > > Sent: Friday, December 19, 2014 10:32 AM > > To: [log in to unmask] > > Subject: Re: [CODE4LIB] rdf triplestores > > > > Thanks Jeff > > > > Interesting concept, can you give me any examples of their usage, what > > kinds of data etc.? > > > > Thanks > > > > > > > ================================================================================ > > Stuart Forrest PhD > > Library Systems Specialist > > Beaufort County Library > > 843 255 6450 > > [log in to unmask] > > > > http://www.beaufortcountylibrary.org > > > > For Leisure, For Learning, For Life > > > > > > > > > > -----Original Message----- > > From: Code for Libraries [mailto:[log in to unmask]] On Behalf Of > > Mixter,Jeff > > Sent: Friday, December 19, 2014 10:20 AM > > To: [log in to unmask] > > Subject: Re: [CODE4LIB] rdf triplestores > > > > A triplestore is basically a database backend for RDF triples. The major > > benefit is that it allows for SPARQL querying. You could imagine a > > triplestore as being the same thing as a relational database that can be > > queried with SQL. > > > > The drawback that I have run into is that unless you have unlimited > > hardware, triplestores can run into scaling problems (when you are > looking > > at hundreds of millions or billions of triples). This is a problem when > you > > want to search for data. For searching I use a hybrid Elasticsearch (i.e. > > Lucene) index for the string literals and the go out to the triplestore > to > > query for the data. > > > > If you are looking to use a triplestore it is important to distinguish > > between search and query. > > > > Triplestore are really good for query but not so good for search. The > > basic problem with search is that is it mostly string based and this > > requires a regular expression query in SPARQL which is expensive from a > > hardware perspective. > > > > There are a few triple stores that use a hybrid model. In particular Jena > > Fuseki (http://jena.apache.org/documentation/query/text-query.html) > > > > Thanks, > > > > Jeff Mixter > > Research Support Specialist > > OCLC Research > > 614-761-5159 > > [log in to unmask] > > > > ________________________________________ > > From: Code for Libraries <[log in to unmask]> on behalf of > Forrest, > > Stuart <[log in to unmask]> > > Sent: Friday, December 19, 2014 10:00 AM > > To: [log in to unmask] > > Subject: Re: [CODE4LIB] rdf triplestores > > > > Hi All > > > > My question is what do you guys use triplestores for? > > > > Thanks > > Stuart > > > > > > > > > ================================================================================ > > Stuart Forrest PhD > > Library Systems Specialist > > Beaufort County Library > > 843 255 6450 > > [log in to unmask] > > > > http://www.beaufortcountylibrary.org > > > > For Leisure, For Learning, For Life > > > > > > > > -----Original Message----- > > From: Code for Libraries [mailto:[log in to unmask]] On Behalf Of > > Stefano Bargioni > > Sent: Monday, November 11, 2013 8:53 AM > > To: [log in to unmask] > > Subject: Re: [CODE4LIB] rdf triplestores > > > > My +1 for Joseki. > > sb > > > > On 11/nov/2013, at 06.12, Eric Lease Morgan wrote: > > > > > What is your favorite RDF triplestore? > > > > > > I am able to convert numerous library-related metadata formats into > > RDF/XML. In a minimal way, I can then contribute to the Semantic Web by > > simply putting the resulting files on an HTTP file system. But if I were > to > > import my RDF/XML into a triplestore, then I could do a lot more. Jena > > seems like a good option. So does Openlink Virtuoso. > > > > > > What experience do y'all have with these tools, and do you know how to > > import RDF/XML into them? > > > > > > -- > > > Eric Lease Morgan > > > > > >