To begin attempting to apply a context to our data I chose to take a sample of our stadium data. The current state of a stadium JSON object is as follows:
{ "Capacity": "30000", "Tenant": "Troy Trojans", "Type": "Football", "Stadium": "Veterans Memorial Stadium", "Location": { ... (google geocoder results) }, "Year opened": "1950" } In order to apply a context to this instance, I can do the following: { "@context" : { "Stadium": "http://schema.org/name", "capacity": "http://schema.org/additionalProperty", "Type": "http://schema.org/brand", "Tenant": "http://schema.org/additionalProperty", "Location": "http://schema.org/address", "Year opened": "http://schema.org/foundingDate", }, "Capacity": "30000", "Tenant": "Troy Trojans", "Type": "Football", "Stadium": "Veterans Memorial Stadium", "Location": { ... (google geocoder results) }, "Year opened": "1950" } To test if the context I provided was valid, I can use JSON-LD's playground site. There are still more properties to be added to make it more useful, but I feel this approach is unrealistic due to how time consuming it will be. This method will need to be applied to every instance, causing a lot of overhead. Also, If I decide to add or change the context, I will need to do so for every instance. This issue is similar to css styling. styles can be embedded into html, added to the header of the document, or it can be linked from an external css file. The latter approach is generally a best practice, because maintenance becomes simpler and quicker. A JSON-LD also has a similar approach to deal with this issue. A .jsonld context file can be created, then an instance can link to the file to apply the context. This approach reduces overhead, and allows for simpler maintenance. I was able to refine the context and create a jsonld context file: { "@context": { "name": "http://schema.org/name", "geo": "http://schema.org/geo", "address": "https://schema.org/address", "latitude": { "@id": "http://schema.org/latitude", "@type": "xsd:float" }, "longitude": { "@id": "http://schema.org/longitude", "@type": "xsd:float" }, "brand": "https://schema.org/brand", "foundingDate": { "@id": "https://schema.org/foundingDate", "@type": "xsd:int" }, "teams": "https://schema.org/additionalProperty", "capacity": { "@id": "https://schema.org/additionalProperty", "@type": "xsd:int" }, "xsd": "http://www.w3.org/2001/XMLSchema#" } } The issue was is figuring out where to host the file, so I can link to it. I decided to store it in our github repo. The most recent stadium context file can be found here. Now that the context file is hosted, I can re-write our instances as followed: { "name": "Veterans Memorial Stadium", "teams": "Troy Trojans", "foundingDate": "1950", "@context": "https://raw.githubusercontent.com/slopez15/ASU-CREU2016/master/JSON-Data/stadiums_context.jsonld", "brand": "Football", "address": "Veterans Memorial Stadium, Veterans Dr, Coffeyville, KS 67337, USA", "@type": "https://schema.org/StadiumOrArena", "geo": { "latitude": 37.0706651, "@type": "GeoCoordinates", "longitude": -95.6415231 }, "capacity": "30000" }
25 Comments
I was unable to complete any significant research this week. The time I did spend was researching JSON-LD's documentation on their site http://json-ld.org/. The examples they use in the documentation use a single instance of an object and is easy to understand,but my issue is we have to apply a context to multiple instances of pre-existing data. If I were to apply the concepts explained in the documentation, I will need to manually apply a context to every instance, which seems unrealistic. I will continue researching this issue through other resources.
The goal for this week was to convert our current JSON data to JSON-LD. I had watched some videos earlier in the semester that covered JSON-LD, and I had thought the process of converting JSON to JSON-LD would be quick and simple. I began researching JSON-LD's documentation to better understand how JSON-LD works. I found a really helpful resource that covers JSON-LD's syntax. After looking through this syntax, I realized this task would not be as simple as I thought. However, there is an aliasing feature that can allow me to map keywords in my current JSON documents to JSON-LD context keywords. I will need to test a subset of the data we have gathered to ensure I am able to successfully produce valid JSON-LD from pre-existing JSON data. I was not able to work on the conversions this week, because I spent a majority of my time building our Rails app. I had developed a Rails website for personal use, and I had already chose a cloud hosting service named Heroku for my personal site. Since I had the background knowledge of setting up a Rails app on Heroku, I chose to setup our Real Estate app the same way. I chose to Heroku's cloud hosting service, because it really makes managing and deploying apps easy (also, because they offer a free plan). I was able to build the skeleton for our web-app and deploy it via Heroku. Once the app was live, I began working on how we would manage our site. I connected the Github repo that houses our app to Heroku, and then setup automatic deployment. Anytime someone pushes to our master branch, the changes will automatically get deployed. Deploying this way is really useful for team oriented projects, because there is one central location for our source code. Heroku has it's own standalone client to manage your repo, but this can cause issues if Github and Heroku become out of sync. Also, I was able to setup Travis CI (Continuous Integration tool) to run tests before any changes to the code gets deployed. Since this is a Ruby on Rails app, it cannot be viewed locally in a browser like a standard html site. The only way to get a visual of any code changes was to deploy the changes. This is generally not good practice, because it's a live site. We need a way to test and view our local changes before deploying. To get around this issue, I was able to setup a development environment that allows you to run the rails server command that allows you to view the site the "localhost". I would like to add more Travis CI tests to run against any pushes to our master branch, but I am not familiar with the different tests for Ruby on Rails apps. This is not a priority, so I will look into this during my downtime. Now that we had the site up and running, and we now have a development environment, I decided to create a new branch to play with the design. I have been wanting to try out Google's material design framework, and this was a good opportunity to do so. I used the design prototype Julie put together as a source of inspiration for the layout. This framework allows you to easily create responsive websites that work across many device sizes through graceful degradation. The images below is what I currently have on the material-design branch. It is a basic responsive landing page. Once we finalize on a design, we can work on dynamically loading conent: Large Screen DisplayGraceful Degradation |
CategoriesArchives
May 2016
|