Re: JSON-LD: 1.0 or 1.1

2022-03-15 Thread Andy Seaborne 




On 15/03/2022 18:13, Martynas Jusevičius wrote:

Hi,

Are the output "flavors" for JSON-LD 1.0 only then?
https://jena.apache.org/documentation/io/rdf-output.html#json-ld


Yes.



On Fri, Mar 11, 2022 at 11:39 AM Andy Seaborne  wrote:


Jena has both JSON 1.0, provided by jsonld-java, and JSON-LD 1.1,
provided by Titanium.

What should the default settings be?

For parsing that means what is bound to "application/ld+json" and file
extension .jsonld.

For writing, it means what is setup for Lang.JSONLD.

This is two decisions - parsing and writing can be different.


But.

It is not so simple:

1/ For Java11, the default settings for java.net.http can't contact
schema.org.

This is not a problem with Titanium.

See example code that uses only the plain java.net.http package.

https://issues.apache.org/jira/browse/JENA-2306

HTTP/2 works for java 17.0.2, but does not work for java 11.0.14.

And that means { "@context": "https://schema.org/; } does not work.

(http: redirects to that as well)

This _may_ be:
https://bugs.openjdk.java.net/browse/JDK-8218546

in which case it is fixed in java 11.0.15.

In my testing, it wasn't just google HTTP/2 sites.

** Please try the example code and report the Java version and what happens.

2/ Jena is writing JSON-LD 1.1 without much in the way of transformation
nor creating a @context from the RDF data. It prints full URIs; numbers
aren't abbreviated etc etc. so it not very pretty.

Or should Jena only write some plain output and expect the application
to further transform it?

Even for this, it needs some improvement so that there is a @context to
work from.

** Can you contribute here? The code is in JsonLD11Writer.java.

  https://issues.apache.org/jira/browse/JENA-2153

  Andy

Re: [4.3.2] Cannot invoke "org.apache.jena.rdf.model.Property.asNode()" because "org.apache.jena.vocabulary.RDF.type" is null

2022-03-15 Thread Martynas Jusevičius 
Hi,

On Wed, Mar 9, 2022 at 12:34 PM Andy Seaborne  wrote:
>
>
>
> On 09/03/2022 11:16, Martynas Jusevičius wrote:
> > Hi,
> >
> > This appeared after Java upgrade from 11 to 17:
> >
> > WARN LocationMapper:188 - Error in configuration file: Cannot invoke
> > "org.apache.jena.rdf.model.Property.asNode()" because
> > "org.apache.jena.vocabulary.RDF.type" is null
>
> May be init related ... depends when it happened in the app.

Most likely is as it happens very early in the startup.
I haven't noticed it with Java 11 though, pretty sure it wasn't there.

>
> Always good to call
> JenaSystem.init
> before any Jena code is touched if you can. It makes the whole thing
> deterministic.
>

JenaSystem.init() is called in a ServletContextListener.

> > I was looking at the LocationMapper code, but line 188 does not
> > contain anything like that:
> > https://github.com/apache/jena/blob/main/jena-core/src/main/java/org/apache/jena/util/LocationMapper.java#L188
>
> Wrong location manager?

We have a custom PrefixMapper, but from the first look line #188
doesn't look related either:
https://github.com/AtomGraph/Web-Client/blob/master/src/main/java/com/atomgraph/client/locator/PrefixMapper.java#L188
Or is it?

>
> Look at any stacktraces.

There is no stack trace.

>
> Run 4.4.0.

Will do soon :)

>
> >
> > What is the cause and does this need to be addressed?
> >
> > Martynas

Re: JSON-LD: 1.0 or 1.1

2022-03-15 Thread Martynas Jusevičius 
Hi,

Are the output "flavors" for JSON-LD 1.0 only then?
https://jena.apache.org/documentation/io/rdf-output.html#json-ld

