weeverapps / iota Goto Github PK

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:

1. 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.
2. 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.
3. 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.

// Current:
"taxonomies": [
    {
        "type":  "tags",
        "value": [ "objects", "examples" ]
    },
    {
        "type":  "categories",
        "value": [ "published" ]
    }
]

// Proposed (Option A):
"taxonomies": {
    {
        "tags": [ "objects", "examples" ],
        "categories": [ "published" ]
    }
}

// Proposed (Option B):
"taxonomies": {
    {
        "tags": {
            "value": [ "objects", "examples" ]
        },
        "categories": {
            "value": [ "published" ]
        }
    }
}

1. On the subject of relationships: Do we need them? I'm struggling to find a difference between relationships and taxonomies.
2. 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.
3. 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.
4. 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?