Hi,
While trying to find a query that works and performs well enough I
noticed that this query:
PREFIX skos: <http://www.w3.org/2004/02/skos/core#>
PREFIX text: <http://jena.apache.org/text#>
SELECT *
WHERE {
GRAPH ?graph {
?s text:query 'musiikkikasv*' .
}
}
VALUES ?graph { <http://www.yso.fi/onto/yso/> }
when there are any potential results, produces this error:
Error 500: Attempt to reassign '?graph' from
'<http://www.yso.fi/onto/yso/>' to '<http://www.yso.fi/onto/yso/>'
I guess this is a bug related to jena-text, since a basic graph pattern
instead of the text:query pattern works.
If I change ?graph to the actual URI and remove the VALUES clause, then
there is no error.
This also happens with 1.3.0 so this is not a new bug.
-Osma
Fuseki - version 1.3.1-SNAPSHOT (Build date: 2015-12-06T09:53:42+0000)
10.12.2015, 15:14, Osma Suominen kirjoitti:
Hi Andy!
I'm very sorry, I've done some testing on intermediate versions
(particularly as I was developing the customizable jena-text analyzer)
but apparently I hadn't tried this particular type of query where the
text condition is outside the GRAPH block. We use them in only in a
special case situation (global search across many SKOS vocabularies) in
the Skosmos application.
I retract my -1 vote. As you say, the vote should be about doing the
release process properly, not the technical side.
I'm still trying to understand the problem. I've tested the Join flags
but I haven't been able to produce any difference. I set both flags to
true but the results were the same as before. For the shorter query,
?label remains unbound and the query takes 400-600 ms.
From your newer message:
Simpler query:
PREFIX : <http://example/>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
SELECT *
WHERE
{ ?s :p ?literal
GRAPH :g
{ ?s rdfs:label ?label
FILTER ( ?label = ?literal )
}
}
Note also putting the text:query inside {} makes things worse. It
isolates that part
In this case the ?literal in the FILTER is out of scope of the basic
graph pattern it is defined in.
Right, thanks, I think I now understand what is happening.
Is there a way to rewrite that query so that ?literal would be in scope
for the FILTER, while still keeping the first pattern (?s :p ?literal)
outside the GRAPH block, i.e. targeting the default graph?
I'm willing to rewrite the queries in my application so that they work
with the current ARQ. So far I just haven't found a way to do this:
1. make a jena-text query *without any graph*
2. using bindings from the results of that query, match additional
patterns from specific graphs
-Osma
10.12.2015, 13:26, Andy Seaborne kirjoitti:
Hi Osma,
The primary purpose of the vote is to verify that the release process
has been executed correctly. A majority and 3 of PMC votes are needed
to show that the release meets the requirements for a release.
I signalled a possible release last month and got a positive response
from you about proceeding. There are several new features in this
release and it would be good to get those out to people.
Whether a release meets technical goals is a separate matter.
If this is a simple fix, then I'm willing to redo the release but to
quite clear that is not because it fails the release criteria but
because I, not as an release manager, want to get useful code to the
public.
I think if we make the vote the start of checking months of changes,
then we'd never release anything. There have been builds for some time.
A possible change was JENA-1023 and that was in September. There is a
flag in class "Join" to control the join strategy. Please try that (it
needs a rebuild as it's a private static final).
Andy
http://www.apache.org/dev/release.html#approving-a-release
PS can you use Fuseki 2? (it will not make a performance difference, it
is better code)
On 10/12/15 09:57, Osma Suominen wrote:
On 08/12/15 13:56, Andy Seaborne wrote:
Hi,
Here is a vote on a release of Jena 3.0.1 with Fuseki 2.3.1 and Fuseki
1.3.1.
-1.
We installed Fuseki 1.3.1-SNAPSHOT 2015-12-07T14:05:00+0000 on our dev
server today. The query below now takes more than 100 seconds. With
1.3.0 it takes about 2.5 seconds. The configuration and databases are
the same.
I'll try to investigate further and isolate a more minimal example. I
just wanted to raise this ASAP.
-Osma
PREFIX owl: <http://www.w3.org/2002/07/owl#>
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX skos: <http://www.w3.org/2004/02/skos/core#>
PREFIX isothes: <http://purl.org/iso25964/skos-thes#>
PREFIX text: <http://jena.apache.org/text#>
PREFIX cn: <http://urn.fi/URN:NBN:fi:au:cn:>
PREFIX lapponica: <http://urn.fi/URN:NBN:fi:au:lapponica:>
SELECT DISTINCT ?s ?label ?plabel ?alabel ?hlabel ?graph
(GROUP_CONCAT(DISTINCT ?type) as ?types)
WHERE {
VALUES (?prop) { (skos:prefLabel) (skos:altLabel) (skos:hiddenLabel) }
{ (?s ?score ?literal) text:query (?prop 'musiikki*' 100000) }
GRAPH ?graph {
{ ?s rdf:type <http://www.w3.org/2004/02/skos/core#Concept> } UNION {
?s a isothes:ConceptGroup }
{
?s rdf:type ?type .
OPTIONAL {
?s skos:prefLabel ?label .
FILTER (langMatches(lang(?label), lang(?literal)))
}
}
FILTER NOT EXISTS { ?s owl:deprecated true }
}
BIND(IF(?prop = skos:prefLabel && ?literal != ?label, ?literal,
?unbound) as ?plabel)
BIND(IF(?prop = skos:altLabel, ?literal, ?unbound) as ?alabel)
BIND(IF(?prop = skos:hiddenLabel, ?literal, ?unbound) as ?hlabel)
}
GROUP BY ?literal ?s ?label ?plabel ?alabel ?hlabel ?graph ?prop
ORDER BY lcase(str(?literal)) lang(?literal) ?graph
VALUES (?graph) { (<http://www.yso.fi/onto/afo/>)
(<http://www.yso.fi/onto/allars/>)
(<http://avoindata.fi/onto/contentType/>)
(<http://avoindata.fi/onto/topic/>) (<http://urn.fi/URN:NBN:fi:au:cn:>)
(<http://iconclass.org/>) (<http://cv.iptc.org/newscodes/scene/>)
(<http://cv.iptc.org/newscodes/subjectcode/>)
(<http://www.yso.fi/onto/juho/>) (<http://www.yso.fi/onto/jupo/>)
(<http://www.yso.fi/onto/kassu/>) (<http://www.yso.fi/onto/kauno/>)
(<http://www.yso.fi/onto/kito/>) (<http://www.yso.fi/onto/koko/>)
(<http://www.yso.fi/onto/kto/>) (<http://www.yso.fi/onto/kulo/>)
(<http://urn.fi/URN:NBN:fi:au:lapponica:>)
(<http://www.yso.fi/onto/liito/>) (<http://lexvo.org/id/iso639-3/>)
(<http://www.yso.fi/onto/tao/>) (<http://www.yso.fi/onto/mero/>)
(<http://www.yso.fi/onto/mesh/>) (<http://metatietosanasto.fi/>)
(<http://www.yso.fi/onto/musa/>) (<http://www.yso.fi/onto/muso/>)
(<http://www.yso.fi/onto/okm-tieteenala/>)
(<http://www.yso.fi/onto/paikat/>)
(<http://www.yso.fi/onto/ponduskategorier/>)
(<http://www.yso.fi/onto/pto/>) (<http://www.yso.fi/onto/puho/>)
(<http://www.yso.fi/onto/sapo/>) (<http://www.yso.fi/onto/tero/>)
(<http://www.yso.fi/onto/tsr/>) (<http://www.yso.fi/onto/valo/>)
(<http://www.yso.fi/onto/ysa/>) (<http://www.yso.fi/onto/yso/>)
(<http://aims.fao.org/aos/agrovoc/>) (<http://skos.um.es/unescothes/>) }
--
Osma Suominen
D.Sc. (Tech), Information Systems Specialist
National Library of Finland
P.O. Box 26 (Kaikukatu 4)
00014 HELSINGIN YLIOPISTO
Tel. +358 50 3199529
[email protected]
http://www.nationallibrary.fi
