Complementary currency schema

This is the forum for Murmurations.network

olisb

    "title": "Monetary model",
    "description": "The basis of issuance and redemption",
    "type": "enumerated",
    "options": {
      "tokens": {
        "label": "Fixed number of tokens e.g. Bitcoin ",
      },
      "points": {
        "label": "Tokens issued as needed e.g. Time banks, reputation scores",
      },
      "mutual": {
        "label": "Mutual credit e.g. Sardex, Wir, business barter, LETS",
      },
      "selfIssued": {
        "label": "Self-issued credit e.g. shopping vouchers, deli dollars, self-signed cheques",
      },
      "mesh": {
        "label": "Mesh credit (a.k.a Ripple)",
      },
      "hybrid": {
        "label": "Hybrid",
      },
      "other": {
        "label": "Other",
      },
    }
    "context": "need to define and create a permanent URL"
}

You're on the bleeding edge here 🙂 I'm not sure many other Schemas will use this field so it's probably OK to define it as you like - I'd aim to make the options really clear and well defined ... in my survey I went for:

Mutual Credit
Time bank
LETs
Crypto-currency / blockchain based
Other:

matslats

olisb naturally this could be a very long discussion.
I would go for a bit more granularity that yours because there are a lot of geeks in the field. But also too much granularity quickly leads to ambiguity and multiple choice answers. believe me I've spent years on this. In your proposed list mutual credit is synonymous for many people with both LETS and timebanking. Some would say that lets and timebanking are social designs more than currency designs. Some would say that blockchain is a ledger technology not a currency type. You'll see there is another question about technology.
Generally with these questions I've tried to make it so that one and only one answer is possible, to make the data as easy to manipulate and parse and possible. I looked over my list again and I still like it. If you can see ambiguities or name projects that might want to select 2 options I would try to refine it.
This field may is probably not suitable for public consumption

olisb

{
    "title": "Conversion to legal money",
    "description": "Whether and how the currency can be exchanged for money",
    "type": "enumerated",
    "options": {
      "none": {
        "label": "None / unofficial only e.g LETS, timebanks, other non-monetary systems.",
      },
      "market": {
        "label": "Market based e.g. via currency markets.",
      },
      "100%reserve": {
        "label": "Legal money is 100% held in a reserve E.g Bristol Pound",
      },
      "fractionalReserve": {
        "label": "Redeemable from a fractional reserve, perhaps using a bonding curve e.g. Grassroots Economics.",
      },
      "other": {
        "label": "Some other mechanism",
      }
    },
    "context": "need to define and create a permanent URL"
}

This one is even more bleeding edge! I'd suggest avoid the words 'legal money' and maybe say 'fiat currency' instead - but if all you're getting at here is if people can 'cash out' (which I do think is a useful metric) then maybe just ask "Can the currency can be exchanged for fiat?" and make it a boolean? I'm not sure why extra value we derive from having all the complexity of "how" wrapped up in this field.

matslats

olisb Cashing out is a user experience, and doesn't describe what's happening in the system. Are you converting your tokens for cash reserves? Are you selling your tokens to another trader on a market? Is the price of your tokens in relation to cash determined by policy, or by supply and demand? Some systems have restrictions on who can cash out.
So I'm trying to capture those kinds of possibilities with these few options. Again if you can think of ambiguous situations or options are not clear, I'll consider refining them or explaining them better.

olisb

{
    "title": "Payments / user interface",
    "description": "How do users make payments and view their accounts? (multiple choice)",
    "type": "enumerated",
    "options": {
      "cheque": {
        "label": "Cheques",
      },
      "physical": {
        "label": "Circulating paper / physical tokens",
      },
      "book": {
        "label": "Each member keeps an account book.",
      },
      "plastic": {
        "label": "Plastic card with PoS system",
      },
      "plugin": {
        "label": "Via a social networking plugin (Example needed)",
      },
      "app": {
        "label": "Standalone App",
      },
      "other": {
        "label": "Other",
      }
    },
    "context": "need to define and create a permanent URL"
}