On Fri, Mar 11, 2022 at 11:39 AM Andy Seaborne  wrote:
>
> Jena has both JSON 1.0, provided by jsonld-java, and JSON-LD 1.1,
> provided by Titanium.
>
> What should the default settings be?
>
> For parsing that means what is bound to "application/ld+json" and file
> extension .jsonld.
>
> For writing, it means what is setup for Lang.JSONLD.
>
> This is two decisions - parsing and writing can be different.
>
>
> But.
>
> It is not so simple:
>
> 1/ For Java11, the default settings for java.net.http can't contact
> schema.org.
>
> This is not a problem with Titanium.
>
> See example code that uses only the plain java.net.http package.
>
>https://issues.apache.org/jira/browse/JENA-2306
>
> HTTP/2 works for java 17.0.2, but does not work for java 11.0.14.
>
> And that means { "@context": "https://schema.org/; } does not work.
>
> (http: redirects to that as well)
>
> This _may_ be:
> https://bugs.openjdk.java.net/browse/JDK-8218546
>
> in which case it is fixed in java 11.0.15.
>
> In my testing, it wasn't just google HTTP/2 sites.
>
> ** Please try the example code and report the Java version and what happens.
>
> 2/ Jena is writing JSON-LD 1.1 without much in the way of transformation
> nor creating a @context from the RDF data. It prints full URIs; numbers
> aren't abbreviated etc etc. so it not very pretty.
>
> Or should Jena only write some plain output and expect the application
> to further transform it?
>
> Even for this, it needs some improvement so that there is a @context to
> work from.
>
> ** Can you contribute here? The code is in JsonLD11Writer.java.
>
>  https://issues.apache.org/jira/browse/JENA-2153
>
>  Andy

Re: SPARQL optional limiting results

2022-03-15 Thread Mikael Pesonen 



Hi,

sorry I cleaned up the example a bit too much. So OPTIONAL is collecting 
additional data like this:


 OPTIONAL { ?concept skos:broader* [ skos:topConceptOf ?graph; 
skos:prefLabel ?topConceptLabel ] }


But even with original example, OPTIONAL shouldn't return fewer rows?


On 15/03/2022 9.30, Lorenz Buehmann wrote:

Hi,

I'm probably misunderstanding the query, but what is the purpose of 
the OPTIONAL here?


?graph is bound because of VALUES clause, ?concept is bound because of 
the graph pattern before the OPTIONAL as well.


So ?graph and ?concept are bound on the left hand side of the 
left-join aka OPTIONAL


Here is the algebra:

(join
  (table (vars ?graph)
    (row [?graph])
    (row [?graph])
  )
  (assign ((?graph ?*g0))
    (leftjoin
  (distinct
    (project (?concept ?prefLabelm ?altLabelm)
  (filter (= (lang ?prefLabelm) "fi")
    (quadpattern
  (quad ?*g0 ??0 rdf:first ?concept)
  (quad ?*g0 ??0 rdf:rest ??1)
  (quad ?*g0 ??1 rdf:first ?score1)
  (quad ?*g0 ??1 rdf:rest ??2)
  (quad ?*g0 ??2 rdf:first ?prefLabelm)
  (quad ?*g0 ??2 rdf:rest rdf:nil)
  (quad ?*g0 ??0 text:query ??3)
  (quad ?*g0 ??3 rdf:first skos:prefLabel)
  (quad ?*g0 ??3 rdf:rest ??4)
  (quad ?*g0 ??4 rdf:first "aamiainen*")
  (quad ?*g0 ??4 rdf:rest rdf:nil)
    
  (sequence
    (graph ?*g0
  (path ?concept (path* skos:broader) ??5))
    (quadpattern (quad ?*g0 ??5 skos:topConceptOf ?graph)


Can you say what you want to achieve with the OPTIONAL maybe, it won't 
return any additional data as far as I can see.


On 14.03.22 14:30, Mikael Pesonen wrote:
Hi, not directly related to Jena, but I have a query in which 
optional clause limits the number of results. I thought it's never 
possible. So below query returns less results with optional enabled. 
Wonder why is that and what would be the correct way to get optional 
data so than all rows are returned?


SELECT *
WHERE
{
    VALUES ?graph { 
}

    GRAPH ?graph
    {
    {
        SELECT DISTINCT ?concept ?prefLabelm ?altLabelm WHERE
        {
            {
                (?concept ?score1 ?prefLabelm) text:query 
(skos:prefLabel "aamiainen*") .

    FILTER ( (lang(?prefLabelm) = "fi" ))
            }
    }
    }
   # OPTIONAL { ?concept skos:broader* [ skos:topConceptOf ?graph] }
    }
}


--
Lingsoft - 30 years of Leading Language Management

www.lingsoft.fi

Speech Applications - Language Management - Translation - Reader's and Writer's 
Tools - Text Tools - E-books and M-books

Mikael Pesonen
System Engineer

e-mail: mikael.peso...@lingsoft.fi
Tel. +358 2 279 3300

Time zone: GMT+2

Helsinki Office
Eteläranta 10
FI-00130 Helsinki
FINLAND

Turku Office
Kauppiaskatu 5 A
FI-20100 Turku
FINLAND

Re: SPARQL optional limiting results

2022-03-15 Thread Lorenz Buehmann 

Hi,

I'm probably misunderstanding the query, but what is the purpose of the 
OPTIONAL here?


?graph is bound because of VALUES clause, ?concept is bound because of 
the graph pattern before the OPTIONAL as well.


So ?graph and ?concept are bound on the left hand side of the left-join 
aka OPTIONAL


Here is the algebra:

(join
  (table (vars ?graph)
(row [?graph])
(row [?graph])
  )
  (assign ((?graph ?*g0))
(leftjoin
  (distinct
(project (?concept ?prefLabelm ?altLabelm)
  (filter (= (lang ?prefLabelm) "fi")
(quadpattern
  (quad ?*g0 ??0 rdf:first ?concept)
  (quad ?*g0 ??0 rdf:rest ??1)
  (quad ?*g0 ??1 rdf:first ?score1)
  (quad ?*g0 ??1 rdf:rest ??2)
  (quad ?*g0 ??2 rdf:first ?prefLabelm)
  (quad ?*g0 ??2 rdf:rest rdf:nil)
  (quad ?*g0 ??0 text:query ??3)
  (quad ?*g0 ??3 rdf:first skos:prefLabel)
  (quad ?*g0 ??3 rdf:rest ??4)
  (quad ?*g0 ??4 rdf:first "aamiainen*")
  (quad ?*g0 ??4 rdf:rest rdf:nil)

  (sequence
(graph ?*g0
  (path ?concept (path* skos:broader) ??5))
(quadpattern (quad ?*g0 ??5 skos:topConceptOf ?graph)


Can you say what you want to achieve with the OPTIONAL maybe, it won't 
return any additional data as far as I can see.


On 14.03.22 14:30, Mikael Pesonen wrote:
Hi, not directly related to Jena, but I have a query in which optional 
clause limits the number of results. I thought it's never possible. So 
below query returns less results with optional enabled. Wonder why is 
that and what would be the correct way to get optional data so than 
all rows are returned?


SELECT *
WHERE
{
    VALUES ?graph { 
}

    GRAPH ?graph
    {
    {
        SELECT DISTINCT ?concept ?prefLabelm ?altLabelm WHERE
        {
            {
                (?concept ?score1 ?prefLabelm) text:query 
(skos:prefLabel "aamiainen*") .

    FILTER ( (lang(?prefLabelm) = "fi" ))
            }
    }
    }
   # OPTIONAL { ?concept skos:broader* [ skos:topConceptOf ?graph] }
    }
}