Problem parsing URIs with periods in them

[Seymore]

For instance, I have problems parsing the following URI, which occurs as the object of an object property : thePrefix:A23_2_SomeClass_1.1_TP_object 

The error is : Error parsing File: C:\optIncubate\stardog-1.1\stardog-1.1\examples\

CLASS_B12136.5.ttl Illegal subject value: "1"^^<http://www.w3.org/2001/XMLSchema#integer> [line 46]

I've had a similar problem with simular URI, 

where the error was :

Error parsing File: C:\optIncubate\stardog-1.1\stardog-1.1\examples\CLASS_B16.5.ttl Illegal predicate value: ".1"^^<http://www.w3.org/2001/XMLSchema#decimal> [line 43]

The triple was: 

thePrefix:CLASS12136_5_group_1.1_CAL10050_TP a owl:Class

thePrefix is unremarkable, on the form : http://example.com/company/ontology/, and should not cause any trouble. 

According to what I've found, periods are allowed in URIs, but I might be mistaken. 

Anyways, I thought you should know. 

[Mike Grove]

The error message you are providing do not seem to indicate the periods in those URI's have anything to do with the parse error.

The following example parses just fine:

<http://example.com/company/ontology/A23_2_SomeClass_1.1_TP_object> <http://example.com/company/ontology/A.B.C.D.E.F.G> <http://example.com/company/ontology/CLASS12136_5_group_1.1_CAL10050_TP>.

If you would like to provide the code sample and data, I can take a more in-depth look.

Generally, we use the RIO parsers from the Sesame framework for all of our RDF parsing and they tend to be pretty robust, so the problem is probably elsewhere.

Cheers,

Mike

--
-- --
You received this message because you are subscribed to the C&P "Stardog" group.
To post to this group, send email to sta...@clarkparsia.com
To unsubscribe from this group, send email to
stardog+u...@clarkparsia.com
For more options, visit this group at
http://groups.google.com/a/clarkparsia.com/group/stardog?hl=en
 
 

[Rich Visotcky]

Seems like this has more to do with the literal values than anything, as both errors relate to the storage of a numeric value.  Could the canonicalization of literals be doing something unexpected here?

http://stardog.com/docs/java/snarl/com/clarkparsia/stardog/index/IndexOptions.html#CANONICAL_LITERALS

Also, while the literals look correct to me, I did notice something else about the parsing of RDF and issues with literals as noted in the Adding and Removing section in the docs:

http://stardog.com/docs/using/#add-remove

[Mike Grove]

On Wed, Dec 5, 2012 at 12:35 PM, Rich Visotcky <viso...@gmail.com> wrote:

Seems like this has more to do with the literal values than anything, as both errors relate to the storage of a numeric value.  Could the canonicalization of literals be doing something unexpected here?

http://stardog.com/docs/java/snarl/com/clarkparsia/stardog/index/IndexOptions.html#CANONICAL_LITERALS

 Not likely, this option only comes into play once parsing is complete and the data is in the database.

Also, while the literals look correct to me, I did notice something else about the parsing of RDF and issues with literals as noted in the Adding and Removing section in the docs:

http://stardog.com/docs/using/#add-remove

Yes, the strict parsing option could be the issue.  By default, if you say "1.5"^^xsd:int or "twelve point four"^^xsd:float, Stardog is going to complain.  While it's perfectly legal to have that in RDF, you can run into trouble later on, particularly when doing query evaluation with filters that would handle those literal values where you will hit the dark corners of the SPARQL spec.