Hi Lewis,
On 14/03/18 06:13, Lewis John McGibbney wrote:
Hi Dave,
Coming back to this to address some thing I missed before
On 2018/03/07 08:57:47, Dave Reynolds wrote:
OntModels use a somewhat older stack of tools (FileManager) which
guesses the language based on
Hi Dave,
Coming back to this to address some thing I missed before
On 2018/03/07 08:57:47, Dave Reynolds wrote:
> OntModels use a somewhat older stack of tools (FileManager) which
> guesses the language based on the suffix, with a default of RDF/XML, and
> then
OK I can open it with Midori. Firefox on the other hand always shows me a login
prompt with the message "ASF Committers" (even after I've cleaned the cache). I
don't know, I don't have an account on apache.org.
Sent: Wednesday, March 14, 2018 at 12:42 PM
From: ajs6f
To:
Lewis,
I tried:
OntModel m = ModelFactory.createOntologyModel();
m.read("http://sweetontology.net/sweetAll;, null, "TTL");
System.out.println("DONE");
System.exit(0);
and it worked for me (3.6.0, 3.7.0-dev; apache-jena-libs)
Have you got any local copies
On 14/03/18 01:34, Laura Morales wrote:
JENA-1461: Allow ARQ custom functions to be written in JavaScript
Draft documentation:
http://jena.apache.org/documentation/query/javascript-functions.html
404?
http://jena.staging.apache.org/documentation/query/javascript-functions.html
Andy
> http://jena.staging.apache.org/documentation/query/javascript-functions.html
401
I'd actually like to read about "ARQ custom functions to be written in
JavaScript", is there a public link for this document?
Andy,
I don't think that helps much. In fact, I think treating ASK result
differently from SELECT breaks some abstractions.
What I mean is that the result data structure normally maps to a media type
and not its query form. That way we can have generic parsers/serializers
that are orthogonal to
You've made a common error that people trying to benchmark Jena make.
execSelect() simply prepares a result set backed by an iterator that is capable
of answering the query, until you are consume that result set no execution
actually takes place. All query execution in Jena is lazy, if you
Hi Rob,
Did you notice that in each case I display the full resultSet (and
therefore consume it) in the console ?In each case, I gave two numbers:
one that measures the time taken by execSelect (this number is relevant
since it can change a lot depending upon the query) and the second
number that
Hi,
I have included here
(https://gist.github.com/MarcAgate/8bbe334fd852817977c909af107a9c6b) some code
tha illustrates the issue.
It runs the same query against three different models (Model, InfModel and
OntModel) of the same ontology.
There's obviously a problem with InfModel.
Any idea ?
On 14/03/18 12:48, Martynas Jusevičius wrote:
Andy,
I don't think that helps much. In fact, I think treating ASK result
differently from SELECT breaks some abstractions.
What I mean is that the result data structure normally maps to a media type
and not its query form. That way we can have
> -Original Message-
> From: Martynas Jusevičius
> Sent: Monday, March 12, 2018 5:11 PM
> To: jena-users-ml
> Subject: Re: Getting Symmetric Concise Bounded Description with Fuseki
>
> I disagree about SCBD as the default. In a Linked
Marc
Yes, displaying the result set is the first operation that actually consumes
the results and thus actually executes the query hence my point. When you call
execSelect() you are just getting a placeholder object that knows how to
execute the query at some future point in time. Only when
In the case of inference then yes there is also an upfront cost of
computing the inferences. Once computed these are typically cached
(though this depends on the rule set) and any changes to the data
might invalidate that cache. You can call prepare() on the InfModel
to incur the initial
On 14/03/18 19:12, Élie Roux wrote:
In the case of inference then yes there is also an upfront cost of
computing the inferences. Once computed these are typically cached
(though this depends on the rule set) and any changes to the data
might invalidate that cache. You can call prepare() on
Hi,
owlURL is the url of the bdrc.owl file that is used to create the
Ontology model.
public static final String owlURL="https://raw.githubusercontent.com/Bu
ddhistDigitalResourceCenter/owl-schema/master/bdrc.owl";
Marc
Le mercredi 14 mars 2018 à 20:25 +, Andy Seaborne a écrit :
>
> On
16 matches
Mail list logo