01: package org.ontoware.rdf2go.impl.jena24;
02:
03: import com.hp.hpl.jena.datatypes.BaseDatatype;
04: import com.hp.hpl.jena.graph.impl.LiteralLabel;
05:
06: public class GeneralDataType extends BaseDatatype {
07:
08: public GeneralDataType(String uri) {
09: super (uri);
10: }
11:
12: /**
13: * Equalness of DataTypes in Jena is implemented through the class
14: * com.hp.hpl.jena.datatypes.BaseDatatype#isEqual .
15: * In that implementation Datatypes are Compared on the Object Level.
16: * We dont know the reason for that design desicision, but in our case
17: * we need DataTypes to be equal if their URIs are equal.
18: *
19: * So we compare the URIs of both Data Types and the Values of both literals.
20: * @see com.hp.hpl.jena.datatypes.BaseDatatype#isEqual(com.hp.hpl.jena.graph.impl.LiteralLabel, com.hp.hpl.jena.graph.impl.LiteralLabel)
21: */
22: @Override
23: public boolean isEqual(LiteralLabel a, LiteralLabel b) {
24:
25: // because LiteralLabel.sameValueAs does not check data typed literals itself,
26: // but instead just calls RDFDatatype.isEqual for data typed literals
27: // we have the undesired effect of comparing data types on the object level
28:
29: // what we want for rdf2go is the following:
30: // datatyped literals l1,l2 are equal if and only if:
31: // the uri of the datatype of l1 and the uri of the datatype of l2 are equal
32: // and the value of both literals are equal
33: // We dont concern ourselves with the lexical representation of the
34: // data typed literal, which might be the cause for all this confusion ^_-
35:
36: // the new
37: return a.getDatatype().getURI()
38: .equals(b.getDatatype().getURI())
39: && a.getValue().equals(b.getValue());
40:
41: // the old
42: // return a.getDatatype().equals( b.getDatatype() )
43: // && a.getValue().equals(b.getValue());
44: }
45:
46: }
|