RDF 1.1 : Work-in-progress

[Andy Seaborne <an...@apache.org>]

 From the commits list, and JENA-816, you may have noticed I've started 
working through the RDF 1.1 isms.

There is a flag in JenaRuntime to control the system mode and a test in 
the jena-core to stop that building with the RDF 1.1 mode set.

The test suites don't yet pass in RDF 1.1 mode - there is code that 
makes reasonably but RDF 1.0 assumptions about xsd:string not being the 
same as simple literals, and datatype code not being aware that language 
tags imply a datatype of rdf:langString.

No work on the persistent storage implications yet.

	Andy

Re: RDF 1.1 : Work-in-progress : xsd:string

[Andy Seaborne <an...@apache.org>]

Update: jena-core, jena-arq, jena-tdb, and jena-sdb now all done.

No changes for jena-jdbc and jena-hadoop - tests pass unchanged.

Fixed to tests in

* jena-security - see next email.
* jena-querybuilder.  See below.

When set up for RDF 1.1, the main build passes.

--------------------------

To run in RDF 1.1 mode:

1/ Change  jena-core :: JenaRuntime.isRDF11 = true

2/ Change TestSystemSetup (this check the mode to avoid jena2 in RDF 1.1 
mode()

3/ In ARQ, under "testing/" there are pairs of results files with 
"RDF_10" and "RDF_11" in the file name.  Need to install the right version.

4/ mvn clean install

Reloading persistent data that used explicit xsd:string is necessary.
If the data never used explicit xsd:string, it should work (in theory!)

--------------------------

Notes::

:: jena-querybuilder

addWhere(?,?,"three") adds an xsd:string (I didn't expect that)

But in RDF 1.1 that is printed as "three", not "three"^^xsd:string. 
Some of the tests are sensitive to the presentation form.

The tests generate a lot of:
WARN  setResultVars(): no query pattern

Claude ::
Jena_Commons and Jena_New_Tests were not being run.  I've tried to fix 
them as best I can but I would be grateful if you'd check them.


On 01/12/14 19:26, Andy Seaborne wrote:
> Update: jena-core & jena-arq status
>
> If you want to play, set:
>
> JenaRuntime.isRDF11 = true
>
> Do not run on persistent storage yet.

Data using explicit xsd;string will need to be reloaded.

> ** jena-arq:
>
> Todo-2/
> ARQ sorts deterministically, even where the SPARQL spec does not require
> it.  The spec requires simple literals before datatype literals.  ARQ
> then sorts by lexical form then by datatype URI.

The most compatible sort order now active (for RDF 1.1)

> Note: Bonus: TransformFilterEquality can now process the string case as
> an optimization.

Done.

Re: RDF 1.1 : Work-in-progress : xsd:string

[Andy Seaborne <an...@apache.org>]

Update: jena-core & jena-arq status

If you want to play, set:

JenaRuntime.isRDF11 = true

Do not run on persistent storage yet.


** jena-core:

Notes:
The Literal.getInt etc operations now cast xsd;strings, not just plain 
literals.  Its the most compatible way forward.  Personally, I think the 
whole casting thing in this area id now wrong (it's an XML-centric 
feature because of prevalence of <property>123</property>).

Todo-1/
There is one RDF/XML-ABBREV writer thing to sort out - it is not using 
attributes for simple strings because they have type xsd:string now.

** jena-arq:

Todo-2/
ARQ sorts deterministically, even where the SPARQL spec does not require 
it.  The spec requires simple literals before datatype literals.  ARQ 
then sorts by lexical form then by datatype URI.

So in SPARQL/RDF-1.0 :

"5" < "5"^^xsd:integer < "5"^^xsd:string

but RDF-1.1 makes "abc" the same term as "abc"^^xsd:String.

Generally, 1.0->1.1 is about treating xsd:string like simple literals 
(no datatpe, no language) so that becomes:

"5" < "5"^^xsd:integer

There are 3 tests that catch this.

Todo-3/
Similarly, it's sorting rdf:langString as a datatype, not as a language 
literal.  2 tests.

Todo-4/
Some of the scripted tests need fixing, including some WG ones which use 
DISTINCT and now "a" and "a"^^xsd:string are the same when they use dot 
be different.

Note: Bonus: TransformFilterEquality can now process the string case as 
an optimization.

Note: Discovery:

SimpleSelector(null, null, 5) does not find "5"^^xsd:integer, only "5" 
which I find bizarre in the extreme.  It always been this way - it's not 
an RDF-1.1-ism.

	Andy

Re: RDF 1.1 : Work-in-progress

[Andy Seaborne <an...@apache.org>]

On 22/11/14 17:28, Andy Seaborne wrote:
>  From the commits list, and JENA-816, you may have noticed I've started
> working through the RDF 1.1 isms.
>
> There is a flag in JenaRuntime to control the system mode and a test in
> the jena-core to stop that building with the RDF 1.1 mode set.
>
> The test suites don't yet pass in RDF 1.1 mode - there is code that
> makes reasonably but RDF 1.0 assumptions about xsd:string not being the
> same as simple literals, and datatype code not being aware that language
> tags imply a datatype of rdf:langString.
>
> No work on the persistent storage implications yet.
>
>      Andy
>

The set of commits I've just pushed is part of cleaning up 
Literal(Label) creation.  It removes the use of defaults (where lang is 
"" or null, or the datatype is null) and makes a call to a factory 
creation create(String, String), create(String, Datatype) or 
create(String).  This reduces the use of consta

In RDF 1.1, there is always a datatype and while the code all works, it 
is less clear when the caller says "datatype = null" and the created 
Node has datatype not null.

The original (String, String, Datatype) operations are still there.  Any 
existing code is unaffected in RDF 1.0.

	Andy