{ "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
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.
{ "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"?
"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.
{ "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?
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?
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?
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
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.
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 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
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 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.
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)...
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.
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
olisb All I could see to do here is set the context in the field definition to the areaServed url.
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.
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?
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
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
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
OK I'm surprise no schema exists for this already. Not sure how to use the taxonomy to make a new schema. It feels wrong to use the ESD internal numbers for each sector, so I've put them as separate properties for now and made my own keys. Drilling down into just the voluntary and charity sector produced a good list, but I had to include blockchain only (as a special form of unincorporated) and private companies.Thoughts?
{ "title": "voluntary and charity sector organisation types", "description": "defined at standards.esd.org.uk", "type": "enumerated", "options": { "blockchain": { "label": "Blockchain only", }, "charity": { "label": "Charity", "context": "https://standards.esd.org.uk/?uri=organisationType/229" }, "community": { "label": "Community group", "context": "https://standards.esd.org.uk/?uri=organisationType/95" }, "cic": { "label": "Community interest company", "context": "https://standards.esd.org.uk/?uri=organisationType/230" }, "coop": { "label": "Co-operative", "context": "https://standards.esd.org.uk/?uri=organisationType/231" }, "98": { "label": "Faith group", "context": "https://standards.esd.org.uk/?uri=organisationType/98" }, "housingassoc": { "label": "Housing association", "context": "https://standards.esd.org.uk/?uri=organisationType/104" }, "residentsassoc": { "label": "Tenants and residents association", "context": "https://standards.esd.org.uk/?uri=organisationType/97" }, "trust": { "label": "Trust", "context": "https://standards.esd.org.uk/?uri=organisationType/232" }, "unincorporated": { "label": "Unincorporated association", "context": "https://standards.esd.org.uk/?uri=organisationType/233" }, "voluntary": { "label": "Voluntary organisation", "context": "https://standards.esd.org.uk/?uri=organisationType/234" }, "company": { "label": "incorporated company", }, "other": { "label": "Other", }, }, "context": "http://id.esd.org.uk/organisationType/71" }
matslats what have written might work - I'm not sure of the correct code and whether you can use "label" like you have done, we really need some advice from @geoffturk or @AdamM on that... RE the list, I took a deeper look at the full list and realise now how restrictive / complex it is... so I created this: https://github.com/MurmurationsNetwork/MurmurationsLibrary/blob/olisb-org-type-tags-v1/fields/org-type-tags-v1.json ultimately I think you have to make a call about how you want to handle this field... 'blockchain only' doesn't really feel like a "voluntary and charity sector organisation type"...
matslats not sure on this one, maybe just "None / unofficial" would be better... it would make it clear that was the option for OCN. I disagree about the term "Legal money" and think it is ambiguous - "Legal tender" is well defined, but so is "Fiat currency", either would be better than "Legal money" imho, but again, it's up to you which to use
Powered by FreeFlarum.(remove this footer)