I think this is probably too much detail / too complex to try and capture for v1 of this schema - many networks will have combinations and might not be accurately covered by your suggested options - I suggest dropping this one for now

matslats

olisb This is important for practitioners and researchers.
I don't see the benefit of dropping fields for version 1 of the schema.
This is a multiple choice which allows for rich combinations of answers.
I missed one - admin_only: A ledger accessed only by an system administrator.

olisb

{
    "title": "Unit of account",
    "description": "How is the value of the currency unit determined?",
    "type": "enumerated",
    "options": {
      "time": {
        "label": "Time based e.g. hour",
      },
      "legal": {
        "label": "Equivalent to national legal unit e.g. US dollar.",
      },
      "market": {
        "label": "Pure supply & demand e.g. Bitcoin",
      },
      "index": {
        "label": "Indexed to a commodity price or basket e.g. gold, eggs",
      },
      "redeemable": {
        "label": "Redeemable for a commodity e.g. vouchers",
      },
      "other": {
        "label": "Other e.g. Most LETS create arbitary units",
      }
    },
    "context": "need to define and create a permanent URL"
}

I think this one is pretty good, it's definitely useful info to gather.
maybe "Equivalent to national legal unit e.g. US dollar." would be better as "Equivalent to fiat currency e.g. USD"?

olisb

"title": "Cost recovery",
    "description": "How does the project cover its running costs? (multiple choice)",
    "type": "enumerated",
    "options": {
      "membershipFee": {
        "label": "Membership fee",
      },
      "transactionFee": {
        "label": "Transaction fee",
      },
      "demurrage": {
        "label": "Savings tax / Demurrage Fee / negative interest",
      },
      "donations": {
        "label": "Donations",
      },
      "grants": {
        "label": "Grants",
      },
      "inkind": {
        "label": "In-kind contributions",
      },
      "volunteers": {
        "label": "Volunteers",
      }
    },
    "context": "need to define and create a permanent URL"
}

This is probably OK too - I can't find any better examples / think of better ways to do this.

olisb

{
    "title": "Accounting software",
    "description": "N.B. The accounting software may differ from the User Interface",
    "type": "enumerated",
    "options": {
      "blockchain": {
        "label": "Blockchain",
      },
      "cyclos": {
        "label": "Cyclos",
      },
      "cmsPlugin": {
        "label": "CMS Plugin",
      },
      "webService": {
        "label": "Accounting web service",
      },
      "unpublished": {
        "label": "Unpublished / proprietary software",
      },
      "mesh": {
        "label": "Mesh credit (a.k.a Ripple)",
      },
      "app": {
        "label": "Integrated with the App. (what's the best name for this)",
      },
      "p2p": {
        "label": "P2P App (e.g. Holochain)",
      }
    },
    "context": "need to define and create a permanent URL"
}

I'm not sure about this one - it could be nice to know / filter by on a map / in a directory... and the people creating CC profiles should easily know this info - I think the hardest part is making the list inclusive enough to be useful... maybe you should allow free tags here?

matslats

olisb Yes i thought about free tags, but you always end up with unusable data. Have you seen the old CC database (its offline now) Can you imagine what OCN would put for software in a free tags field? It wouldn't be useful.
I think the list includes everything and the answers would be fairly well distributed. Can you think of an system that wouldn't fit in this list?

matslats

admin This is more about the scale of the project, or its ambition than the actual area or region covered. Would be great to classify and filter projects. Could it merit a new type in schema.org?

olisb

matslats RE Geographical scope - my advice would be to define this as https://schema.org/areaServed as an enum list with the options: Local, Regional, National and International, which would make the field useful for other schemas too - so it could be re-used via the fields library

matslats

olisb Its not about legal forms, so much as social forms.
The list at https://standards.esd.org.uk/?uri=list%2ForganisationTypes is not bad, though I would probably trim it.

olisb

matslats RE Org Type - OK using https://standards.esd.org.uk/?uri=list%2ForganisationTypes for an Org Type field makes a lot of sense, so we can refer to each of the URIs they already have. Starting with a trimmed down list makes sense for this (CC) schema but will make the field less interoperable with other schemas that need more / the full list of options... do what you think is best, but if you can included all the options it will mean this field is more interoperable and stands a better chance of being re-used via he Fields Lib.

