If you are using Maven the current dev build version you will want for
your Jena dependency will be 2.10.1-SNAPSHOT

If you are using multiple Jena components you should use the latest
SNAPSHOT across all your Jena dependencies as otherwise you will run into
issues with conflicting versions of Jena modules on the class path.

Note - There may be a 24 hour or so delay between when a fix is committed
and when it is available in a development snapshot because snapshots are
only deployed on a nightly basis.  You can see when the last snapshot was
built and deployed and what changes it contained at
https://builds.apache.org/job/Jena__Development_Deploy/



Rob

On 3/19/13 3:59 PM, "Dave Reynolds" <[email protected]> wrote:

>Yes you need to update your copy of Jena.
>
>As it says on:
>
>   http://jena.apache.org/download/index.html
>
>Development builds are available from:
>
> 
>https://repository.apache.org/content/repositories/snapshots/org/apache/je
>na/
>
>Dave
>
>On 19/03/13 22:42, Léonard PETNGA wrote:
>> 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.o
>>>rg/jira/browse/JENA-413>fixes the 0 duration issue (fixed, closed)
>>>
>>> 
>>>https://issues.apache.org/**jira/browse/JENA-414<https://issues.apache.o
>>>rg/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.o
>>>rg/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://w
>>>>>ww.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.w
>>>>>3.org/TR/xmlschema11-2/#yearMonthDuration>
>>>>>
>>>>> or
>>>>>
>>>>> 
>>>>>http://www.w3.org/TR/**xmlschema11-2/#dayTimeDuration<http://www.w3.or
>>>>>g/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
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>

Reply via email to