Ontology design

[timea-solid]

Ontology design

• Usually one starts designing an ontology based on the use cases it needs to serve. We have just a few basic use cases for now. The key is to create an ontology that is flexible enough to be extended and serve more use cases. That being said, one should not get stuck on deciding how the ontology looks because of decision paralysis. First versions will not be perfect and as with software, it will improve. It is really not easy to change an ontology but it is also not impossible, especially at the incipient phases of a product. Advice for starting: done is better than perfect.

• This is a proposal for namespace of the data model (learn about how to design proper persistent URIs: https://philarcher.org/diary/2013/uripersistence/#intro)

  • general remarks - one should never add plural forms to ontology classes
  • it is good practice to create inverse relations

PROPOSAL

1. decide already on a domain name -> @Prefix namespace: http://our_app_domain/ontology# . -> probably the best option!
2. @Prefix namespace: http://timeaturdean.com/ontology# . (we depend on provider, eh)
3. @Prefix namespace: http://timea.solidcommunity.net/ontology# . (we depend on NSS provider)
4. @Prefix namespace: http://periodtracker.solidweb.me/ontology# . (get our own pod on some provider but then we depend on CSS provider) or

App settings

• In the future we can have settings for:

  • Temperature units - Celsius or Fahrenheit
  • Weight unit - KG or LB
  • Time display - 24h or 12h clock
  • Language
  • Connecting to a wearable
  • Theme
  • Reminders (or notifications)
  • Some kind of points collection for gamification
  • Dedicated name for app only
  • Dedicated avatar/photo for app only

• For now we do not really need them to get started.

• The URI design could look like:

  • a class https://timea.solidcommunity.net/ontology#PeriodTrackerApp which has properties like
    • https://timea.solidcommunity.net/ontology#temperatureUnits
    • https://timea.solidcommunity.net/ontology#weightUnits
    • https://timea.solidcommunity.net/ontology#preferedLanguage
    • ...

Period entries

• each period entry needs a type - let's call it PeriodEntry
• each Period Entry is described by:
  • start date (each month) - date -> need to check if schema.org has such an attribute
  • end date (each month) - date -> need to check if schema.org has such an attribute
  • length of the period (days between start and end date) - number

PROPOSAL

Classes

• PeriodEntry
  • example
    <https://timea.solidcommunity.net/ontology#PeriodEntry> a owl:Class; rdfs:label "Period entry""@en .

Attributes

• StartDate
  <https://timea.solidcommunity.net/ontology#startDate> a owl:DatatypeProperty; rdfs:label "Start date"@en; rdfs:range ^^xsd:dateTime .
• EndDate
  <https://timea.solidcommunity.net/ontology#endDate> a owl:DatatypeProperty; rdfs:label "End date"@en; rdfs:range ^^xsd:dateTime .
• PeriodLength -> I actually think this should be under Statistics
  <https://timea.solidcommunity.net/ontology#periodLength> a owl:DatatypeProperty; rdfs:label "Period length"@en; rdfs:range ^^xsd:integer .

Statistics

• some statistics that can occur on the basic period entries are:
  • average cycle length
  • average period length
• since we will have to see how computational heavy it is to do these on the fly, an alternative is to write these statistics and needed mathematical numbers out on the pod say once a month. And then just display them.
• in order to compute the average cycle length we need to calculate the length of a cycle (from start of period till the start of next period)
• we can add this number to the statistics part of data when a user logs in 2 consecutive periods.
• this statistics data should be stored separate from the period entries - so while period entries we can add to periodEntries.ttl this ones we can add to periodStatistics.ttl
• so for the statistics we also need:
  • cycle length
• in the future we can also go into ovulation date and luteal and follicular phase.

PROPOSAL for statistics

Classes

• PeriodStatistic
  • example
    <https://timea.solidcommunity.net/ontology#PeriodStatistic> a owl:Class; rdfs:label "Period statistic"@en .

Attributes

• AverageCycleLength = in days, from start of period till the start of next period
  <https://timea.solidcommunity.net/ontology#averageCycleLength> a owl:DatatypeProperty; rdfs:label "Average cycle length"@en; rdfs:range ^^xsd:integer .
• AveragePeriodLength = in days, from start of period till the start of next period
  <https://timea.solidcommunity.net/ontology#averagePeriodLength> a owl:DatatypeProperty; rdfs:label "Average period length"@en; rdfs:range ^^xsd:integer .

Classes

• CycleStatistic
  • example
    <https://timea.solidcommunity.net/ontology#CycleStatistic> a owl:Class; rdfs:label "Cylce statistic"@en .

Attributes

• CycleLength = in days, from start of period till the start of next period
  <https://timea.solidcommunity.net/ontology#cycleLength> a owl:DatatypeProperty; rdfs:label "Cycle length"@en; rdfs:range ^^xsd:integer .

• PeriodLength
  <https://timea.solidcommunity.net/ontology#periodLength> a owl:DatatypeProperty; rdfs:label "Period length"@en; rdfs:range ^^xsd:integer .

So what do you think? What is missing?

[timea-solid]

Ok, to get going I settled on a first version.
Deploy it so that it is available online.
I defined all the properties mentioned above. I am sure they will suffer changes as we develop.
See: https://timea.solidcommunity.net/SolidPeriodTracker/SolidPeriodTrackerVocabulary.ttl