- From: McBride, Brian <bwm@hplb.hpl.hp.com>
- Date: Fri, 4 Aug 2000 17:34:28 +0100
- To: "RDF Interest (E-mail)" <www-rdf-interest@w3.org>
- Message-ID: <5E13A1874524D411A876006008CD059F1006CD@0-mail-1.hpl.hp.com>
I have been getting feedback about the current java RDF API from potential
RDF users in HPLabs. A number of issues with the current API are inhibiting
the adoption of RDF in this organisation. I have been exploring some ideas
for addressing these issues in the form of an evolution of the SiRPAC API.
I'd appreciate the comments of this group on the results.
I am in the process of building an implementation of these enhancements
which I intend to make freely available. I have got far enough with the
design that I am reasonably confident that it is implementable. I would
like to get early feedback before getting too far into the implementation.
In particular I'd welcome comments on:
* is the overall style appealing?
* preferences for strict evolution from the current SiRPAC API versus
conforming to current java stylistic conventions
* detailed comments on the interfaces
I'd like to stress that what I am proposing is an evolution of the excellent
work that has already been done on RDF API's. This evolution has been
motivated by a desire to address specific concerns raised by potential
users. I'd also like to acknowledge that I 'borrowed' the core idea from
Dave Beckett at ILRT.
The main changes are:
* whilst maintaining the current statement centric method calls, added
a set of resource centric method calls which are cascadable to make code
easier to read and write
* explicit container support
* typed data values in literals - supports built in types and user
defined objects
* property as an explicit type
* subclassing of resource to provide resource specific behaviour (used
by containers)
* explicit support for reification (... dare I mention this :)
* a style more consistent with current java api practice
Here are some brief code samples:
// create the structure in Figure 2 of m&s
Resource ora = model.createResource()
.addProperty(Dc.name, "Ora Lassila")
.addProperty(Dc.email, <mailto:lassila@w3.org>
lassila@w3.org);
Resource page = model.createResource( <http://www.w3.org/Home/Lassila>
http://www.w3.org/Home/Lassila)
.addProperty(Dc.creator, ora);
The alternative in the current API (as I have implemented it) might be:
Resource ora = model.createResource();
model.add(model.createStatement(ora, DC.name, "Ora Lassila"));
model.add(model.createStatement(ora, DC.email, lassila@w3.org
<mailto:lassila@w3.org> ));
Resource page = model.createResource();
model.add(model.createStatement(page, DC.creator, ora);
// create bag structure from figure 4 of m&s
Resource bag = model.createBag()
.addResource("/Students/Amy")
.addResource("/Students/Tim")
.addResource("/Students/John")
.addResource("/Students/Mary")
.addResource("/Students/Sue");
Resource course = model.createResource("/courses/6.001")
.addProperty(Myschema.students, bag);
Again the alternative:
Resource student = null;
Resource course = model.createResource("/courses/6.001");
Resource bag = model.createResource();
model.add(model.createStatement(bag, RDF.type, RDF.Bag));
model.add(model.createStatement(course, MYSCHEMA.students, bag));
student = model.createResource("/Students/Amy");
model.add(model.createStatement(bag, RDF.li(1), student));
student = model.createResource("/Students/Tim");
model.add(model.createStatement(bag, RDF.li(2), student));
student = model.createResource("/Students/John"));
model.add(model.createStatement(bag, RDF.li(3), student));
student = model.createResource("/Students/Mary");
model.add(model.createStatement(bag, RDF.li(4), student));
student = model.createResource("/Students/Sue");
model.add(model.createStatement(bag, RDF.li(5), student));
// access the i'th element of the bag starting from course
Resource student = course.getProperty(Myschema.students)
.getProperty(Rdf.li(i)).getResource();
Again the alternative
Model m = model.find(course, MYSCHEMA.students, null)
Statement s = (Statement) m.elements.next();
m = model.find(s.subject(), RDF.li(i), null);
s = (Statement) m.elements.next());
Resource student = (Resource) s.object();
// a reification from figure 8 of m&s
Resource page = model.createResource("http://www.w3.org/Home/Lassila")
Model.createStatement(page, Dc.creator, "Ora Lassila")
.addProperty(SomeSchema.attributedTo, "Ralph Swick");
// creating and accessing a compound value from figure 15 of m&s
john.addProperty(Nschema.weight, model.createResource()
.addProperty(Rdf.value, 200)
.addProperty(Nschema.units.
Nschema.Pounds));
int weight = john.getProperty(Nschema.weight)
.getProperty(Rdf.value).getInt();
// transactions (if supported) are also inline
Resource bag = model.begin()
.createBag()
.addResource("/Students/Amy")
.addResource("/Students/Tim")
.addResource("/Students/John")
.addResource("/Students/Mary")
.addResource("/Students/Sue")
.commit();
// there are two kinds of query operation - one group returns iterators on
the
// the current model, the other group, as with the original returns, a new
model.
// return an iterator over all bags in the model
ResIterator iter = model.listSubjectsWithPredicate(Rdf.type, Rdf.Bag);
// return all the creators in a model
ResIterator iter = model.listObjectsOfPredicate(Dc.creator);
That should be enough to give a flavour. The current (work in progress)
interface files are attached.
Brian McBride
HPLabs
Attachments
- application/octet-stream attachment: api2.zip
Received on Friday, 4 August 2000 12:34:46 UTC