RDF to SQL at GovTrack

Hi all, Follow those who are taking the web on to the next level of
information sharing with the RDF to SQL discussion, see the message appended
below, that Joshua and Dave are having with the others in the GovTrack
discussion group,  You may subscribe to that discussion at
http://groups.yahoo.com/group/govtrack

For those of you who would like to make sense RDF, RSS, XML and all that  is
in play as the web is taken to the next level of information sharing read
Making a Semantic Web at http://www.netcrucible.com/semantic.html

For those who need some help with the definitions of RDF, RSS and XML I have
appended the three definitions from the article at the end of this message.
Here is a summary of the discussion at GovTrack discussion group that is
just getting underway.  John, John DeBruyn, Denver CO USA


-----Original Message-----
From: Joshua Tauberer [mailto:tauberer-a/[email protected]]
Sent: Saturday, March 12, 2005 9:55 AM
To: [email protected]
Subject: [govtrack] RDF to SQL



This is mainly a follow-up to something Chris from DIA (he's on the mail
list now) and I were talking about Monday, but I think the list at large
would be interested in seeing this.

When I met with Chris on Monday, he raised an important point that
whatever system is used to share data, it should be really easy to use,
in part to encourage people to use it.

Sharing data as raw databases makes it really easy to drop the data into
a website, he suggested.  And, I totally admit that it's much easier
than dealing with RDF.

But, as I responded Monday, once data is in RDF, it's easy to export it
into a database.  Two weeks ago I had been working on an RDF querying
engine (for fun, really, since there are already existing programs to do
this), and this week I added to it an SQL output format.  The result is
the ability to query an RDF data model and output it, more or less, as a
database.

First some background...

GovTrack publishes an RDF version of all of its data in
http://www.govtrack.us/data/rdf/.  You should take a look at the
people.rdf file if you haven't seen it get to get a general idea for the
structure of the data.

You can browse the data at http://www.govtrack.us/rdfbrowse.xpd.  The
browser program itself knows nothing about the type of data that it's
browsing, which is a good example of the advantage of using RDF.  All of
the different types of information magically just come together, with no
glue specific to each type of data.  (The browser uses the RDF schemas
in http://www.govtrack.us/share/ and some labels present in the RDF
files above to display nice names in place of some URIs.)

RDF can be written in XML or Notation 3, among other formats.  There are
N3 versions of the schemas in the share directory if you want to see
what they look like.  N3 is a much simpler format than RDF/XML.  It's
basically just a list of statements: subject predicate object, followed
by a period.

For the query engine that I wrote, the query itself is written as RDF
(in this case as N3).  You give it an RDF graph with some nodes marked
as variables, and the engine tells you the different ways it can match
up (bind) those variables with entities in the target data model.

Ok, the example...

At http://www.govtrack.us/rdfquery.cgi you can try it out.  Although,
admitedly it's difficult coming up with valid queries because the
structure of the data isn't all that simple.

The example queries the data model for all representatives currently
serving in an office.  (Since the data model is pretty rich, it's also
possible to write queries to list the population of each state for any
senator that voted Nay on legislation related to Copyright, for instance.)

Anyway, the idea is that once the data is in RDF, we could come up with
some queries to generate database versions of the information, and then
also publish those.

--
- Joshua Tauberer

http://taubz.for.net

** Nothing Unreal Exists **

Definitions of RSS, RDF and XML definitions from Making a Semantic Web,
circa 2001 (the URL is at the top of this message) follow:

RSS Rich Site Summary (the name for RSS 0.91, which is the most widely-used
version of RSS currently) is another XML-based node-labeled hierarchical
format, similar to OPML, but it uses tag names to represent various
metadata. The metadata that are permitted to be used are laid out in the
specifications, also in the Really Simple Syndication (RSS 0.92)
specification. The metadata defined by these specifications are fairly
general, but nevertheless define a vocabulary that needs to be used by
interoperable implementations. It's a step more restrictive that OPML, but
the act of defining some common metadata allows tools to count on the
meanings of those metadata and build services. The metadata defined by RSS
are meant to be meaningful primarily to syndication and aggregation tools.

RDF (and RSS 1.0)Resource Description Framework is the W3C recommended way
to store generic metadata. RDF is an XML format that allows metadata about
pretty much anything to be expressed. RDF also is designed in such a way
that metadata can always apply to a URI instead of to the parent item in the
XML structure, so it allows one-to-many and many-to-one relationships to be
expressed. This allows metadata to be stored in a non-hierarchical manner
and allows edge-labeled graphs to be represented. Since RDF attempts to be a
generic format for all metadata (and metadata about metadata, ad nauseum),
it is extensible by design. In other words, you can store RDF metadata about
resources described in a different piece of RDF metadata without worrying
about screwing up the format of the original metadata or breaking tools that
use it. Parallel to the RSS 0.92 work, RSS 1.0 was developed as RDF Site
Summary. RSS 1.0 uses RDF to describe basically the same things as the
original syntax, with a few additions. All of the RSS family of
specifications are designed for tools that do syndication and aggregation.
You can certainly put RDF and OPML/XML to other metadata uses besides just
syndication and aggregation.

XML is already a common syntax that many tools use, and XML documents do
include semantic information. For example, I may have a common "employee"
document format that I use, and you may use a different format, but the tag
names in the document provide some hints as to the content of the data. If
my format uses the tag name "StreetAddress" and yours uses "Address", we can
still interoperate. In fact, if there were a central repository (ignore for
now that this is a bad idea) that recorded the fact that "StreetAddress" in
my XML mapped to "Address" in yours, our import and export tools could
happily exchange employee data without requiring intervention on our part.
(Although this is similar to "inferencing" discussed earlier, inferencing is
normally used to describe those cases where we discover something that
wasn't explicitly recorded -- this example is more about "translation",
although inferencing is certainly possible with straight XML). XML documents
are hierarchical. This means that each element or piece of data can have
only one parent. So if your metadata uses the parent-child relationships of
the XML structure to represent meaningful data, you will be unable to
express meaningfully any sort of multiple-parent relationships. (People try
to get around this with id and idref tricks, but it is best to just think of
XML data as being a "tree", or in discrete mathematics terminology, "a
node-labeled graph").



[Non-text portions of this message have been removed]



-/-/-/-/-/

There is a read/write Web page with resources that will be linked there and used during the Seminar on PDFs for lawyers and legal applications:

http://Network-Lawyers.org/PDFLinks

-/-/-/-/-/


 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/Network-Lawyers/

<*> To unsubscribe from this group, send an email to:
    Network-Lawyers-unsubscribe-hHKSG33TihhbjbujkaE4pw@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/