W3C home > Mailing lists > Public > semantic-web@w3.org > October 2007

Re: representing null in semantic frameworks

From: Story Henry <henry.story@bblfish.net>
Date: Mon, 22 Oct 2007 13:01:18 +0200
Message-Id: <7EB8419E-FED6-4DFA-A3E6-75A064E74BBA@bblfish.net>
Cc: Alan Ruttenberg <alanruttenberg@gmail.com>, Garret Wilson <garret@globalmentor.com>, Semantic Web <semantic-web@w3.org>
To: Carroll Jeremy <jjc@hpl.hp.com>, users@sommer.dev.java.net
Since we are mentioning closed world programming languages in a  
semantic web context, I thought the following may be of interest.

In so(m)mer [1] I have been thinking that a null return value for a  
semantically mapped object should mean that there is no value for  
that relation.

So if I define a simple Person class like this:

class Person {
	@rdf(foaf+"name") String name;
	@rdf(foaf+"mbox") Collection<URI> mboxes;
         @functional @rdf(foaf+"member",inverse=true)  
Collection<Person> memberOf;

and I then call extract a Person from a graph with code something  
similar to this:

Mapper map = MapperManager.getMapperForGraph("http://joe.eg/foaf");
Collection<Person> people = map.getAllObjectsOfType(Person.class);
Person p1 = people.iterator().next();

Then if the person has no name defined in the graph I would expect:


On the other hand since mboxes is a virtual collection - it is a way  
of collecting foaf:mbox relationships, since java does not allow  
multiple fields with the same name - it should return an empty  
collection, and so we should have


without a null pointer exception being thrown. [2]

Finally the memberOf relation relates a Person to a collection. (This  
is not really how foaf:member is defined, since a person can be  
memberOf many groups, but let us assume this is not the case for the  
purpose of this example...)
Here again I would expect [3]:


if the person is not member of any group. The null should be saying:  
there is no relation foaf:member from the collection to the person.

Does this seem like a resonable way to map rdf to java?


[1] https://sommer.dev.java.net
[2] I am not sure if so(m)mer really does this yet. But if people  
here think it is the right thing, I'll make sure it does.
[3] as in [2] I have not yet set up unit tests for this.

Home page: http://bblfish.net/
Sun Blog: http://blogs.sun.com/bblfish/
Foaf name: http://bblfish.net/people/henry/card#me

On 22 Oct 2007, at 12:33, Jeremy Carroll wrote:

> I think Frank's comments are very pertinent, and I will add just a  
> little.
> In a programming framework, or a relational db, quite what a null  
> means varies by context.
> If you like the name 'null', the Semantic Web framework allows you  
> to make this variation explicit, by defining a different 'null', in  
> the appropriate namespace, for each ontology. So that in your  
> cricket match ontology cricket:null might be defined as rain  
> stopped play (although really, particular in England, that result  
> is so important that it shouldn't be swept under the carpet with a  
> 'null'), whereas in a names and addresses ontology name:null might  
> be defined as 'no data available' (although that is only useful in  
> applications making closed world assumptions).
> One of my colleagues has an in principle objection to using null as  
> a legal value while programming, and prefers to have explicit  
> objects that represent the various BadValues that are expected.  
> While I am often too lazy to follow this design while programming,  
> I think there is a clarity of thinking involved, which seems the  
> essence of good design, and good modelling.
> In summary - rather than represent null - think more clearly - and  
> represent the results of clear thought. Using null is an  
> alternative to thinking clearly. I guess I see it as legitimate to  
> choose not to think, and so a null which is defined as approx. 'I  
> stopped thinking here' is clear, and it will be no great surprise  
> when such a null appears rather frequently in the defect tracker!
> Jeremy

Received on Monday, 22 October 2007 11:16:31 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 08:45:03 UTC