olisb

matslats RE. Monetary model - ok, if it's not for public consumption I don't think it matters much - and we're not seeking interoperability with this field so perhaps just go with what you had.

olisb

matslats RE Conversion to legal money - As mentioned, I'd suggest avoid the words 'legal money' and maybe say 'fiat currency', which is more explicit. Again, this is not likely to be an interoperable field so do what you think best. I'm not sure this field will get much uptake tho... I'd struggle to know how to classify OCN 'credits' because although there's no official way to convert OCN credits for fiat it would probably be possible for someone to 'sell' their credits for fiat outside of the OCN accounting system... which is probably true for all alt currency systems, really... so every answer will (should) probably default to that option (which is missing)...

olisb

matslats RE Payments / user interface - ok, keep it in if you think it's useful, I'd suggest aiming for simplicity (to encourage uptake / use) in v1 and building out from there with more detail (i.e. more fields) once the schema has some practical use - but it's your schema so it's your call! Again, I'm not sure I'd know how to classify OCN - I'd probably define it as an "online accounting system", which might be what you mean by "Standalone App", but to me a "Standalone App" is a true app, that I can install on my phone / other device, so OCN is not that.

olisb

matslats RE Accounting software - again, it's your call on this one really, if you go for a fixed list you will always need to add new options as new systems are created, if you go for free-tags it could get messy but at least it would be inclusive. For OCN I would want to put "MCCS" and link to https://github.com/ic3network/mccs - which makes me think maybe this should be a Name + URL combination (since it would be useful for others browsing to be able to find the software listed) like https://github.com/MurmurationsNetwork/MurmurationsLibrary/blob/master/fields/urls-v1.json but with only one row (i.e. just one name + URL pair, rather than several)? If this is a list of 'accounting software' then every option will have a URL the form filler should be able to point to

matslats

olisb
All I could see to do here is set the context in the field definition to the areaServed url.

matslats

olisb
Sorry you couldn't work out which option for ocn. Can you think how to make the field description clearer than:
"None / unofficial only e.g LETS, timebanks, other non-monetary systems."
Legal money is a technical term, but fiat currency is actually colloquial. I will use the latter, since it is better understood.

matslats

olisb I ichanged the name to accounting softwareType. This field is not for documenting all the accounting systems out there, but to get an idea of what's going on internally to the currency.
For these custom fields should I remove the 'context' property?
How is that property used? Does the field inherit other properties from the given context?

olisb

I hope all the above helps, and is useful for a new draft of the schema?
I'm really exited to see it coming together and will definitely try to help get it deployed and people to use it... 🙂

The schema also needs a few more fields (maybe you have already planned for these!?):

Name - you can re-use this field: https://github.com/MurmurationsNetwork/MurmurationsLibrary/blob/master/fields/name-v1.json

Description - so people can get a quick overview of the CC network / system - We need a generic version of this too for the Field Lib, based on https://schema.org/description

It would probably also be nice to capture / show logos - based on https://schema.org/logo

Plus, you really do need a URL field too - if just a single URL you can re-use: https://github.com/MurmurationsNetwork/MurmurationsLibrary/blob/master/fields/url-v1.json or if you think you need to collect multiple URLs you can re-use: https://github.com/MurmurationsNetwork/MurmurationsLibrary/blob/master/fields/urls-v1.json

Oli

matslats

olisb I thought this was an extension schema which means all the standard murmurations fields apply?
The name of the currency unit is not very useful in a context of aggregation.
Also a description isn't good for aggregating, and it's very vague. I could consider a field 'purpose' - What is the purpose of this currency, based on https://schema.org/description

olisb

matslats Yeah, plus the change to International, rather than Supranational, so we end up with this:

https://github.com/MurmurationsNetwork/MurmurationsLibrary/blob/master/fields/areaServed.json

This is the forum for Murmurations.network

A free forum powered by FreeFlarum (remove this footer)
Terms & Conditions | Privacy Policy