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.....
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
>
> "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
>
> or
>
> 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->
> > 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
>
>
