W3C home > Mailing lists > Public > www-rdf-interest@w3.org > August 2000

RE: Java API

From: McBride, Brian <bwm@hplb.hpl.hp.com>
Date: Mon, 7 Aug 2000 18:24:35 +0100
Message-ID: <5E13A1874524D411A876006008CD059F239342@0-mail-1.hpl.hp.com>
To: "'Jan Grant'" <Jan.Grant@bristol.ac.uk>
Cc: "RDF Interest (E-mail)" <www-rdf-interest@w3.org>
Hi Jan,

> The ability to store class definitions (for example) in an 
> RDF model is
> appealing.

Could you say a little more about what you have in mind here?

I did consider having a mapping from RDF types to Java classes
that implement those types so that whenever a resource 'got'
an object of the correct Java class would be instantiated.

I haven't done that because I don't think the RDF and Java
type models are sufficiently similar, e.g. if a resource has
two types, which one do I instantiate.

Right now I'm letting the programmer decide by passing in a
factory class.

Were you thinking of something similar, or do you have another

> The only thing I'm really unclear on thus far is this:
>      Resource ora = model.createResource()
>                          .addProperty(Dc.name, "Ora Lassila");
>      model2.add(ora, Dc.creator, model2.createLiteral("Mr. 
> Lassila, Snr.");
>      model2.add(ora, Dc.creator, model2.createLiteral("Mrs. Lassila");
>      ora.addProperty(anotherProptery, anotherValue);
> Which model is changed by the last call? Does ora have a default
> model? Or does it carry an identity with respect to each 
> model it comes
> into contact with?

What you get back from model.createResource and model.getResource is
actually an instance of ResourceInstance which contains a pointer to
the model that was used to create it.  If you do any model manipulation
through calls to that resource, then it is the model which was used
to create it which is modified.

So the last call in your example will modify model, not model2.

I agree this is not very clear; I wonder if there is a way to make it
clearer, other than just documenting the behaviour.

Thanks for the feedback.

Received on Monday, 7 August 2000 13:24:54 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:44:24 UTC