I have an OWL file (OWL2) that I need to parse and ultimately write the data into some file. The file contains AnnotationProperties, DataProperties, ObjectProperties and Classes.
My first aim is to try to list out the property information as much as possible. i.e. for AnnotationProperties to see if I can print out the name of the property and the "value".
Similarly, to be able to display the class details i.e. for each class, the name of the class, the properties i.e. data or object properties of the class. I'm not sure how to do this and any reading I've done so far is confusing because it seems to talk about instances, which I don't believe are present in the file. Also, the OWLAPI javadoc and documentation and such are not very helpful with the kind of methods I might have to be calling.
E.g. if I had the following AnnotationProperty:
<owl:AnnotationProperty rdf:about="&xxx;SOME_ID">
<ABC rdf:datatype="xsd;string">1235412</ABC>
</owl:AnnotationProperty>
ontology.getAnnotationPropertiesInSignature() would get me a set of AnnotationProperties and I can iterate and say property.getIRI().getFragment() to see the SOME_ID, but now how would I obtain and display the inner contents i.e. the ABC-1235412 ? Similarly, any help on how to obtain the information of a class i.e. display or show its properties and restrictions is appreciated.
The fragment you're showing does not create an annotation assertion axiom with property SOME_ID, it is instead an annotation on the property SOME_ID itself. The triple looks like this:
SOME_ID ABC "1235412"^^xsd:int
From your description of what you're trying to do, you /need/ instances - values for any property (annotation, object or data property) are expressed through assertions, i.e., axioms which refer to an individual (or instance - the two names refer to the same concept).
E.g.,
Ignazio hasAge "38"^^xsd:int
would be a data or annotation property assertion on the individual Ignazio with value 38.
To access these assertions, you can use
OWLIndividual ignazio = ...
ontology.getAnnotationAssertionAxioms(ignazio);
To access annotations like the one you show, i.e., on the annotatio property itself:
OWLAnnotationProperty some_id = ...
ontology.getAnnotationAssertionAxioms(some_id.getIRI());
Related
I wonder if somebody has already met with a requirement to make a processing in Java depending on values defined in a .properties file and what would be the best approach to achieve that ? For example, a property file will have some key/value pairs like that:
file.input=csv
data.type=multi
data.separator=;
...etc
So in this case, depending on a property value(for example, 'csv'), I'll call CSV processing related classes, depending on 'data.type' value, I'll update the corresponding model values (e.g. class MultiCastXXX). The aim is to have something more or less generic like an API and be able to process no matter what is defined in a property file (of course with some conventions and restrictions applied). What do you think, any ideas ? Thank you.
Just another Java problem (I'm a noob, I know): is it possible to use dynamic property binding in a Custom Control with a dynamic property getter in a Java bean?
I'll explain. I use this feature extensively in my Custom Controls:
<xp:inputTextarea id="DF_TiersM">
<xp:this.value><![CDATA[#{compositeData.dataSource[compositeData.fieldName]}]]></xp:this.value>
This is used in a control where both datasource and the name of the field are passed as parameters. This works, so far so good.
Now, in some cases, the datasource is a managed bean. When the above lines are interpreted, apparently code is generated to get or set the value of ... something. But what exactly?
I get this error: Error getting property 'SomeField' from bean of type com.sjef.AnyRecord which I guess is correct for there is no public getSomeField() in my bean. All properties are defined dynamically in the bean.
So how can I make XPages read the properties? Is there a universal getter (and setter) that allows me to use the name of a property as a parameter instead of the inclusion in a fixed method name? If XPages doesn't find getSomeField(), will it try something else instead, e.g. just get(String name) or so?
As always: I really appreciate your help and answers!
The way the binding works depends on whether or not your Java object implements a supported interface. If it doesn't (if it's just some random Java object), then any properties are treated as "bean-style" names, so that, if you want to call ".getSomeField()", then the binding would be like "#{obj.someField}" (or "#{obj['someField']}", or so forth).
If you want it to fall back to a common method, that's a job for either the DataObject or Map interfaces - Map is larger to implement, but is more standard (and you could inherit from AbstractMap if applicable), while DataObject is basically an XPages-ism but one I'm a big fan of (for reference, document data sources are DataObjects). Be warned, though: if you implement one of those, EL will only bind to the get or getValue method and will ignore normal setters and getters. If you want to use those when present, you'll have to write reflection code to do that (I recommend using Apache BeanUtils).
I have a post describing this in more detail on my blog: https://frostillic.us/f.nsf/posts/expanding-your-use-of-el-%28part-1%29
So let's say you have a class called Human, and a bunch of other classes that all extend Human (John, Sally, Mark). Human has an annotation "#Tags({"human"})", John has annotation "#Tags({"john"})", etc.. All classes have their corresponding tags.
My question is: how can I use these tags to figure out which object to make?
So like, a user will input either "john" "sally" or "mark" and I want to make that corresponding object...
Look at the Strategy Pattern:
a software design pattern, whereby an algorithm's behaviour can be selected at runtime
You could use this pattern to match input to a factory or as part of an enum that maps the name to a given class type (though there are several "hard-coding" issues with this approach).
As for construction of object instances, I recommend you also look at the Factory Pattern and combine the two to create these objects in an abstract manner.
I also recommend you don't tag your objects lik this, as you're hard-coding user input expectations against your codebase. At least externalise such expectations to a configuration file (.properties or .xml) so the mappings of input can change independently of the code.
I had faced similar requirements in a Project.
This is what I did,
Design a strategy to read the Class(s) : This is required because the classes are not referenced in any of your code directly. Hence these classes wont be processed by any ClassLoader automatically. Load class dynamically using Class.forName()
Generate a Factory : Make the scope of your annotation as Runtime. This will allow you to process the class files that you have read and extract your custom annotation value out of it. Then you can register the name of this class against the annotation in the factory class.
Use the factory to generate the Objects : Now you have a factory which can return the objects of your class when you pass a tag name. Use reflection to create a Object.
To know more about factory pattern please refer the link : Factory Pattern
I have a class like
class A {
private String property1;
private String property2;
private String property3;
// constructor , getters , setters
}
it is possible to get a list/array of the names of properties of this class in the order they appear in the source file ? like ["property1", "property2", "property3"]
The answer is that you can't. The information you require is not available at runtime from the .class files.
In some other parts of my code i need to "print" the data of this class in certain order. This class in the real case has a lot of properties and can change (as the order) so, i can write this array/list by myself to get the order i need but if it is possible to get it from the class it would be better for me.
Here are some better ways to solve this problem:
Sort the properties before printing, by name or by type name, or something that makes sense.
Embed an array in the bean class (or another class) that defines the bean property order.
Create a separate metadata file that specifies the bean property order.
You could do some build time pre-processing of your source code to extract the order of the properties and (say) write them to a file. But frankly, I think it is better to detach these aspects; e.g. so that your system integrators / end-users could tweak the property order without changing the source code.
This is not precisely possible. Class#getDeclaredFields makes no guarantee about the ordering of the fields returned. However, in the test I just conducted, the fields were indeed returned in their declaration order.
it is possible to get a list/array of the names of properties of this class
Yes, using Class.getDeclaredFields()
in the order they appear in the source file
No, not with any kind of guarantee unless you parse the source file.
I'm working with three separate classes: Group, Segment and Field. Each group is a collection of one or more segments, and each segment is a collection of one or more fields. There are different types of fields that subclass the Field base class. There are also different types of segments that are all subclasses of the Segment base class. The subclasses define the types of fields expected in the segment. In any segment, some of the fields defined must have values inputted, while some can be left out. I'm not sure where to store this metadata (whether a given field in a segment is optional or mandatory.)
What is the most clean way to store this metadata?
I'm not sure you are giving enough information about the complete application to get the best answer. However here are some possible approaches:
Define an isValid() method in your base class, which by default returns true. In your subclasses, you can code specific logic for each Segment or FieldType to return false if any requirements are missing. If you want to report an error message to say which fields are missing, you could add a List argument to the isValid method to allow each type to report the list of missing values.
Use Annotations (as AlexR said above).
The benefit of the above 2 approaches is that meta data is within the code, tied directly to the objects that require it. The disadvantage is that if you want to change the required fields, you will need to update the code and deploy a new build.
If you need something which can be changed on the fly, then Gangus suggestion of Xml is a good start, because your application could reload the Xml definition at run-time and produce different validation results.
I think, the best placement for such data will be normal XML file. And for work with such data the best structure will be also XMLDOM with XPATH. Work with classes will be too complicated.
Since java 5 is released this kind of metadata can be stored using annotations. Define your own annotation #MandatoryField and mark all mandatory fields with it. Then you can discover object field-by-field using reflection and check whether not initiated fields are mandatory and throw exception in this case.