In OWL API, there method getObjectPropertiesInSignature() can be used to obtain the set of object properties in an ontology. I have two questions with respect to this:
By using this method, will it return also the object properties in imported ontology ?
Also, this method is deprecated in the latest version of OWL API, is there another method with the same behaviour ?
getObjectPropertiesInSignature() has an overloaded version with a boolean flag, its purpose is to allow you to choose to look in the signature of the ontology or in the signature of the imports closure. Use it to get the object properties for the whole imports closure.
The method is deprecated and the javadoc suggests using the stream based method. For all such scenarios in OWLAPI 5, methods named getXxx() have an alternative version named xxx() that returns a stream. It is preferable to use them if you need only one iteration through the underlying collection (it saves having to make defensive copies). If you need multiple iterations or lookups, you can keep using the deprecated methods or collect the data from the stream in a set.
Related
I Am working with flink 1.15.2, should i use Row or GenericRowData that inherit RowData for my own data type?, i mostly use streaming api.
Thanks.
Sig.
In general the DataStream API is very flexible when it comes to record types. POJO types might be the most convenient ones. Basically any Java class can be used but you need to check which TypeInformation is extracted via reflection. Sometimes it is necessary to manually overwrite it.
For Row you will always have to provide the types manually as reflection cannot do much based on class signatures.
GenericRowData should be avoided, it is rather an internal class with many caveats (strings must be StringData and array handling is not straightforward). Also GenericRowData becomes BinaryRowData after deserialization. TLDR This type is meant for the SQL engine.
The docs are actually helpful here, I was confused too.
The section at the top titled "All Known Implementing Classes" lists all the implementations. RowData and GenericRowData are described as internal data structures. If you can use a POJO, then great. But if you need something that implements RowData, take a look at BinaryRowData, BoxedWrapperRowData, ColumnarRowData, NestedRowData, or any of the implementations there that aren't listed as internal.
I'm personally using NestedRowData to map a DataStream[Row] into a DataStream[RowData] and I'm not at all sure that's a good idea :) Especially since I can't seem to add a string attribute
I am working on a project using RDF data and I am thinking about implementing a data cleanup method which will run against an RDF triples dataset and flag triples which do not match a certain pattern, based on a custom ontology.
For example, I would like to enforce that class http://myontology/A must denote http://myontology/Busing the predicate http://myontology/denotes. Any instance of Class A which does not denote an instance of Class B should be flagged.
I am wondering if a tool such as the OWLReasoner from OWL-API would have the capability to accomplish something like this, if I designed a custom axiom for the Reasoner. I have reviewed the documentation here: http://owlcs.github.io/owlapi/apidocs_4/org/semanticweb/owlapi/reasoner/OWLReasoner.html
It seems to me that the methods available with the Reasoner might not be up for the purpose which I would like to use them for, but I'm wondering if anyone has experience using OWL-API for this purpose, or knows another tool which could do the trick.
Generally speaking, OWL reasoning is not well suited to finding information that's missing in the input and flagging it up: for example, if you create a class that asserts that an instance of A has exactly one denote relation to an instance of B, and have an instance of A that does not, under Open World assumption the reasoner will just assume that the missing statement is not available, not that you're in violation.
It would be possible to detect incorrect denote uses - if, instead of relating to an instance of B, the relation was to an instance of a class disjoint with B. But this seems a different use case than the one you're after.
You can implement code with the OWL API to do this check, but it likely wouldn't benefit from the ability to reason, and given that you're working at the RDF level I'd think an API like Apache Jena might actually work better for you (you won't need to worry if your input file is not OWL compliant, for example).
From reading the docs, and my experience using the 4 built-in collaborative types, these possible advantages come to mind:
If you prefer to have the realtime functionality mixed into your classes, rather than using composition (class contains a Collaborative* field; this is what I'm doing now).
Some of the usual advantages of constructors, with the initializer hook, to ensure that all objects of the class satisfy some property.
Some of the usual advantages of typed objects over untyped ones. It seems you cannot write to fields that you haven't registered, so no bugs caused by mistyping a CollaborativeMap key, or accidentally assigning to a key that was meant for a different CollaborativeMap of a different informal type. The latter has happened to me. If I understand correctly, one could preclude both such bugs statically when using Typescript or Flow.
The onLoaded hook. It's not clear to me why something like this isn't available for the built-in types. Can it be simulated for the built-in types?
The two functionally equivalent (a custom collaborative object is implemented as a CollaborativeMap under the hood), the primary difference is just in the syntax as you point out.
For the onLoaded hook, you can do similar work for built in types in the document onLoaded function.
I've been trying to find some info on difference between instantiating form fields through static method and the new keyword. Can somebody tell me what are the practical implications, limitations, between new MyFormField and MyFormField::create() esp. with regards to SilverStripe
Using the create factory method would check for overloads (set via Object::useCustomClass()) and return an instance of the custom class in that case.
This method first for strong class overloads (singletons & DB
interaction), then custom class overloads. If an overload is found, an
instance of this is returned rather than the original class. To
overload a class, use Object::useCustomClass()
So using the create method rather than instantiating the Object yourself would provide a possibility to overload the used Class without altering the code.
see
http://api.silverstripe.org/3.1/class-Object.html#_useCustomClass
http://api.silverstripe.org/3.1/class-Object.html#_create
What is the difference between using AuthComponent::allowedActions and AuthComponent::allow?
When I Google, I see the majority of examples and documents using or talking about allow(), but only a few using allowedActions. But they both seem similar in usage.
allowedActions is a property that contains a list of allowed actions.
allow() is a method that adds actions to the allowedActions property.
When you call the allow() method, it will merge the actions you specify with the actions already kept in allowedActions.
You can bypass the allow() method and assign an array of allowed actions to the allowedActions property directly, but I would only do that if I absolutely had to override any actions previously added (for example, by a parent class) to this property. The official documentation makes no reference to the allowedActions property.
In 2.x use:
$this->Components->disable('Security');