I am using protege to build an ontology and use the SWRL rules provided with the software for reasoning. When creating a new SWRL rule, I was reminded "protege prefix not registered for prefix name". Many thanks here, can someone tell me how to register the prefix name?
This happened to me too when I used the SWRLTab and the SQWRLTab.
I like to edit my turtle files with an IDE instead of using protege. I prefer this as I end up with a much cleaner and shorter file.
I still use Protege for a better visualization of my Ontology, to use reasoners, etc.
I personally use the Turtle format but this solution should work with all the other formats too, just make sure to adapt it to yours in the right way.
The problem for me was that I stored the Ontology IRI using only the #base declaration.
#base <MY_ONTOLOGY_IRI> .
I did some exploration and find out that Protege also saves a prefix as follow:
#prefix _: <MY_ONTOLOGY_IRI> .
This causes the SWRLTab and the SQWRLTab to expect to find the _: prefix. I think this can happen only if the Ontology is written by hand like in my case. Doesn't matter your situation, just make sure that the #prefix _: and the #base declaration have the same value and You should be fine.
⚠️ An additional note:
After adding the #prefix from my IDE, Protege asked to reload the Ontology with a pop-up. Reloading it was not enough for me. I had to restart Protege completely to make it work.
Related
Please refer to the Expressions Grammar and code generator present in below link
Is there some way to test my grammar which refer to EAttributes?
What I want to do is create a file (.ecore) and save it locally, specifically for the purpose of storing variables and i want my code to cross references the variables of EAttribute type from that ".ecore" file. This is in context with the below rule of grammar.
Atomic returns Expression:
...
{VariableRef} variable=[ecore::EAttribute|QualifiedName];
I am unable to find much help on how to customize a global scope provider as per this requirement. Would really appreciate if someone could guide me in the right direction.
I am converting DITA to XLIFF. In my technical solution I have to specialize (modify) xliff-core-1.2-strict.xsd to accommodate few DITA attributes. It means some attributes will go along with "g" tag. For Example:
<g id="00001" newAtt="this is new attribute" xid="009"/>
From the translation side I am not sure how it will work, so my questions:
Is it general practice that LSPs will get different flavor of XLIFF XSDs from different companies?
And is it possible for them to use it in their XLIFF editor by updating updated XLIFF XSD? I tried to explore “Transolution” but did not find any place where to place modified XSD.
Please let me know if you have any thought on this.
Thanks.
Here are my answers to your two questions:
I work for an LSP and I've seen all sorts and flavors of Xliff. Most of them try to stick to OASIS 1.2 transitional schema. Some of TMS/CAT producers added their own extensions. These producers normally provide an XSD so you can validate their Xliffs by adding that XSD to OASIS schema; e.g. SDL extensions to 1.2. When I'm customizing Xliff for a client, I normally do namespaces and provide a simple additional XSD; e.g.:
<trans-unit id="0" translate="yes" resname="msg_foo">
<superduper:uri>http://foo.bar/iJKLM9</superduper:uri>
<source>This is supposed to be a <superduper:g id="00001" newAtt="this is new attribute" xid="009"/> example.</source>
<target state="new"></target>
</trans-unit>
Most of the TMS/CAT tools are very basic (and closed) when it comes to their Xliff filters (or any of their filters for that matter) and I'm sorta kinda sure that they ignore your customized XSD.
Transolution is a very nice tool and my favorite Open Source translation tool. Unfortunately it's been long abandoned and has plenty of defects and shortcomings.
Anyway, if you provide a sample file, I can tell you what happens to non-conforming tags when it's imported into one of common, major CAT tools.
One final note; <g> seems to be retired in Xliff 2.0.
Forget about Transolution for one thing. I would try it with Trados, MemoQ or MemSource. Those are some of the big tools used in the translation business.
Personally I never got an XLIFF with a XSD, nor do I think Trados can handle it.
What do you need to change in the XLIFF?
I'm developing a xtext-based language which should refer to objects defined in a vendor-specific file format.
E.g. this file format defines messages, my language shall define Rules that work with these messages. Of course i want to use xtext features e.g. to autocomplete/validate message names, attributes etc.
Not sure if that is a good idea, but I came up with the following:
Use one xtext project to describe the file format
Add a dependency for this project to my DSL project, import the file format grammar to my grammar
import the description files via importURI
FileFormat grammar:
grammar com.example.xtext.fileformat.FileFormat;
generate fileformat "http://xtext.example.com/fileformat/FileFormat"
[...]
DSL grammar:
grammar com.example.xtext.dsl.DSL;
import "http://xtext.example.com/fileformat/FileFormat" AS ff;
Model:
rules += Rule*;
Rule: ImportFileRule | SampleRule;
ImportFileRule: "IMPORT" importURI=STRING "AS" name=ID ";";
SampleRule: "FORWARD" msg=[ff::Message] ";"
First of all: This works fine.
Now, different imported files may define messages with colliding names,
and I want to use fully qualified names for messages anyways.
The prefix for the message names should be defined in my DSL, e.g. the name of the ImportFileRule.
So I would like to use something like:
IMPORT "first-incredibly-long-filename-with-version-and-stuff.ff" AS first;
IMPORT "second-incredibly-long-filename-with-version-and-stuff.ff" AS second;
FORWARD first.msg_1; // references to msg_1 in first file
FORWARD second.msg_1; // references to msg_1 in second file
Unfortunately I don't see a easy way to achieve this with xtext.
At the moment I'm using a ID for the namespace qualifier and custom ProposalProvider/Validator classes,
which is ugly in detail and bypasses the EMF index, becoming slow with files of 1000 messages and 50000 attributes...
Would there be a right way to do it?
Was it a good idea to use xtext to parse the definition files in the first place?
I have two ideas what to check.
Xtext has a specific global scope provider called ImportedNameSpaceAwareScopeProvider. By using an overridden version of this, you could specify other headers to consider.
Check the implementation of the xtext grammar itself, as it supports such a feature with EPackage imports. I am not exactly sure, how it operates, but should work this way.
Finally, I ended up using the SimpleNamesFragment, ImportURIScopingFragment and a custom ScopeProvider derived from AbstractDeclarativeScopeProvider.
That way, I had to implement ScopeProvider methods for quiet a few rules but was much more flexible in using my "namespace prefix".
E.g. it is simple to implement syntaxes like
FORWARD FROM first: msg_01, msg_02;
In the zf2 database and models tutorial a path such as this leads to a directory containing my model classes:
module/Album/src/Album/Model
I have created two more classes at:
module/Album/src/Album/Model/AlbumRelatedClass.php
module/Album/src/Album/Model/AlbumRelatedTable.php
I would like to put these classes at
module/Album/src/AlbumRelated/Model/
I have created duplicates of the model classes there for the purposes of this test, unfortunately, my module config for Album tells me that it cannot find the classes at the AlbumRelated location. I have tried changing the namespaces in the AlbumRelated location to AlbumRelated\Model and directly referring to the class location (\Album\Model\AlbumRelated()) without success.
Does anyone know how I can do this? If I shouldn't be doing this, can somebody explain why? I'm also interested to know why the folder structure is Album/Model/Album (it seems redundant, and I wasn't clear on the explanation in the tutorial).
Any help given would be great, thanks :)
The short answer is that it can't find the class because you probably didn't set up the autoloader config to know about a new "AlbumRelated" namespace. Look at what happens in \Album\Module::getAutoloaderConfig(). You probably want to add a key/value pair to namespaces like 'AlbumRelated' => __DIR__ . '/src/AlbumRelated'. That will tell the autoloader where to look for classes under the AlbumRelated namespace.
That said,
If I shouldn't be doing this, can somebody explain why?
You probably shouldn't be doing it that way. You've got a top-level namespace called \Album. Then you have \Album\Model namespace under it. Any models related to Albums ought to live there. Imagine you had an entity in your system for Record Labels, so you could associate an Album with the label that released it. The ZF2 expectation is that you'd create a class called \Album\Model\RecordLabel that lived in module/Album/src/Album/Model/RecordLabel.php. As long as we assume that RecordLabels are primarily related to albums, that all makes perfect sense.
Of course, you could stick RecordLabel in it's own module as well, if you had a lot of workflow around managing them.
I'm also interested to know why the folder structure is Album/Model/Album
I assume you mean Album/src/Album. That redundancy is to keep a nice clean PSR-0 setup. So, the first Album is identifying the module, and the second is the top-level of the Album namespace. This provides maximum flexibility, but isn't a hard and fast rule. See Rob Allen's recent blog post about alternative module layouts in zf2 for an exploration.
Like the asker of the question here
Variable substitution JSF Resource Bundle property file
I'm slightly aghast at the inability to reference the value of other property keys in the message bundle.
Although I see how easy to write my own rubbish handler[0] that can do what I want in a custom component, that would leave expressions in templates calling the message bundle still using the default JSF implementation.
Is it possible to override the default JSF handling of the message bundle?
[0] Or better, to use code referenced in one of the answers to the above question
https://code.google.com/p/reflectiveresourcebundle/
You can provide the fully qualified name of a concrete ResourceBundle implementation as "base name" instead of alone the path and filename of the properties files.
E.g.
public class YourCustomResourceBundle extends ResourceBundle {
// ...
}
which can be registered as follows
<application>
<resource-bundle>
<base-name>com.example.YourCustomResourceBundle</base-name>
<var>text</var>
</resource-bundle>
</application>
or declared on a per-view/template basis as follows
<f:loadBundle baseName="com.example.YourCustomResourceBundle" var="text" />
Here are several related questions/answers which contain some concrete code which you could use as a kickoff example:
How to remove the surrounding ??? when message is not found in bundle
internationalization in JSF with ResourceBundle entries which are loaded from database
i18n with UTF-8 encoded properties files in JSF 2.0 appliaction
Everything is possible for those who try. The question is not whether it is is possible but should you do it. And the answer to that question is: probably not.
Referencing other message in a message bundle means you want to build a compound message. So you can re-use part of the message many times just to save small fraction of the disk space or small fraction of development time.
If that is the case, I have a message for you. What you plan to do is called a concatenation and it is the second most common I18n defect. And its implications are as bad as those of hardcoded strings.
Why? Because target languages do not follow the English grammar rules. First, it is common need to re-order the sentence while translating. This might be easy to fix by using (numbered or named) placeholders. On the other hand though, the translation might differ depending on the context. That is, it might need to be translated in totally other way, or simply the word endings might need to be different depending on a grammar case, mood or gender.
My advice is, do not use such shortcuts, it will create more problems than it fixes.
Now you should know why "those stupid Romans" didn't implement it like this: it is against I18n best practices.