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

Tania Tudorache tudorache at
Tue Aug 28 13:42:38 PDT 2007

Hi Thomas,

Thank you for the bug report and for the suggested fixes. I have 
implemented solution 2, which seemed to be the more useful approach.

We are not querying the property fillers from the reasoner, so I am not 
concerned right now with the inverse translation. We will address this 
if we are going to do the property filler query in future.


Thomas Russ wrote:
> 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 at about line 62.
> For (2) additional code would need to be added to the method
>      IntDataTypeMapEntry.getRendering
> in the File 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.
> _______________________________________________
> protege-owl mailing list
> protege-owl at
> Instructions for unsubscribing: 

More information about the protege-owl mailing list