@matslats has prepared this:
{ "$schema": "https://json-schema.org/draft-04/schema#", "id": "https://raw.githubusercontent.com/MurmurationsNetwork/MurmurationsLibrary/master/", "title": "Complementary currency project", "description": "Metadata for mapping tracking and comparing complementary currency projects.", "type": "object", "properties": { "launchYear": { "$ref": "fields/launchyear-v1.json" }, "numUsersYear": { "$ref": "fields/numUsersYear-v1.json" }, "numTransactionsYear": { "$ref": "fields/numTransactionsYear-v1.json" }, "geographicalScope": { "$ref": "fields/geographicalScope-v1.json" }, "legalForm": { "$ref": "fields/legalForm-v1.json" }, "monetaryModel": { "$ref": "fields/monetaryModel-v1.json" }, "convertToLegalMoney": { "$ref": "fields/conversion-v1.json" }, "paymentTech": { "$ref": "fields/paymentInterface-v1.json" }, "unitOfAccount": { "$ref": "fields/unitOfAccount-v1.json" }, "costRecovery": { "$ref": "fields/costRecovery-v1.json" }, "accountingSoftware": { "$ref": "fields/monetaryModel-v1.json" } }, "metadata": { "owner": { "name": "Murmurations Network", "url": "https://murmurations.network" } } }
I'd like to go through this field by field and suggest some possible improvements:
I'll do each field as a separate reply so we can keep track of discussions more easily 😉
{ "title": "Launch Year", "description": "The year that the entity was instantiated. ", "type": "number", "minimum": 1900, "context": "https://schema.org/yearBuilt" }
This could be made more generic (hence interoperable so it works for legal entities as well as projects. ) by calling it founding_date: https://schema.org/foundingDate which is also a property of Project https://schema.org/Project so the Description should probably be: The date this entity was founded. type MUST be one of the six primitive types ("null", "boolean", "object", "array", "number", or "string"), or "integer" which matches any number with a zero fractional part - so that's OK
We're now suggesting that Context is part of a Metadata section, like this:
"metadata": { "creator": { "name": "Murmurations Network", "url": "https://murmurations.network" }, "field": { "name": "name-v1", "version": 1 }, "context": ["http://schema.org/name"] }
So it would be good if you could add / update to match this
{ "title": "Active users", "description": "The number of users who have traded / logged in within the last 12 months.", "type": "number", "minimum": 0, "context": "need to define and create a permanent URL" }
In order to make this one more generic and hence interoperable I think it would be good to redesign it according to https://schema.org/InteractionCounter which can be related to https://schema.org/interactionType
{ "title": "Active users", "description": "The number of transactions registered in the last 12 months, not including usage fees", "type": "number", "minimum": 0, "context": "need to define and create a permanent URL" }
Same comment as Active Users - if we can redesign this for https://schema.org/InteractionCounter of type https://schema.org/TradeAction that would be much cooler
{ "title": "Geographical scope", "description": "The size of the area the project covers", "type": "enumerated", "options": { "local": { "label": "Local", }, "regional": { "label": "Regional (or Bioregional)", }, "national": { "label": "National", }, "global": { "label": "Supranational", }, } "context": "need to define and create a permanent URL" }
This can be defined by https://schema.org/areaServed like this:
"areaServed": { "@type": "GeoCircle", "geoMidpoint": { "@type": "GeoCoordinates", "latitude": 41.108237, "longitude": -80.642982 }, "geoRadius": 1000 }
But that might be tricky for users who's networks stop at national borders...
You might want to look at https://schema.org/AdministrativeArea which is defined as "A geographical region, typically under the jurisdiction of a particular government."
https://schema.org/areaServed can also be of type 'text' - so maybe your enum list is OK?
"supranational" means "having power or influence that transcends national boundaries or governments." So I think that option might be better as "international"
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?
{ "title": "Geographical scope", "description": "The size of the area the project covers", "type": "enumerated", "options": { "none": { "label": "No legal entity", }, "local": { "label": "Non-profit organisation or charity", }, "regional": { "label": "Co-operative", }, "national": { "label": "Private enterprise (corporation, sole trader/proprietor, or partnership)", }, "other": { "label": "Other", }, } "context": "need to define and create a permanent URL" }
This field contains some copy paste errors (I presume) because the Title and Description and Enum options are the same as Geo scope... That aside - this field is a HUGE can of worms, because Legal Forms vary by country, so you can't have a simple enum list, unless you have asked for Country code first ... but even then it's not easy to know where to pull the latest list of possible Legal forms for that country from...
We do need to nail this, because many schemas want to use this field.
One option is to follow https://schema.org/leiCode which says:
An organization identifier that uniquely identifies a legal entity as defined in ISO 17442. The implementation and use of Legal Entity Identifier (LEI) is supported by Global Legal Entity Identifier Foundation https://www.gleif.org.
But GLEIF doesn't looks like much help as Orgs need to follow a certification process to get an LEI - see https://www.gleif.org/en/lei-data/lei-mapping - and its doubtful that many CC projects will have done / want to do this...
This element is based on the work of the Financial Industry Business Ontology project (see http://www.fibo.org/schema for details), in support of the W3C Financial Industry Business Ontology Community Group (http://www.fibo.org/community). Many class and property definitions are inspired by or based on http://www.fibo.org.
https://spec.edmcouncil.org/fibo/schema might be useful when we get into trying to define transactions But doesn't seem to help define Legal Form per se
There's also this https://standards.esd.org.uk/?uri=list%2ForganisationTypes which is more about Org Type than Legal Entity - however, what are you really getting at with this field? If what you want to know is if the Org is a co-op and / or non profit or a for profit Business, then maybe Org Type is more appropriate here, and simpler to deliver?
I would suggest redesigning this field according to https://standards.esd.org.uk/?uri=list%2ForganisationTypes which could help avoid the 'different legal forms per country' problem, be more accurate than your current list, be easy enough for CC Orgs / projects to fill in - and still provide the filtering I think you want.
NB a "co-op" is not a Legal Form in the UK - and nor is a "Non-profit organisation or charity" - Several Legal Forms can be used for Co-ops, and can also be both Non-profit / for profit and / or charities.
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.
"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:
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
{ "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.
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.
{ "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?
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 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.
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.
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.
Powered by FreeFlarum.(remove this footer)
