Re: RDF Connection

2022-05-17 Thread Erich Bremer
https://github.com/apache/jena/issues/1318

On Mon, May 16, 2022 at 3:59 PM Erich Bremer  wrote:

> Will do. - Erich
>
> On Mon, May 16, 2022 at 3:43 PM Andy Seaborne  wrote:
>
>> Hi - could you raise an issue for this please.
>>
>> There's a backlog at th emoment so don't want to loose it.
>>
>>  Andy
>>
>> PS the difference is that there are newlines in the
>> con.query(Query) form and not in the con.query(String) form - add a \nb
>> and I expect it will also break.
>>
>> On 16/05/2022 17:47, Erich Bremer wrote:
>> > I changed
>> > QueryExecution qe = con.query(query);
>> > to
>> > QueryExecution qe = con.query("select ?s where {?s ?p ?o} limit 10");
>> > and it works.  A bug in the former method?  - Erich
>> >
>> > On Mon, May 16, 2022 at 12:31 PM Erich Bremer 
>> wrote:
>> >
>> >> Thanks Andy, this is a huge help.
>> >> using this code:
>> >>
>> >> Query query = QueryFactory.create("select ?s where {?s ?p ?o} limit
>> 10");
>> >> AuthEnv.get().registerUsernamePassword(new URI("
>> >> https://myserver.edu/sparql-auth;), Settings.user, Settings.password);
>> >> HttpClient client = HttpClient.newBuilder()
>> >>  .connectTimeout(Duration.ofSeconds(10))
>> >>  .version(HttpClient.Version.HTTP_1_1)
>> >>  .build();
>> >> RDFConnection con = RDFConnectionRemote.create()
>> >>  .destination(host)
>> >>  .queryEndpoint("sparql-auth")
>> >>  .httpClient(client)
>> >>  .build();
>> >> QueryExecution qe = con.query(query);
>> >> ResultSet results = qe.execSelect();
>> >>
>> >> is throwing an error:
>> >>
>> >> Exception in thread "main" java.lang.IllegalArgumentException: invalid
>> >> header value: "Digest username="username", realm="SPARQL",
>> >> nonce="b7ef0b701772c22b88db561ac58bd55f",
>> uri="/sparql-auth?query=SELECT  ?s
>> >> WHERE
>> >>{ ?s  ?p  ?o }
>> >> LIMIT   10
>> >> ", qop=auth, cnonce="D8DA17AFEAD93444", nc=,
>> >> response="4d8ba8cef8aaa7f22d1adf811c6ac903",
>> >> opaque="5ebe2294ecd0e0f08eab7690d2a6ee69""
>> >> at
>> java.net.http/jdk.internal.net.http.common.Utils.newIAE(Utils.java:286)
>> >> at
>> >>
>> java.net.http/jdk.internal.net.http.HttpRequestBuilderImpl.checkNameAndValue(HttpRequestBuilderImpl.java:113)
>> >> at
>> >>
>> java.net.http/jdk.internal.net.http.HttpRequestBuilderImpl.setHeader(HttpRequestBuilderImpl.java:119)
>> >> at
>> >>
>> java.net.http/jdk.internal.net.http.HttpRequestBuilderImpl.setHeader(HttpRequestBuilderImpl.java:43)
>> >> at
>> >>
>> org.apache.jena.http.auth.DigestLib.lambda$buildDigest$0(DigestLib.java:119)
>> >> at org.apache.jena.http.auth.AuthLib.handle401(AuthLib.java:124)
>> >> at org.apache.jena.http.auth.AuthLib.authExecute(AuthLib.java:54)
>> >> at org.apache.jena.http.HttpLib.execute(HttpLib.java:536)
>> >> at org.apache.jena.http.HttpLib.execute(HttpLib.java:493)
>> >> at
>> >>
>> org.apache.jena.sparql.exec.http.QueryExecHTTP.executeQuery(QueryExecHTTP.java:497)
>> >> at
>> >>
>> org.apache.jena.sparql.exec.http.QueryExecHTTP.performQuery(QueryExecHTTP.java:471)
>> >> at
>> >>
>> org.apache.jena.sparql.exec.http.QueryExecHTTP.execRowSet(QueryExecHTTP.java:168)
>> >> at
>> >>
>> org.apache.jena.sparql.exec.http.QueryExecHTTP.select(QueryExecHTTP.java:160)
>> >> at
>> >>
>> org.apache.jena.sparql.exec.QueryExecutionAdapter.execSelect(QueryExecutionAdapter.java:117)
>> >> at
>> >>
>> org.apache.jena.sparql.exec.QueryExecutionCompat.execSelect(QueryExecutionCompat.java:97)
>> >> at com.mycompany.rad.RDF.(RDF.java:90)
>> >> at com.mycompany.rad.RDF.main(RDF.java:105)
>> >>
>> >> I'm using Graalvm:
>> >> java -version
>> >> openjdk version "17.0.3" 2022-04-19
>> >> OpenJDK Runtime Environment GraalVM CE 22.1.0 (build
>> >> 17.0.3+7-jvmci-22.1-b06)
>> >> OpenJDK 64-Bit Server VM GraalVM CE 22.1.0 (build
>> 17.0.3+7-jvmci-22.1-b06,
>> >> mixed mode, sharing)
>> >>
>> >> - Erich
>> >>
>> >> On Mon, May 16, 2022 at 11:49 AM Andy Seaborne 
>> wrote:
>> >>
>> >>>
>> >>>
>> >>> On 16/05/2022 16:11, Erich Bremer wrote:
>>  It seems in Jena 4.3.X forward HttpClient in
>> RDFConnectionRemoteBuilder
>> >>> was
>>  changed from org.apache.http.client.HttpClient to
>> >>> java.net.http.HttpClient.
>>  The latter doesn't appear to support Digest Authentication.  Is there
>>  support for Digest authentication in 4.3.X forward?  I was able to
>> do it
>>  with the older RDFConnectionRemoteBuilder.  Thanks, Erich
>> 
>> >>>
>> >>> https://jena.apache.org/documentation/sparql-apis/
>> >>>
>> >>> Digest auth is supported (implemented by Jena).
>> >>>
>> >>>   Andy
>> >>>
>> >>
>> >
>>
>


Re: SHACLC and RDFLanguages

2022-05-17 Thread Martynas Jusevičius
On Tue, May 17, 2022 at 1:19 PM Andy Seaborne  wrote:
>
> RDFLanguages is a general registry of names (Lang's) in the system.
>
> It is not for functionality.
>
> RDFParserRegistry
> RDFWriterRegistry
> RowSetReaderRegistry, ResultSetReaderRegistry
> RowSetWriterRegistry, ResultSetWriterRegistry
> StreamRDFWriter
>
> A Lang needs looking up in a registry to see if there is support for it.

Thanks, I didn't know these existed.

But there are no RDFParserRegistry::getRegistered or
ResultSetReaderRegistry::getRegistered methods?

So do I still need to iterate RDFLanguages::getRegistered and check
each Lang against
RDFParserRegistry::isRegistered/ResultSetReaderRegistry::isRegistered?

>
>  Andy
>
> On 17/05/2022 09:54, Martynas Jusevičius wrote:
> > Hi,
> >
> > After upgrading from 4.3.2 to 4.5.0, some of our RDF writing code
> > started failing.
> >
> > It seems that this is due to RDFLanguages.isTriples(Lang.SHACLC)
> > returning true, which messes up our content negotiation as it attempts
> > to write Models as SHACLC. Can this be rectified?
> >
> > The RDFLanguages registry is a bit of an oxymoron in general. Right
> > now it's a bag of all sorts of syntaxes Jena supports, half of which
> > are not even "RDF languages". We need to iterate and filter the
> > languages just to know which ones can be used to read/write Models,
> > which can be used for ResultSets etc.:
> > https://github.com/AtomGraph/Core/blob/master/src/main/java/com/atomgraph/core/MediaTypes.java#L86
> > Wouldn't it make sense to have separate registries depending on the
> > entity types they apply to?
> >
> > Thanks.
> >
> > Martynas


Re: SHACLC and RDFLanguages

2022-05-17 Thread Andy Seaborne

RDFLanguages is a general registry of names (Lang's) in the system.

It is not for functionality.

RDFParserRegistry
RDFWriterRegistry
RowSetReaderRegistry, ResultSetReaderRegistry
RowSetWriterRegistry, ResultSetWriterRegistry
StreamRDFWriter

A Lang needs looking up in a registry to see if there is support for it.

Andy

On 17/05/2022 09:54, Martynas Jusevičius wrote:

Hi,

After upgrading from 4.3.2 to 4.5.0, some of our RDF writing code
started failing.

It seems that this is due to RDFLanguages.isTriples(Lang.SHACLC)
returning true, which messes up our content negotiation as it attempts
to write Models as SHACLC. Can this be rectified?

The RDFLanguages registry is a bit of an oxymoron in general. Right
now it's a bag of all sorts of syntaxes Jena supports, half of which
are not even "RDF languages". We need to iterate and filter the
languages just to know which ones can be used to read/write Models,
which can be used for ResultSets etc.:
https://github.com/AtomGraph/Core/blob/master/src/main/java/com/atomgraph/core/MediaTypes.java#L86
Wouldn't it make sense to have separate registries depending on the
entity types they apply to?

Thanks.

Martynas


SHACLC and RDFLanguages

2022-05-17 Thread Martynas Jusevičius
Hi,

After upgrading from 4.3.2 to 4.5.0, some of our RDF writing code
started failing.

It seems that this is due to RDFLanguages.isTriples(Lang.SHACLC)
returning true, which messes up our content negotiation as it attempts
to write Models as SHACLC. Can this be rectified?

The RDFLanguages registry is a bit of an oxymoron in general. Right
now it's a bag of all sorts of syntaxes Jena supports, half of which
are not even "RDF languages". We need to iterate and filter the
languages just to know which ones can be used to read/write Models,
which can be used for ResultSets etc.:
https://github.com/AtomGraph/Core/blob/master/src/main/java/com/atomgraph/core/MediaTypes.java#L86
Wouldn't it make sense to have separate registries depending on the
entity types they apply to?

Thanks.

Martynas