When I add triples that use rdfs:subPropertyOf, Blazegraph adds a reflexive triple. After doing some research, I came to the conclusion that I could turn off this behavior by going into the blazegraph.properties file and uncommenting this line:
com.bigdata.rdf.store.AbstractTripleStore.axiomsClass=com.bigdata.rdf.axioms.NoAxioms
I then deleted the journal and namespace my app is using, started up the service again, recreated the namespace, and tested to see if I could add a subPropertyOf triple without the extra triples being added in, and I still can't. Is there anything else I need to do? Or am I incorrect in thinking this behavior is inference?
Related
I am trying to add an accelerator to the rocket chip framework through the MMIO peripheral. I went through the GCD example and was able to build the basic GCD code. I then replaced the GCD with an accelerator which has it's own Config, Parameters and Field information. Now when I try to pass this information to the rocket chip there is a name clash with the freechips.rocketchip.config.{Parameters, Field, Config}. I tried specifying the whole path i.e; accelerator.util.conig.Parameters to distinguish it from freechips.rocketchip.config.Parameters but it still gave me the same error. When I remove my accelerator configs and parameters and pass simple hand made parameters the build is successful, however, when I add my config I get %Error-TIMESCALEMOD and this error is in the generated file which I am not modifying. I tried a work around by altering my verilator options but that goes down a rabbit hole of errors. I have narrowed down the problem to the fact that this is being caused because I am using two different configs both of which have their own Config.scala file shown here Is there a way to fix this problem? I have attached the error with this question.
The problem was with a blackbox, not sure why it was giving me that error, but yes we can mix two different configs having different util.config files. We just have to specify them explicitly.
I would like to annotate the first token of a text and use that annotation in following rules. I have tried different patterns:
Token.begin == 0 (doesn't work, although there definitely is a token that begins at 0)
Token{STARTSWITH(DocumentMetaData)}; (also doesn't work)
The only pattern that works is:
Document{->MARKFIRST(First)};
But if I try to use that annotation e.g. in the following way:
First{->MARK(FirstAgain)};
it doesn't work again. This makes absolutely no sense to me. There seems to be a really weird behaviour with annotations that start at 0.
This trivial task can be a bit tricky indeed, mainly because of the visibility settings. I do not know why your rules in the question do not work without having a look at the text that should be processed.
As for UIMA Ruta 2.7.0, I prefer a rule like:
# Token{->First};
Here some additional thoughts about the rules in the question:
Token.begin == 0;
Normally, there is not token with begin at 0 since the document starts with some whitespaces or line breaks. If there is actually a token that starts at offset 0 and the rule does not match, then something invisible is covering the begin of the end of the token. This depends of course of the filtering settings, but in case that you did not change them, it could be a bom.
Token{STARTSWITH(DocumentMetaData)};
Here, either the problem above applies, or the begin offset is not identical. If the DocumentMetaData covers the complete document, then I would bet on the leading whitespaces. Another reason could be that the internal indexing is broken, e.g., the tokens or the DocumentMetaData are created by an external analysis engine which was called with EXEC and no reindexing was configured in the action. This situation could also occur with unfortunate optimizations using the config params.
Document{->MARKFIRST(First)};
First{->MARK(FirstAgain)};
MARKFIRST creates an annotation using the offset of the first RutaBasic in the matched context IIRC. If the document starts with something invisible, e.g., a line break, then the second rule cannot match.
As a general advice in situations like this when some obvious simple rules do not work correctly as expected, I recommend adding some additional rules and using the debugging config with the explanation view. As rule like Token; can directly highlight if the visibility setting are problematic for the given tokens.
DISCLAIMER: I am a developer of UIMA Ruta
just out of curiosity:
As you all might or might know, it is possible to set a custom BE logo with $GLOBALS['TBE_STYLES']['logo'] = '../fileadmin/mylogo.png'; in typo3conf/extTables.php.
This behavior is working since old v4.x times.
But I just read that extTables will be deprecated in v8.x.
I tried to find a simple solution to this (one that keeps that one-line simplicity and does NOT require me to create&install an extension!)
I moved this line to typo3conf/AdditionalConfiguration.php,
but it does not work from there.
Why?
What would be necessary to make this line work within typo3conf/AdditionalConfiguration.php ?
In TYPO3 8.x you'll be able to change a backend logo via EXT:backend, so you should stick to that approach. Read more in release notes.
UPDATE.
To answer your question, why TBE_STYLES defined in AdditionalConfiguration are ignored: take a look at unsetReservedGlobalVariables() method from \TYPO3\CMS\Core\Core\Bootstrap class. It is executed after all the configuration is initialized (Local and Additional are merged and populated) and explicitly calls unset($GLOBALS['TBE_STYLES']);.
...and why has the package this misleading name (I assumed it had something to do with JavaME or mobile/smart phones)?
I found no references on the internet about scala.mobile.Code or scala.mobile.Location at all nor did I manage to do anything with those classes except getting ClassCastExcetions or NoSuchMethodErrors.
Actually there is not even a single test against scala.mobile in the Scala's test tree which could help understanding that code.
The classes really smell like they were forgotten in the source tree a long time ago and got accidentally released since that.
Maybe I just missed something about them?
Update:
scala.mobile was removed in Scala 2.9.
I just checked the source code.
When Scala changed the name mangling of class files a few years ago and it seems people forgot to update these classes accordingly.
So my answer would be:
At least Location has no purpose, because it is not possible to get anything sensible out of it (except exceptions) and Code without Location is severely limited. It works though if you pass the class literal to Code directly:
import scala.mobile._
val c = new Code(classOf[scala.collection.mutable.StringBuilder])
c.apply[StringBuilder, String]("append")("Foo")
c.apply[String]("toString")() // returns "Foo"
c.apply[Int]("length")() // returns 3
Looks like yet-another implementation in the standard library of reflection-slightly-nicer.
The description of Location pretty much explains what that is about:
The class Location provides a create method to instantiate objects
from a network location by specifying the URL address of the jar/class file.
It might be used by remote actors. Maybe.
As for why it has this misleading name? Well, back in 2004 smart phones had really low penetration, so maybe the association wasn't all that strong.
I'm working on a very large CGI application that uses Crypt::RSA, which is properly installed. I get a "attempted to call a null reference as a function" type of error (I can't go back to get the exact error right now because we had to rollback for a release date) when I try to run any the embedded library. I trace the null reference to Crypt::RSA's constructor, which uses Class::Loader to enable Crypt::RSA::ES::OAEP.
I replaced the class loader with a "use" and a "new", and that part works fine, though the library still fails in many points. Obviously something is wrong with my environment. I'm just not certain as to what. Can anyone give me any leads?
Ok, after 12 hours of digging into it, I got this working.
Here's what was going on (but not why). Whenever I called eval() on a quoted use or require statement (as occurs in Class::Loader, but also in other locations in the Crypt:: framwork), it failed to see paths that were otherwise included as Perl classpaths. Since most quoted use/require objects simply assume the class will be there, very few useful errors were thrown out at me. I would dump #INC to file, outside an eval block, and everything would be there.
Ironically, I used the same setup in dev vs staging, and it worked in dev, but not in staging. I must also point out that FindBin (I shouldn't be using it in CGI, I know, but Crypt uses it) was flailing up and down about /dev/null in staging, but not in development.
Since I can't easily compare versions or global configs, that's where my quest ends.
How I resolved the issue for myself in Crypt::RSA was to disable all commands tied to FindBin, and hard-code require references for anything my code would ever access. I did a require in Crypt::RSA for Crypt::RSA::ES::OAEP and one in Crypt::Random::Generator for Crypt::Random::Provider::rand
Hope this helps anyone in the future who has the problem. Anyone who can suggest the why of it, please respond and I'll add it to complete the post.