There seem to be a lot of resources on using Virtuoso with Jena thanks to the availability of the virt-jena. I wonder if there is an existing binding of virtuoso with owl api.
I know that a jena model can be used to create OwlOntology, but that makes things redundant (having to use both jena and owl api codes in my application). So, my question is can virtuoso be accessed using owl api only? Is there some driver to do this?
Thanks.
Not at present. We (owl api) are working on adding commons rdf support, but it's not possible at this time.
Related
I have used OData in my career quite a bit and now few of my colleagues from different teams recommended we move to JsonAPI and GraphQL as its not tied to Microsoft. I don't have much experience in both these query languages. As far as i know OData is a standard used by Salesforce, IBM, Microsoft and it is very mature. Why should one switch to JsonAPI and/or GraphQL? Is there a real benefit? Is JsonAPI and GraphQL new standard? Changing public api implementations based on popularity seems useless especially when there is no big benefit.
Can someone please enlighten me?
OData is a similar specification to JSON API. Both of them describe a standard protocol for creation and consumption of RESTful APIs. GraphQL is a totally different approach to API design and specifies a different way of querying API resources.
OData: Designed and developed at Microsoft since 2007, standardized by the OASIS consortium. The latest version V4 is submitted to ISO/IEC JTC 1 for approval as an international standard. Companies on the technical committee (TC) include CA Technologies, Citrix, IBM, Microsoft, Progress, Red Hat, SAP and SDL.
There are a number of libraries for popular programming languages - .NET, Java, JavaScript, PHP and Ruby. The spec allows dynamic resources and there's a service document which lists all API endpoints for clients to discover. Additionally, there's a metadata document describing the schema.
JSON API: JSON API was originally drafted by Yehuda Katz in May 2013. This first draft was extracted from the JSON transport implicitly defined by Ember Data’s REST adapter. The current stable version of the spec is 1.0. The JSON API spec is implemented for the majority of programming languages, for both the client and server sides.
JSON API supports HATEOAS through the link property in the JSON document. Other features include pagination, sorting, filtering and relationships. The JSON documents produced by JSON API servers are very verbose with lots of nested properties.
GraphQL: Developed at Facebook since 2015. The specification is still a working draft. It's quite popular among React fans and is mainly used in combination with React or Vue.js. Similar to GraphQL is Falcor, which is also relatively new.
While GraphQL makes use of HTTP, it is not considered REST, rather, an alternative to REST. Instead it makes use of a query/response model into a single (virtual) JSON document. This new model is somewhat nicer for developers to work with, but its benefits over REST are debatable. Given its young age, the ecosystem has yet to mature.
For the sake of clarity and completeness, I’ll include OpenAPI to the list, although it is not exactly an API specification. That can be confusing to some people. The OpenAPI standard is a language-agnostic standard for describing and defining APIs. Your API can follow one of the above standards (excluding GraphQL) and also be documented using OpenAPI 3, for example.
OpenAPI (a.k.a. Swagger): Developed as part of the OpenAPI Initiative and the Linux Foundation. Supported by big tech companies like Google, Microsoft, IBM, SAP, Oracle, Ebay and PayPal. The current version of the spec is 3.1.0. There are implementations for the majority of programming languages, as well as lots of additional tools like web UI generators, etc.
The best thing you get with specs like OpenAPI is the tooling around them - generators for API documentation pages, generators for client SDK code, etc.
This standard is probably the most commonly used today for API declaration, documentation and code generation. It is also supported by cloud providers like Amazon Web Services in their API Gateway.
In summary, OData and JSON API are both JSON data formats which add context and features (e.g. links) around your data, GraphQL is a totally different new way to query and mutate JSON data, and OpenAPI is the standard way to declare and document any RESTful API.
My personal opinion:
As you can see, there are quite a few RESTful specs out there, rather than a single universal standard. I agree with xumix here - they all seem to suffer from the "Not Invented Here" syndrome. The benefits of choosing any of the above are small, especially if your project is small or medium sized.
Does it matter which specification your API implements? Probably not much. Just focus on building a consistent and well-documented API.
I'm playing around with Neo4j community edition, with Neo4jClient for .net, and looking for a way to use the great Miniprofiler for the calls to the Neo4j DB.
I'm using the miniprofiler on some other projects with SQL Server and Entity Framework and getting wonderful insights about the queries sent to the DB. Wondering if I can get the same with Neo4j and Cypher queries.
The answer is No and Maybe.
No, as it doesn't exist at the moment.
Maybe as you could either have a stab at writing it yourself, or add it as a feature request to the Neo4jClient GitHub page and we can have a look about doing it in the future, but obvs it comes after bolt and a few other things.
How can Breeze JS be used to consume a pure, simple, plain old RESTful API? Consider a web api endpoint that does not support OData and does not have Microsoft Entity Framework as the OR/M layer.
I see there's this Edmund's sample here, but I would like it to be more specific on how to manually setup BreezeJS metadata, since from what I understand about not having OData support is the fact that you lose out-of-the-box metadata resolution for the model consumed from an api endpoint. I quote from this Edmund example:
we have not yet described the Metadata Definition API properly. We ask that you rely on your intuition as you read this code ... your intuition will usually be correct. Please post questions to StackOveflow tagged with "breeze".
Is there any source of information on this topic that leaves intuition aside?
That Edmunds sample is so old, it pre-dates any of the documentation on how to write metadata.
Take a look at the Metadata by Hand topic in the BreezeJS documentation.
Im new to breeze js, I understand that breeze has it's own query language related to OData
But I am trying to get breeze js working with a custom query language, as an example FIQL is
one of the form to make queries to backend, can we get breeze run with this type of query language.
Overview of FIQL :-
http://jaxenter.com/tutorial-smarter-search-with-fiql-and-apache-cxf-46876.html
(this is not a technical answer, at the very most it's an advice)
As mentionned from their website documentation :
Today, out of the box, the Breeze product ships with adapters for the
ASP.NET Web API and for OData. It also ships with .NET components that
interface with the Entity Framework and that generate Breeze metadata
from an Entity Framework model; that EF model could be developed code
first or database first. The Breeze client is in no way limited to
these technologies; they are merely the first backend components
available; we’d be thrilled to help you adapt Breeze to your preferred
server stack.
First question is whether
1) you want breeze to actually create FICL queries on the client and send them to a FICL service. This involves translating a client side breeze EntityQuery into FICL url syntax. If so you would need to create a new a 'uriBuilder' adapter.
2) you want to translate a breeze query already sent to your service into FIQL syntax on the server so that you can further refine the query and then send it on to your FICL service. If so you would need to create a breeze DataService endpoint.
Both of these are certainly possible.
If you are looking at the 1st option, take a look at the 'b000_uriBuilder.xxx' files in the breeze GitHub repo under the 'src' directory. There should be two 'uriBuilder.xxx' files, one which translates an EntityQuery into OData syntax and another that translates the EntityQuery into a new 'json' query syntax. There is also additional information on this 2nd syntax here:
http://www.getbreezenow.com/documentation/query-using-json
Both of these 'uriBuilder's make use an internal 'visitor' framework that we have not yet documented but should be reasonably understandable by looking at the source.
If you are looking at the 2nd option, I would recommend looking at the link mentioned above and then taking a look at the 'breeze.node.js' repo and the 'breeze-sequelize' subdir within it. In this repo we take a serialized server side breeze EntityQuery and translate it into a 'Node' Sequelize query that we can apply to a variety of backends.
Another option is to contact our professional services arm, at breeze#ideablade.com and ask them to assist in building the adapters for you or to ask for more detailed technical help.
I am at a new company and one of our goals is to implement a document search portal for our team and our clients. I am a bit worried that if we use an external service provider like Salesforce or some other ECM in the cloud there will be a lot of integration work in the future. From a client perspective, these documents will also exist in the same bucket as our structured content (stored in the DB, not a MS Word doc).
If you have implemented document searching, what languages, frameworks, and technologies have you used? Do you have any failure stories? I don't have a problem using something out of the box, but I think it is important that we have control over the documents and the API to access them. I would like to use Rails if we go fully custom.
Depending on your licensing needs Lucene (LGPL) and Xapian (GPL) both are great, mature, fast search engine API's with bindings for a lot of languages. I've used both of them with great success.
Lucene is probably the safest choice because it is widely used and quite good.
The easiest way to benefit from Lucene is probably with Alfresco, which is a breeze to install, and has Lucene by default. It means you just need to install Alfresco, put your documents in the repository, and you can search for your documents using the powerful web search interface.
If you need to search programmatically, my recommendation is to use Alfresco' CMIS interface, which allows you to search in a REST way. The JCR API is also available.