Search Mailing List Archives


Limit search to: Subject & Body Subject Author
Sort by: Reverse Sort
Limit to: All This Week Last Week This Month Last Month
Select Date Range     through    

[protege-owl] Problem with DIG rendering of boolean-valued properties

Thomas Russ tar at ISI.EDU
Mon Aug 27 11:39:28 PDT 2007


We've run into a problem with the DIG rendering of boolean-valued  
DatatypeProperties that is breaking connections to Pellet.

The problem is that the DIG renderer in Protege claims to support  
boolean-valued datatypes (as integers), but that when asserted values  
of "true" or "false" are rendered, they are rendered literally.  And  
the integer parser in Pellet rejects them as integers.

It seems that there are two reasonable solutions to this problem.

(1)  Remove boolean from the set of supported datatypes in the DIG  
renderer.

(2)  Translate the boolean "true" value to "1" and "false" => "0".

I think either of these would work and be fairly easy to implement.   
The design decision involves deciding which route would be the better  
approach.  (1) is more strictly correct, whereas (2) would IMHO be a  
more useful transformation for reasoning.

For (1) what would be needed is to remove the line
     map.put(owlModel.getXSDboolean(), new IntDataTypeMapEntry());
in the file DIGDataTypes.java at about line 62.

For (2) additional code would need to be added to the method
     IntDataTypeMapEntry.getRendering
in the File DIGDataTypes.java at about line 229, to handle the
transformation of the values.  One possible implementation would
be
     	public String getRenderering(RDFSLiteral value) {
                 String rendering = value.getString();
                 if (rendering.equals("true")) {
                     return "1";
                 } else if (rendering.equals("false")) {
	            return "0";
                 } else {
		    return rendering
		}
	}

   What I'm not sure of is whether there needs to be a reverse  
translation from {1,0} to {true,false} to return inferred values back  
into Protege.  Unfortunately, I wasn't able to find a place where  
this may be occurring.  The IntegerResultReasoningTask interface  
didn't have an implementing class that I could find.





More information about the protege-owl mailing list