There is now a fair amount of RDF/XML data around, thanks to various SeedApplications and other Semantic Web efforts.
How do programmers deal with this in code? What is it like to be an RDF coder? How do RDF toolkits compare to the machinery familiar to XML developers, such as SAX, DOM, XPath, XSLT...?
hmm... is this an API design discusion, aiming at convergence, or just a catalog, something for? need better PPR:OpeningStatement
See also: RDFAccessProtocol for network protocol ... er... network protocol something... ugh... naming cop-out..
What RDF APIs can I use?
- Jena from HP Labs Semantic Web Research
- redland API in C and perl, python, Tcl, Java, Ruby, PHP. The latter pages contain links to other language APIs in each of those languages.
- rdflib. XML.com: Building Metadata Applications with RDF [Feb. 12, 2003] is a nice intro.
- swap/cwm; see CwmTips, toIcal.py -- convert RDF to iCalendar syntax posted by DanC at 2003-04-18 15:18
- RAP - RDF API for PHP V0.6 - Home
- Sesame, Java APIs from Aduna
- YARS Home language-independent RESTful HTTP API and JDBC-like Java API
- mozilla, ... (LinkMe)
- see also: RDF API requirements and comparison, SWAD-Europe Deliverable by Jan Grant Started 2003-01-14; revised 2003-02-27.
What OWL APIs can I use?
- jena has OWL support, per Reynolds/HP 7 May
- OWL API (bechover/volz 7 May)
- Cerebra from network inference
- ... WebOnt WG OWL implementation report may list others over time.
Many RDF toolkits offer similar facilities. In-memory and persistent representations of RDF graphs (often but not always SQL-based in the latter case). Parsers for the RDF/XML syntax, often a serializer too. Often a graph-oriented API, sometimes with richer textual query interfaces.
This is an attempt (partial/incomplete) to list some common tasks that occur when building Semantic Web applications, so that we can walk through the way the different RDF tools address these needs.
When learning a new RDF package, we might ask ourselves:
"How do I...?"
- load a graph from a URI
- create a new SQL-backed RDF store
- stash some RDF there
- refresh a named portion of the DB with this graph
- serialize to RDF/XML
- get a graph that matches (some blanked out statement)
- do fancier queries
- create a... statement... graph... term...
One pattern is to make APIs computer language independent so that the same libraies can be shared by users of many languages. Another is to make the interface use as many nice features of the language as possible. When using RDF seriously, one tends to need access to the properties of things just as often and just as easily as access to the slots in an object. This suggests a value for a specialized language-specific interface. Also, one needs a neat way of using namespaces.
For example, in python, which is object-oriented and allows the object model to be bent in all kinds of ways, namespaces can be used as though they were dictionaries (rdf['type']) or objects (rdf.type) and objects in an RDF store can be represented by python objects.
To take this to a logical extreme, one makes a new language, a mixture of a declarative RDF langauge (like N3) and a procedural language (like python). Adenine is an example.