Re: Are current RDF tools ready for this use case?

Hi Mark --

You wrote...

In my mind, the ideal system would support:
 * The ability to store large numbers of triples, scalable to hundreds
of millions.
 * Would be clusterable for redundancy.
 * Could be accessed via HTTP for easy integration into a variety of
platforms.
 * Would be highly performant in regards to querying.

You may like to evaluate the Internet Business Logic system for this
purpose.

It supports the authoring and running of applications as business rules in
open vocabulary, executable English, using a browser.  It's live online at
the site below, and shared use is free.

Our current approach is to use the robustness and scalability of Oracle or
MySql to store triples and n-ary data.

>From the rules, the system automatically generates and runs SQL over
distributed databases.  The SQl is normally too complex to write reliably by
hand, but the system can explain the results, in English, at the business
level.

The following links may be useful for an evaluation.

 www.reengineeringllc.com/demo_agents/RDFQueryLangComparison1.agent

www.reengineeringllc.com/A_Wiki_for_Business_Rules_in_Open_Vocabulary_Executable_English.pdf


www.reengineeringllc.com/Oil_Industry_Supply_Chain_by_Kowalski_and_Walker.pdf

Apologies if you have seen this before, and thanks for comments.

                                                  -- Adrian

Internet Business Logic (R)
A Wiki for Executable Open Vocabulary English
Online at www.reengineeringllc.com    Shared use is free

Adrian Walker
Reengineering




On 6/27/07, Mark Kennedy <MKennedy@fool.com> wrote:
>
>
> Hello, all:
>
> I'm hoping to get some feedback for the appropriateness of using RDF as
> a solution to a challenge that I'm facing. Here's the scenario:
>
> I have an environment that includes several disparate sets of content,
> all maintained and stored by separate systems. For example, we have a
> CMS for our editorial content, a third party blogging tool, a message
> board application, a third party video management system, and perhaps a
> third party wiki application. Each of those systems has their own schema
> and storage for metadata about the content they manage. In the future,
> new systems and content types will be added to our environment as
> needed.
>
> Our vision is to build a common metadata store that each separate system
> would feed into. This common store would enable us to add new metadata
> to content and rectify the metadata from each system into a common
> schema, e.g. allow us to map the author information from each separate
> system onto a common set of authors, map separate categorization schemes
> to a common taxonomy, etc.
>
> Our goal is to be able to query the common metadata store to do things
> like find all of the content created by a single author regardless of
> the system, or find all content related to a particular topic, or some
> similar combination of query criteria.
>
> Based on our requirements, RDF seems like an ideal solution. What I'm
> unsure about, however, is if there are any RDF tools/frameworks/stores
> that are robust enough to handle a high level of concurrent querying
> that would result from a high traffic, publicly available web site.
>
> I'm just starting the process of researching tools and triple stores
> now, but I guess I'm looking for a gut check on the readiness or
> appropriateness of RDF to serve the needs I describe. Are RDF and the
> current tools that enable/support it ready for prime-time consideration?
> If so, which ones make the most sense to research first?
>
> In my mind, the ideal system would support:
> * The ability to store large numbers of triples, scalable to hundreds
> of millions.
> * Would be clusterable for redundancy.
> * Could be accessed via HTTP for easy integration into a variety of
> platforms.
> * Would be highly performant in regards to querying.
>
> Any feedback would be appreciated. And if you think this query might
> make more sense in another forum, please let me know.
>
> Thanks!
>
> Mark Kennedy
> mkennedy@fool.com
>
>
>
>
>