When I import this data:
http://pkupiekb.org/resource/田边凉 http://pkupiekb.org/ontology/生日 “12-20”^^http://www.w3.org/2001/XMLSchema#gMonthDay .
An error happened, ‘12-20’ is not a valid value for datatype http://www.w3.org/2001/XMLSchema#gMonthDay
How can I fix it? My Stardog version is 5.0.3
Thanks for answer!
When I import this data:
Hi, you have two options:
- Fix the data such that the values it is using are valid for the datatypes
- Start the Stardog server with
strict.parsing=falsein your stardog.properties to ignore such errors
Quick follow up. The format for gMonthDay is “–MM-DD” so you’re missing two dashes at the front.
Hi, stephen, your suggestion helps me a lot, thank you very much!
Another question I want to know is that whether stardog can skip the line which contain an error and then go on import the following line?
Thank you for your warm heart!
Suppose you loaded some messy data using strict.parsing=true, what would be the best way to identify the literals that required you to set strict.parsing=true?
There is currently no way to do this. You will either need to load in the bad data with
strict.parsing=false or fix the issues as they come up until you have good data.
The stardog.log will contain error messages that spell out which values are invalid for their datatypes.
Not yet but there soon will be. I’ll put together a user defined function that calls XMLDatatypeUtil.isValidValue(). It would only check XSD types but it’s a start. I have to admit I find datatype handling is still a bit mysterious past the basics. If anyone is interested in it please just let me know and I’ll be more motivated to get it out more quickly or if anyone has any suggestions that would be more helpful in cleaning up messy data.
Here it is. I hope someone finds it useful. I know my OCD kicks in when I’ve got dirty data and it would probably nag me from the second I set strict.parsing=true until I fixed it. I haven’t had a chance to test it at all but pull requests are always welcome and interest is motivating.
On a side note about creating plugins. I’ve struggled a bit with how I’d like to package them. It’s and all or nothing proposition when loading a jar so ideally I’d like package a single function per jar so that people can choose a-la-cart what to make available. On the other hand that’s a bit of a pain and the extensions directory is going to get really cluttered really quickly. It might be nice to support recursing the STARDOG_EXT directory so they can be put into separate directories. I was also thinking it might be nice to include a stardog.ttl file in the META-INF directory including some documentation on the function and then writing a bites extractor for loading that info when adding the jar to a stardog doc store. You could create a db called stardog-ext and then point STARDOG_EXT to the document directory and voila you’ve got some extension tracking. It would also be nice to include some signatures so you can be sure they are secure.
It’s probably way too complicated for something that’s currently easy but I thought I’d throw it out there.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.