Hi Andy, I understand from your email below that the issues I mentioned in my email have been fixed. Can you please tell me the procedure to access and integrate these fixes smootly to my code? Do I have to upgrade to a more recent version of Jena? For instance in Eclipse, I'm getting the error "The method createLiteral(String, XSDDatatype) is undefined for the type NodeFactory" when trying to run the piece of code uploaded at * https://issues.apache.org/jira/browse/JENA-414*. I'm using Jena 2.6....
Thanks Leo 213/3/19 Andy Seaborne <[email protected]> > JIRA:: > > https://issues.apache.org/**jira/browse/JENA-413<https://issues.apache.org/jira/browse/JENA-413>fixes > the 0 duration issue (fixed, closed) > > https://issues.apache.org/**jira/browse/JENA-414<https://issues.apache.org/jira/browse/JENA-414>records > the formating of non-zero second durations (fixed, closed) > > https://issues.apache.org/**jira/browse/JENA-415<https://issues.apache.org/jira/browse/JENA-415>is > a feature request for xsd:dayTimeDuration and xsd:yearMonthDuration in > Jena datatypes. > > (Awaiting contribution) > > ARQ supports both xsd:dayTimeDuration and xsd:yearMonthDuration. > > > On 19/03/13 00:54, Léonard PETNGA wrote: > >> Hi everyone, >> Thank you for your valuable insight. I understand there is an agreement >> here on avoiding the use of the Constructor as recommended in Jena >> Javadoc. >> Thus, I've tested the use of Literal as many of you suggested but it >> doesn't solve the problem as you can observe on my code below which shows >> numerous inconsistencies in the outputs. You can test it by yourself..... >> > > It is helpful if you include complete code, including the bit that prints > input and output. If a complete, minimal example can be cut-and-pasted to > run and get the behaviour, it avoids the risk of the reconstructed setup > being wrong. > > > public static XSDDuration parseStringToISODuration(**String duration) >> throwsIllegalArgumentException { >> >> Model model = ModelFactory.**createDefaultModel(); >> >> Literal l = model.createTypedLiteral(**duration, XSDDatatype. >> XSDduration ); >> >> XSDDuration durationXSD = (XSDDuration) l.getValue(); >> >> return durationXSD; >> >> } >> >> Input String Output XSDDuration >> >> "PT0H0M0S" ----> P >> "PT26S" ----> PT >> "PT0S" ----> P >> "PT5.034S" ----> P5.034S //only correct result! >> "PT5.00S" ----> PT >> "PT0.000S" ----> P >> >> Is the getValue() method not doing its job properly or am I missing >> something here? >> Thank you again, >> Leo >> >> >> >> 2013/3/18 Jeremy J Carroll <[email protected]> >> >> >>> >>> There are specific problems with xsd:duration, see >>> >>> http://www.w3.org/TR/2004/REC-**rdf-mt-20040210/#dtype_interp<http://www.w3.org/TR/2004/REC-rdf-mt-20040210/#dtype_interp> >>> >>> "xsd:duration does not have a well-defined value space" >>> >>> This is fixed and you should use either >>> >>> http://www.w3.org/TR/**xmlschema11-2/#**yearMonthDuration<http://www.w3.org/TR/xmlschema11-2/#yearMonthDuration> >>> >>> or >>> >>> http://www.w3.org/TR/**xmlschema11-2/#dayTimeDuration<http://www.w3.org/TR/xmlschema11-2/#dayTimeDuration> >>> >>> I am unclear as to how this interacts with Jena support for duration, or >>> your question - sorry. >>> >>> As regards to your question, the error message that "P" is not a valid >>> duration is correct, "P0D" for example, seems to be valid representation >>> of >>> the zero length duration, which is the canonical one for >>> dayTimeDuration. I >>> can't quite follow where the "P" is produced in your code, but still, >>> wherever it is, patching it to be "P0D" will fix things. >>> >>> >>> Jeremy >>> >>> >>> >>> On Mar 18, 2013, at 1:54 PM, Léonard PETNGA <[email protected]> wrote: >>> >>> Hi Jena Community, >>>> I'm new to Jena and I would need your help fixing some issues with my >>>> >>> code. >>> >>>> I'm trying to parse a String in duration format ie "*PnYn MnDTnH >>>> >>> nMn**S*" into >>> >>>> an *XSDDuration* datatype that I'll bind to a Node of my inferred graph >>>> >>> (in >>> >>>> a custom built-in function). To that aim, my parser extracts and stores >>>> integer values for Year, Month, etc... in an array int[9] of *value, >>>> >>> *that >>> >>>> is latter passed to the XML duration constructor. This works fine >>>> >>> ...except >>> >>>> for when the duration is 0 (see the error below). >>>> >>>> public static int[] parseStringToISODurationInt(**String duration) >>>> throwsIllegalArgumentException { >>>> >>>> int[] value = new int[9]; >>>> >>>> StringTokenizer st = new StringTokenizer(duration); >>>> >>>> String nullDur = "PT0H0M0S"; // from a previous converter >>>> >>> function >>> >>>> >>>> if (duration == nullDur){ >>>> >>>> value[0] = 0; >>>> >>>> value[1] = 0; >>>> >>>> value[2] = 0; >>>> >>>> value[3] = 0; >>>> >>>> value[4] = 0; >>>> >>>> value[5] = 0; >>>> >>>> value[6] = 0; // [7] is the Z character(zulu timezone, not >>>> needed >>>> here), >>>> >>>> value[8] = 3; // 'mscale' value >>>> >>>> } else { >>>> >>>> // ....rest of the code >>>> >>>> } >>>> >>>> return value; >>>> >>>> } >>>> >>>> In my built-in I pass the array obtained to the *XSDDuration(Object >>>> value)*constructor and make the new node that is binded to the graph >>>> as follows : >>>> >>>> Node duration = null; >>>> >>>> duration = Node.createLiteral( >>>> LiteralLabelFactory.create(**newXSDDuration(value)) ); >>>> The following excerpt shows the error when running my built-in for a >>>> zero >>>> duration (value[i]=0 forall i =0,..6 and value[8]=3 ). >>>> >>>> Exception in thread "main" >>>> com.hp.hpl.jena.datatypes.**DatatypeFormatException: Lexical form 'P' >>>> is >>>> >>> not >>> >>>> a legal instance of Datatype[http://www.w3.org/** >>>> 2001/XMLSchema#duration- <http://www.w3.org/2001/XMLSchema#duration->> >>>> class com.hp.hpl.jena.datatypes.xsd.**XSDDuration] null >>>> [java] at >>>> >>>> com.hp.hpl.jena.graph.impl.**LiteralLabelImpl.getValue(** >>> LiteralLabelImpl.java:300) >>> >>>> >>>> So what what is the legal lexical form for a "zero" duration? How do I >>>> construct that using the *XSDDuration* constructor? >>>> Any other solution will be welcomed... >>>> >>>> Many thanks in advance for your prompt reaction. >>>> >>>> Leo >>>> >>> >>> >>> >> >
