Point of Interest Repository
Introduction
Key Users of the information systems:
- System Architect – the person responsible for the system design of system, data entities, relationship and other technical aspect of the system
- Point of Interest Admin – Administrators who are responsible for maintaining and updating the affiliated resources (e.g., a hotel operator)
- Travellers – who will be browsers these resources and building their travel itinerary
- Future: Advertisers – who will be able to purchase advertisement or on relevant pages
I have implemented a simple prototype for storing Point of Interest data within WordPress. Reusing the data structure we have set up previously (pictured above), we will create the following entities (resources):
- Island
- Region
- Prefecture
- Point of Interest Type
- Point of Interest
All relationships are set to “One-to-Many” except for Point of Interest Type vs. Point of Interest, which is set to Many-to-Many”
The Point of Interest resource contains the following attributes
- Name in Japanese (Required)
- Name in English (Required)
- URL (Optional)
- Experience Address (Required; coordination)
- Images (Optional; repeatable)
I have also set up the appropriate relationship to the Prefecture and Point of Interest Type.
Data entry screen for the Point of Interest schema in the current system.
The 4 Major Islands of Japan. It acts as a classification and also a controlled vocabulary. (i.e., for the prefecture (parent-child relationship) screen below, the user is only able to choose from one of four values here.
The Prefecture configuration (Content Standard). The fields with an * are required fields. The ISO-3166-2 Code, Region, and Prefecture are examples of controlled vocabulary.
Reflection
Information System Improvement
- Enhance the geographic hierarchy by adding major cities into the database
- Realign the schema with the Place or touristAttraction schemas at schema.org
- Further enhance the entities to follow other relevant schema.org schemas such as Accommodation
- Create API endpoints to allow these entities to be consumed via JSON
- Add trip-planning capability; activities on the trip (e.g., hotel stay or dinner reservation, etc.) are essentially events in Calendar with Person, Place, and Date Time information
Technology Next Steps
- The model will be migrated to a Python (fast-api) infrastructure with a flutter front-end in the future
- Internationalization will be set up differently; instead of storing the Japanese and English name as a same record, a language look-up with proper internationalization support will be used instead
- The proper language will be auto-detected by user’s browser language and fallback to English; the language can also be set explicitly as part of the user experience