You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Mar 2, 2022. It is now read-only.
So I think now that we've been using IoTA objects internally for awhile, we should discuss changes we want/need to make for this to be a 1.0 candidate. Here are a few of my thoughts:
Since an IoTA object is, generally, one "thing," I feel like geo should be an object, rather than an array. If there are multiple locations (eg, for each item in the items array), that informantion should be stored in each item.
Related to that, I feel like we should use GeoJSON for our geometric points. Just storing lat/lng in our current format isn't really a problem, but if we ever need to model more complicated things (shapes, lines, etc), we have a framework for it.
On the subject of taxonomies, I'd like to see them moved from an array to a key/value pair. This will making looking things up or seeing if properties exist much easier & faster.
On the subject of relationships: Do we need them? I'm struggling to find a difference between relationships and taxonomies.
On the subject of datetime: We should always store dates and times as unix timestamps. We should also agree to always use either number of seconds (PHP style) or number of milliseconds (JS style). I don't have a strong preference either way, just as long as we're in agreement.
On the subject of datetime: This is more of a "programming" issue than a "feed standards" issue, but we should try and always include created and updated values in our datetime.
On the subject of accessControls: I feel that we should remove references to this until we have a working prototype. It's a good idea, but not fully fleshed out yet, and I don't want to limit ourselves "because that's what the spec says."
So, these are the few things I've been thinking of. Any thoughts/opinions? @AdamSutch, I think you said you had some changes you wanted to see, but I may be misremembering?
The text was updated successfully, but these errors were encountered:
We do seem to use status a lot. However I don't know if that should apply to the iota spec. Maybe something more abstract (however that brings us back to taxonomies)?
So I think now that we've been using IoTA objects internally for awhile, we should discuss changes we want/need to make for this to be a 1.0 candidate. Here are a few of my thoughts:
geo
should be an object, rather than an array. If there are multiple locations (eg, for each item in theitems
array), that informantion should be stored in each item.taxonomies
, I'd like to see them moved from an array to a key/value pair. This will making looking things up or seeing if properties exist much easier & faster.relationships
: Do we need them? I'm struggling to find a difference betweenrelationships
andtaxonomies
.datetime
: We should always store dates and times as unix timestamps. We should also agree to always use either number of seconds (PHP style) or number of milliseconds (JS style). I don't have a strong preference either way, just as long as we're in agreement.datetime
: This is more of a "programming" issue than a "feed standards" issue, but we should try and always includecreated
andupdated
values in ourdatetime
.accessControls
: I feel that we should remove references to this until we have a working prototype. It's a good idea, but not fully fleshed out yet, and I don't want to limit ourselves "because that's what the spec says."So, these are the few things I've been thinking of. Any thoughts/opinions? @AdamSutch, I think you said you had some changes you wanted to see, but I may be misremembering?
The text was updated successfully, but these errors were encountered: