The goal for this week was to begin designing our ontology for our Real Estate Advisor application. Our hierarchy relies on our data sources and the data we will be able to obtain from them. The sources we decided on were ones that provided open web APIs. We have yet to receive keys for all of our sources, so our ontology is still a work-in-progress. I was able to get it started by creating a class hierarchy for our application (see attached). We will wait to add properties and restrictions until we find out exactly what types of data we will be able to utilize from our sources. Some questions that arose while building the ontology.
One question was if the naming conventions of properties. Schema.org has predefined property values for the classes they have listed in their ontology, but what if we want to create a new property? How would that translate for others that may end up referencing our data sets in the future?
The main question was how and where in the implementation process of developing the application will we actually use our ontology? This lead to me researching online to learn how linked data applications have been created. I came across a video series titles the Euclid Project. I really learned a lot through this series and it answered a lot of questions I had, and filled in the gaps as far as my understandings on how linked data applications are built. I learned that the application we are developing can be referred to as a Domain-Specific Web Application, because the data is geared towards a specific use.
The talk in the series goes into detail about the different types of Software Architectures for linked data applications. These architectures were designed to prevent a coupled design which will allow applications to be expanded in the future, if needed, and promote re-usability. One architecture type he discusses is the general three-tiered architecture (Which is something I believe we should implement). The three-tiered architecture consists of the following layers: Presentation Tier, Logic Tier, and the Data Tier. The Presentation tier houses the GUI code for the application. The Logic Tier is where data is intelligently managed between the Presentation and Data tiers; this process is also referred to as Business Logic. Lastly, the Data Tier houses our triple store. The idea of a triple store is what sets linked data applications from other applications. The triple store is generated by obtaining data from external sources, mapping it to our predefined ontology, which forms our triples, then it is stored into our database in its tripled form (hence the name "triple store"). The scripts that are written in our logic tier will query our triple store in a way that will take advantage of the properties that are used to describe our data.