search

raytheonbbn / parliament

Standards-compliant triple store for RDF, OWL, and SPARQL
BSD 3-Clause "New" or "Revised" License
59 stars 4 forks source link

Literals in N-Triples exports from ParliamentAdmin are malformed #14

Closed IanEmmons closed 5 years ago

sadakatsu commented 5 years ago

I do not see this happening. I used the following script to insert data into my default graph:

@prefix bbn: <http://www.bbn.com#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
bbn:e bbn:has "e" .
bbn:f bbn:has "f"@en .
bbn:g bbn:has "g"^^xsd:string .
bbn:h bbn:has "2.71828"^^xsd:double .

When I ran the export function, the dump contained the following statements:

<http://www.bbn.com#e> <http://www.bbn.com#has> "e" .
<http://www.bbn.com#f> <http://www.bbn.com#has> "f"@en .
<http://www.bbn.com#g> <http://www.bbn.com#has> "g" .
<http://www.bbn.com#h> <http://www.bbn.com#has> "2.71828"^^<http://www.w3.org/2001/XMLSchema#double> .

How can I duplicate this issue to fix it?

IanEmmons commented 5 years ago

I created the following test data turtle file, which is a slightly enhanced version of the data above:

@prefix bbn: <http://bbn.com/literal/formatting/test#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

bbn:entity01 a bbn:ThingyMcBobber ;
    bbn:hasValue
        "foo" ,
        "bar"^^xsd:string ,
        "baz"@en ,
        42 ,
        3.1415927 ,
        "2.71828"^^xsd:double .

I imported this into Parliament version 2.7.10 (which is the version in use in the environment where this bug was observed) and then exported it in N-Triples format twice. The first export used Parliament's Web interface (and therefore used Jena's RDF serialization code), and the second used the ParliamentAdmin command-line tool (and therefore the C++ serialization code built into Parliament). The first export was correct, and the second one showed the malformed literals.

I then performed the exact same import and two exports in the most current version of Parliament on the master branch. The two exports were identical and correct. Therefore I am closing this ticket as "no longer a bug".