isomorphic graph with literal testing

[satra]

if not g_rdf.isomorphic(g0_rdf):
    in_both, in_first, in_second = graph_diff(g_rdf, g0_rdf)
    print("FIRST")
    dump_nt_sorted(in_first) 
    print("SECOND")
    dump_nt_sorted(in_second) 

returns

FIRST
<http://example.org/a2> <http://www.w3.org/2000/01/rdf-schema#label> "activity2" .
<http://example.org/a2> <http://www.w3.org/2000/01/rdf-schema#label> "hello" .
SECOND
<http://example.org/a2> <http://www.w3.org/2000/01/rdf-schema#label> 
            "activity2"^^<http://www.w3.org/2001/XMLSchema#string> .
<http://example.org/a2> <http://www.w3.org/2000/01/rdf-schema#label> 
            "hello"^^<http://www.w3.org/2001/XMLSchema#string> .

would there be a way to say that the string "activity2" is equivalent to "activity2"^^<http://www.w3.org/2001/XMLSchema#string>

[joernhees]

hmm, i'm inclined to agree with your reasoning, but this probably has tons of intricate effects on RDFlib.
Additionally people might rely on Literal("foo").dataype is None, so this is definitely nothing we can change in a patch release.

For consistency reasons, accepting #657 should then also enforce datatype == XSD['langstring'] for strings with a language...

I think the reason for this can be seen (as many weird things) in rdflib trying to find the "pythonic" way in between syntactic and semantic equivalence.

1. If you write Literal("foo").n3(), would you expect "foo" or "foo"^^xsd:string?
2. If you now parse "foo"^^xsd:string, and afterwards serialize it again, what would you expect?

[satra]

@joernhees - i wrote an extension to find_diff that helped me for my use case to isolate the differences that were actually affecting output. however, if you note the check that i'm doing is a literal check and that does return equivalence for things that don't return equivalent for a hash-based check.

https://github.com/satra/prov/blob/e480c62f2ed4dc1a4d1db4da8293afad163ba9e0/prov/tests/test_rdf.py#L22

this could be enabled through a flag or something.

i completely agree about the pythonic nature of things. this is exactly the issue noted here:

trungdong/prov#89

[cmaumet]

@joernhees, @satra: agreed accepting #657 would have side effects, let's close it.

+1 for @satra's suggestion above.

[gromgull]

this is sort of the same as #670