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.
2 Comments
My goal for this week was to develop a simple API driven web application. I began by researching online to find a relevant tutorial that is not too complicated and is something I will be able to complete by the end of the week. I ended up finding a really good tutorial that provided a thorough walk-through. The application is used to obtain application icons. This is done by utilizing Apple Store's API to return the icon after users provide a link to the desired application. The tutorial walks you through the entire development life-cycle: Planning, Designing, and Building. I did not have access to the Sketch application that was used to create a mask to shape the output of the logo obtained from the API query, but I felt this portion was not essential to my desired learning outcome. Going through this tutorial was really fun and really answered many of the questions I had in regards to utilizing JSON. This tutorial also provided some really useful best practices when it came to the development and structuring of a Web Application. I learned some useful CSS tricks that involved displaying animated errors, and creating a responsive design. Also, in the Javascript portion of the tutorial, they introduce a simple implementation for form validation using regex matching that I can picture myself referencing in future projects. In the portion that involved connecting the API with Javascript, it was interesting to see how it required you to realize the structure of URL's in order to manipulate them into your queries. After completing this tutorial, I felt more comfortable with the process behind developing an API driven application. I know know how to locate publicly available API's, how there may be restrictions with the use of an API, and how to obtain the structure of an API so ontologies may be created to create linked data. I hope to take what I've learned and incorporate it into the application we plan on building.
|
CategoriesArchives
May 2016
|