I am developing a demo of semantic web-based Information System, which just uses SPARQL instead of traditional SQL to manipulate dataset. How the application can demonstrate Semantic Web benefits.
I did steps as below:
The client gets parameters from web UI.
Requests a web service.
The service generates a SPARQL command according to given parameters.
The service uses Jena/SDB API to execute the SPARQL command.
Retrieves or persists data from or to MySQL.
Parsing returned result set.
Responses a JSON object to the client.
The client uses Javascript + html to display data.
Currently, the application just has CRUD operations. Only one difference to the traditional IS, which is using SPARQL instead of SQL. It seems that cannot see obviously semantic features. I'm just thinking of two points:
To demonstrate data federating through SPARQL. From this point, can I imagine that the system can be broken down into several subsystem and work on their independent dataset but they can communicate with each other by SPARQL, which because they work on the RDF specification.
Reasoning over datasets. I use Ontologies to describe data schema, should my reasoning operation need to based on them. In my application, I try to get a RDF model, and use Pellet to do inferences. Is that corrent way?
Basically, if the application can demostrate data federating and reasoning, which can be seen as a semantic web-based application. Do I understand it right?
Hopefully, the application can combine services together automatically through semantic description. Furthermore, any other third party data sources may be communicate with the system and work immediately.
Yes ,you are right.the benefit with semantic web being you can write separate set of ontologies which will describe the domains(e.g. product,user) and then combine them using inference ,reasoning and make the data seem much more useful(r.g. product types and user preferences).
The difference being the rules for the data are now written with the data and not in the business logic layer.
Hope this helps .:)
Related
I am trying to build a federated RDF application based on rdf4j and FedX. What I need is to be able to:
Optimize the querying plan and joining strategies.
To expose different and heterogeneous databases (A timeseries or a relational DB for example) in a federated fashion.
I went a little bit through the rdf4j documentation and I got a grasp. And therefore I have some little questions:
Is there any documentation that explains how to implement the SAIL API? I tried to debug and follow the flow of execution of an example query using a RDF memory store and I got lost.
Suppose I want to expose a relational database in my datacenter, Should I implement a SPARQL repository or an HTTP repository? should I in anyway implement the SAIL api?
Concerning fedX, how can I make it possible to use the SERVICE and VALUES terms as proposed in the SPARQL 1.1 federated queries? How can I change the Joning strategies? the query plan?
I know that this can be answered if I dive deeply into the code but I wonder if someone has already exposed some kind of a database using the rdf4j API or even worked and tuned RDF4J.
Thanks to you all!
Is there any documentation that explains how to implement the SAIL API? I tried to debug and follow the flow of execution of an example
query using a RDF memory store and I got lost.
There is a basic design draft but it's incomplete. A more comprehensive HowTo has been in the planning for a while but it never quite gets the priority it needs.
That said, I don't think you need to implement your own SAIL for what you have in mind. There's plenty of existing implementations that can do what you need.
Suppose I want to expose a relational database in my datacenter, Should I implement a SPARQL repository or an HTTP repository?
I don't understand the question. HTTPRepository is a client-side proxy for an RDF4J Server. SPARQLRepository is a client-side proxy for a (non-RDF4J) SPARQL endpoint. Neither has anything to do with relational database.
should I in anyway implement the SAIL api?
It depends on your use case, but I doubt it - at least not right at the outset. I'd probably use an existing R2RML library that is compatible with RDF4J, like for example the R2RML API, or CARML - either a live mapping or an offline batch mapping between the relational data and your triplestore may solve your problem.
Concerning fedX, how can I make it possible to use the SERVICE and VALUES terms as proposed in the SPARQL 1.1 federated queries?
You don't need to "make it possible" to do that, FedX supports this out of the box.
How can I change the Joning strategies? the query plan?
You can't (at least not easily), nor should you want to. Quite a lot of research and development went into RDF4J's and FedX query planning strategies. I'm not saying either is perfect, but you're unlikely to do better.
Hi everyone I’m new to server-side technologies so maybe this is a bit of a dumb question but after reading dozens of articles and viewing dozens of videos I’m still very confused. This has to do with arquitecture principles of modern apps.
Relational model:
I know that a few years ago the model was to have a database (mostly relational) and a DBMS that enabled the connection between an app and the database.
Question 1: Since we are talking about a relational model some examples of DBMS’s are MySQL or PostgreSQL?
Question 2: What is the process of information exchange? The client-side uses a language like PHP to make a request to the server and then the DBMS transforms the request into SQL and accesses the database? Is the conversion of the PHP into SQL part of DBMS function or another server-side software is needed?
(If someone could provide me summary detailed explanation I would be very thankful)
Non-Relational Models:
Question 2: Nowadays with the rise of NoSQL models does the same concept of DBMS apply? Since these systems allow other querying language other than SQL there should be some piece of software that has this function?
Service Oriented Arquitecture:
Almost every app uses this type of arquitecture. I understand the concept of avoid the creation of too tight software relation between client and server side allowing for multiple use across several platforms. What I don’t understand is what parts constitute a system that is build this way.
Question 3: Does the DBMS provides the API’s that constitute the web services made available?
Web Frameworks:
Last but not least, where do frameworks like Django or Ruby on Rails land on?
Question 4: These are supposed to provide tools to develop everything between the front-end and the database of a SOA system right?
Question 5: I’ve seen a lot of buzz about REST arquitecture. Can you explain me of the querying process happens and what are the software entities involved.
Thank you in advance for any explanation that helps me understating these questions. Please provide some links or any diagrams that you find useful.
EDIT:
I'll tackle your questions individually:
Question 1: Since we are talking about a relational model some examples of DBMS’s are MySQL or PostgreSQL?
Correct. The Database Management System is the suite of software that lets you interact with a particular database technology. The examples you give are correct.
Question 2: What is the process of information exchange? The client-side uses a language like PHP to make a request to the server and then the DBMS transforms the request into SQL and accesses the database? Is the conversion of the PHP into SQL part of DBMS function or another server-side software is needed?
There are many different avenues for this. Typically the API for accessing a database is done via ODBC (Open Database Connectivity). ODBC drivers are available for most (if not all) Relational DB vendors and are all very similar.
A language like PHP could connect to the database via an ODBC connection library (eg http://php.net/manual/en/intro.uodbc.php) which would allow you to send CRUD operations to the DBMS to be executed on the database.
Since most DBMS's use a subset or superset of a SQL standard for querying the database you can either pass this code directly via ODBC or you may use another level of abstraction. A common method is called an ORM (Object Relational Mapper). ORMs (eg SQLAlcmehy for Python: http://www.sqlalchemy.org/) provides an abstraction layer so you're not reliant on writing SQL but instead write queries and database commands in a format more common of your language of choice.
Question 2: Nowadays with the rise of NoSQL models does the same concept of DBMS apply? Since these systems allow other querying language other than SQL there should be some piece of software that has this function?
Same general concept (in that there is a DB Driver that exposes an API that languages can hook into) but there are generally more and differing ways of interacting with DB's now since they have many differing structures. Most NoSQL DBs still have ODBC connectors (eg MongoDB and Hadoop) so the general programming practices still apply whilst connecting with them, but the things you expect the database to do (and their natural query languages) will differ.
This continues to be an evolving space as these technologies evolve.
Question 3: Does the DBMS provides the API’s that constitute the web services made available?
Not sure I'm understanding this question. ODBC and webservices are different. Often webservices sit on top of ODBC if you want to query a database via a web API, but it's one layer of abstraction more than connecting to the DB directly via ODBC.
Last but not least, where do frameworks like Django or Ruby on Rails land on?
Web Frameworks are a way of quickening the development of web applications by trying to stop some of the "reinvent the wheel" things that you commonly do with every web application. They give you the basics, and have a lot of extensions that allow you to implement other common elements of web apps (like a subscription/login system, session management, admin system etc).
These are supposed to provide tools to develop everything between the front-end and the database of a SOA system right?
Both Django and RoR aim to be end-to-end frameworks. They include all the common elements you'll need including an Object Relational Mapper. They don't prescribe which DBMS you have to use, their ORMs can interface with many so that choice is still up to you.
Yes, they are aimed to cover everything from the front end to the DB, including the interaction with and initialization of the structure of the database.
Question 5: I’ve seen a lot of buzz about REST arquitecture. Can you explain me of the querying process happens and what are the software entities involved.
REST stands for Representational State Transfer (quick Wikipedia article: https://en.wikipedia.org/wiki/Representational_state_transfer). In a nutshell the creation of a "RESTful" (REST compliant) web API would mean that you have GET, PUT, POST and DELETE methods to accomplish all your services. REST aligns closely with the HTTP protocol which is why it's been very appropriate for the ever growing concept of Web Apps, it's helped transform the thinking from a Web Page (or set of web pages) into Web Apps.
It's hard to sum up better than the Wikipedia article does, I'd suggest you dive into it.
Hope that's cleared up a few of the questions!
I am looking at OData and it is very powerful, at the same time it's very disconcerting. It is the equivalent of exposing your datasource to a remote user. There is no service nothing nada and very little injection points, resulting in an almost comical 2-tier architecture.
My concerns are:
It's hard to enforce pattern such as DDD while using OData.
It is also hard to use OData against a set of soa Data Transfer Objects, because these are not usually queryable. ie.by the time you get the DTOs, the DB query is done, but OData is just starting up. There is not a lot of value in querying against it, because the DTOs are already in memory.
I can create a view on the DB itself that's a representation of the OData entity, but this is putting UI concern in persistence. Big no-no.
At best combining the result set from various DDD services now happens at the UI layer using kludgy javascipt - a maintainance nightmare with poor reuseability record.
Another possibility is to write a translator for the OData entity which is likely a ViewModel level class, that then translates to the DTOs, that then translates to Domains, that then translates to the ConceptualModels, the rest the ORM can handle. But this will require an inordinate amount of resources.
In short, how do you make OData play nice with SOA, OO encapsulation principles, DDD and just good old SOC?
There needs to be clear separation of the OData standard and the OData implementations.
As for the standard:
The standard itself to my view lets you to have an OOTB accessible data endpoint with full metadata on a portable manner. With support for relations and projection consumers can compose viewmodels on the server or later on the client. It is important to note, that OData supports operations (functions) to be exposed, so on the top of automatic crud you can have remote methods that seamlessly integrate into the relational pattern (functions can have results that you can further query, still on the server, and also functions can act as the "smart writer" code).
To wrap it up: OData gives a shape to what actually happens most of the time when someone needs massive REST compliant data access: formalizes common, always repeated scenarios like how it is to query for data or submit data back. This might be still affected by what you write at point 4, but to my opinion it's not an OData related issue. This is simply how AJAX and Mashups work: you'll have a client with lots of code dealing with combining data.
Other issues of yours can be answered with selecting the most appropriate server implementation. There are a couple of implementations already:
EF4/EF5 + WCF Data Services being the most "automatic". In this use case you might just be correct regarding some of your concerns but: with the fine extensibility model of EF you can interact with the automatic operations as you wish. Having an application that is driven by the actual EDMX model is a true DDD scenario.
ASP.NET Web API let's you have a totally code based back-end for what you perceive as a static, relational endpoint, so this is where you can think in 3 layers: DB, middle tier to bridge between DB data and to what is best for the clients, and client tier as a smart consumer to that model.
JayData provides these in Server Side JavaScript with the added dynamism of JavaScript.
SAP NetWeaver gateway exposes complex SAP data on a manner easy to consume for simple scenarios.
OO concerns:
With V3 of OData we have now "instance methods" (that are definitely server methods too) so what actually SOA took away with brutally separating things to data and functionality OData really gives back: defining functionality + data encapsulated but in mapped to the SOA concept of static methods with context data that act like the "this".
2Tier concerns:
IMHO 2Tier architectures became "ancient" not because the client has too much knowledge about the server side structure, but because they did not scale well and the new thin cliens were to dumb to act like a real DB client. In fact 2tier was always easier to work with (from a developer point of view), and now that actually OData server implementations are indeed middle tier with logic, you actually can get the best of both worlds:
- code agains a virtuall 2 tier architecture
- and scale as a normal n tier application can.
I'm having a hard time wrapping my mind around something and would appreciate some reading material on this concept.
I'm writing an application that relies heavily on providing API calls via a URI scheme. example.com/company/user/123123. The aspects of taking a URI string and converting it to an action makes sense.
But where I get confused is taking that process and utilizing within the MVC structure. Do I build calls using models or a library? My goal is to be able to do something like $this->company->user(12311), so that I can have the API functionality available externally and internally.
Also how do I make this functionality accessible without exposing core code?
One of the biggest problems with the word API is that it does not make a distinction between when you are making local in process calls and when you are making remote calls. This is the essence of the RPC style, using the same programmatic model regardless of where the code to be executed exists.
REST is explicitly about doing distributed computing and is optimized for those scenarios. Trying to use a RESTful interface as a local API is likely to produce something that is highly inefficient.
I would suggest not trying to use the same API internally and externally and I would go further and say try not to think of REST as a way of building APIs. REST is an approach to building distributed systems that requires consideration of the system holistically.
To address your question more specifically, I use an MVC approach to exposing Resources in my system. The Model is the Resource and the View is the Representation. The key to building a RESTful system is to identify the links between your models. These links are rendered into the respresentations as embedded links. Also, consider that your models should be more like Presentation Models than domain models as a RESTful interface is more about exposing the usage scenarios of a system than it is about exposing a domain model.
Using VB.NET 2008
I want to know what is 3 Tier Architecture for windows application?
Can any one give a example of How to make a code for Inserting, Deleting, Updating in a database using 3 tier architecture.
Note am not asking a real code. Just give me a example.
From Multitier architecture
Three-tier'[2] is a client-server
architecture in which the user
interface, functional process logic
("business rules"), computer data
storage and data access are developed
and maintained as independent modules,
most often on separate platforms.
These days, a normal 3 tier application consists of a user interface written in Javascript, CSS and HTML which runs in the browser, a business rules layer which runs in a web server, and could indeed be built in VB.NET, and a storage layer which runs on a database server written in SQL and stored procedures.
Now it would be possible to do a user interface layer in VB.NET as a Windows application which then calls the business rules layer on the web server using a web services interface. This would give you more flexibility than the browser, and would not require learning as many APIs, however it is not common. It can really only be done in an enterprise situation.
This article has a simple VB.NET application that is a Windows GUI app, which call Google's web services API to do searches and to check spelling. That is a good example of a user interface layer. Then check this article for and exmple of a web service developed in VB.NET. This corresponds to the business rules layer, and in a real 3-tier application, it would be based around a database such as SQL server. If you were to use Access then it would not be a real 3-tier application. The database needs to be run on its own server and accessed across the network in order to be considered a tier.
The advantage of a 3-tier application is that you can scale each layer separately, and because each layer is simpler, scaling is also simpler. The DBAs can scale up to a database cluster, the business rules layer can scale up with a load-balancer and multiple servers, and the user-interface just gets replicated across as many clients as you need.
I don't know if is it the right way to use it, but I often use 3-tier int the following way:
One big Solution, with the name of the project
One dll project wich has the conection with the DB, using LINQ or whathever. Validating only the required fields of the DB
Another DLL project, wich has a reference to the project that conects to DB, and validate all data using the bussiness rules. Sometimes you may want a repositorium class wich has methods that can be used from the GUI layer
Finally, the GUI layer that can be HTML or WINForms, wich references to the bussines layer and calls all the appropiates methods, passing the data transparently and waiting for validation on the bussines rules.
You can comunicate with each layer using bool methods that returns true if everything is good, and personalized exceptions for each of the possible errors, and catch them on the upper layer.
I'll give you the gist of it. Real crash course.
You have three tiers:
DAL - Data Access Layer
BRL - Business Rule Layer
Presentation - The Forms, and such.
In the DAL, you configure how your application connects to databases, how it recieves datasets, etc. etc. Everything that has to do with data access.
In the BRL, you lay down how your program is going to handle the data it recieves from the DAL. Methods, and other things go in here.
And in the Presentation area, you simply make things purty and instantiate things from the BRL. The presentation area never has to touch the DAL, and that's the beauty of the 3tier layout. You can work on different areas and not step on other peoples toes.
I find the best way to understand it is to look at an example. If you go here:
http://www.codeproject.com/KB/vb/N-Tier_Application_VB.aspx
You can download an example and read the walk through for creating a very basic 3 Tier App in VB.Net. It's a little old in that it's a Visual Studio 2003 project but it should be easy enough to follow the upgrade wizard and get it up and running to check it out.
I'd like to give a brief overview about this style of programming and maybe I'll explain it in more details next time.
First of all, the 3-Tire concept engages dividing your program or application you are designing into 3 layers, the first layer is for manipulating the database in the operation called CRUD which stands for {Create,Read,Update,Delete} data from your database, using any kind of Databases : for example Oracle,SQLserver,MySql etc. That means you can connect your application with any type of databases without specifying a connection String to Only one database and we'll get more details about this next time.
The Second layer is Business layer which includes user data verification and other similar operations in which you process your business rules and the core of program,
The Third and Last layer is the Presentation layer which relates to User input and UI User Interfaces {The different forms for Input}
Frankly you can divide your Solution {Program,Application,Website} to sub-Programs to avoid data loss,organize your work, and to divide the development of your application among a team members.
in my point of view this is a great thing should be learnt in development, and as I was told by the grapeVine, if you want to enrich your knowledge and experience then you should be acknowledged about this important subject.