Complementary currency schema: Page 2

This is the forum for Murmurations.network

Complementary currency schema

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)...

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.

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 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

matslats

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

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

matslats

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"
}

olisb

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"...

olisb

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

olisb

matslats For these custom fields should I remove the 'context' property?

Yes, if there is no obvious URL to link to and you don't want to create one.

How is that property used?

The idea of the context section of the metadata is simply to provided some context about the intended use of the field. You could also add a "purpose" section, in the metadata, as I have done on: https://github.com/MurmurationsNetwork/MurmurationsLibrary/blob/olisb-description-v1/fields/description-v1.json to clarify the purpose of the field. That could be the perfect place to put your explanatory text "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. "

Does the field inherit other properties from the given context?

olisb

matslats I thought this was an extension schema which means all the standard murmurations fields apply?

It's not strictly an 'extension schema', as we've dropped that idea in favour of the Field Library, to which all re-usable Fields will be added, which will hopefully then provide a growing resource for other Schema Creators to use and build on. So, if you want to use fields that already exist in the Field Lib than all you need to do it reference them in your schema, but if you are creating new fields which you think will be useful to others then it makes sense to add them to the Field Lib and then reference them - hope that makes sense?

The name of the currency unit is not very useful in a context of aggregation.

"Name", in the context of your schema, would refer to the name of the CC network, e.g. "The Open Credit Network"

Also a description isn't good for aggregating, and it's very vague.

Sure, but it would still provide some useful context in listings / pop ups on a map - see this, which I hope will become part of the Field Lib very soon: https://github.com/MurmurationsNetwork/MurmurationsLibrary/blob/olisb-description-v1/fields/description-v1.json

I could consider a field 'purpose' - What is the purpose of this currency, based on https://schema.org/description

Maybe compare "Mission" too - although I am not sure you need both Mission and Description: https://github.com/MurmurationsNetwork/MurmurationsLibrary/blob/olisb-description-v1/fields/mission-v1.json

geoffturk

olisb 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...

Here's how to do it:
https://github.com/MurmurationsNetwork/MurmurationsProtocol/issues/16#issuecomment-721150371

matslats

olisb OK I didn't realise that there were no longer extension schemas.
I guess that means there are no longer base fields?
Does that mean any site can publish any fields it wants, and the aggregator will just do its best?

olisb

See my updated version of Matt's schema here: https://forum.currency.community/d/6-project-database-design/19 and please let us know if you have any feedback before we deploy this..?

« Previous Page

This is the forum for Murmurations.network