Creating a domain and data model and finding a suitable representation

Tags: #<Tag:0x00007f5bcba959b0>


Glad to hear this. Can you provide me with a link that holds a record of our agreement? I’m unable to derive an authorative source from all that has been mentioned above.


Sorry for the more input and more distraction! :wink:

What I see is difficult to perceive in your image, is that the upper part is an example of how to use the items from the lower part as a vocabulary for actual data. I recognise that this is similar to what we see at the bottom of the pad: a graph visualisation of a set of statements describing a budget.

Yeah, I just did your graph image in a simpler way to help me think, and to bridge from your though process to mine. Sorry about that. Continuing now with the UML, since that is the easiest way for me to think about the model, which I really need to see in one diagram. I recognize it isn’t the easiest for some (most?), and will try an rdf based diagram, which should fit into your glossary approach better.

I’m continuing to think about your model, and have another iteration (not the final one !! ).


  • On the right, the agent relationship model is from ValueFlows. Or you could use ActivityStreams. So the role could be “member”, “supplier” (say a seed source), etc. (user definable with small set of model defined behaviors).
  • The relationship between Activity and AccountingPeriod along with the parent-child recursive on AccountingPeriod gives the option to have activities by sub-accounting periods within a budget, or just use the same one and keep it simple. I added the direct relationship from Activity to Budget because I don’t know if the activity-effort piece knows about agents, or needs to explicitly be made part of a particular budget. Anyhow, I’m not sure I like that one, still thinking.
  • Added some recursives (parent-child) on some of the entities to reflect your model, where I understand you might want flexibility on all kinds of roll-up for reporting the budget. The budget could be reported in any number of ways using the base activity-effort data, from the simplest (one layer) to any level of complexity people might want. So the budget line items are basically that - the reported effort by process classification or resource classification, and by accounting period level.
  • Not sure about BudgetMember, seems all intertwined with the agent relationships (SFS members) and the accounting periods. Like we belong to a CSA where membership is not handled yearly or seasonally, you can become a member and quit any time, because it is for meat which is frozen. But I’m sure they need to do seasonal/yearly budgeting and planning.
  • I’m not sure if an Activity will always be for an accounting period, or can be generic, like yearly or monthly?


Hi Lynn,

to entangle this with the approaches that we took, from the mermaid flowcharts in the pad, after finding and reading of other ontologies, next to writing down of a list of terms into a Wikibase, to your graphical depictions in a standardised way (UML), I am now using your graph as a reference to project the terms that we found from the SolidBase perspective.

I admit I struggle to choose the level of detail, meaning which relations are properties of objects, and which are relations to other objects. This I am not quite clear yet how to represent, next to the weird Blank node and references denoting the expected object as an instance of. Should we be explicit about which objects are Classes, categories in category theory I may correctly remember?, either by naming or an additional instance of relation?

Indeed the whole process feels a bit tideous, when one also needs to name the kinds of relations. I hope this is quite malleable with the Wikibase provided, and we also get a take at visualising it easily. For now I have allowed myself to craft a manual summary of the discussion up until now and hope I got your suggestions correctly. I would also want to suggest we start choosing an authorative source and workflow for agreeing on certain representations soon. Until then I am happy with this pad:

:link: Full screen view


Hi @yala, thanks for the picture! And the perspective.

OK, and I haven’t been able to make complete sense of your SolidBase terms, I have a problem without pictures or at least the relationships defined (that’s just my brain wiring). So I guess it makes sense for you to integrate whatever pieces of my work you want into that, and whatever doesn’t make sense don’t worry about. (Believe me, I won’t take it personally!)

Also, it seems like it might take me too long to think through the whole budgeting model in a way needed for ValueFlows. You all might want to do a very simple app that supports the one solawi method you have users for, which is of course valid. Or something more generalized to other kinds of SFSs, also valid. But before we finalize for VF, we’ll want to run a number of use cases through it, and argue endlessly over the terms too. :slight_smile:

This I am not quite clear yet how to represent, next to the weird Blank node and references denoting the expected object as an instance of.

Do you use the rdfs:domain and rdfs:range? Those should define where properties can live and what they can be (relate to) without having to get into objects. I’m trying to get my turtle (ttl) representation to compile so I can make an rdf based picture. :sweat: Maybe looking at that will be useful once I get it cleaned up.

Should we be explicit about which objects are Classes

I think so, but then I come from relational and OO thinking, sometimes that trips me up in rdf-land. I’ve learned a lot from the elf, but haven’t completely internalized it. Still I think most rdf people use owl:Class a lot. And category theory (which Bob knows a lot more than I do about) thinks still a bit differently, but I think still makes use of class-like patterns.

Indeed the whole process feels a bit tideous

Yeah, totally! :blush:

I would also want to suggest we start choosing an authorative source and workflow for agreeing on certain representations soon. Until then I am happy with this pad

Sounds good to me! I will follow what you all decide for workflow. Not sure yet I can function in a useful way in the terms list.

But I will try to finish my turtle representation asap anyhow… even with parts of it that I don’t totally like yet…


Small note about the name “Activity”. If you are going to integrate ActivityPub at some point, that name will clash with ActivityStreams vocabulary used in AP. What do you think about “Function”? Or maybe “Process” (to us it would be a high level parent process in the case of budgeting, but I worry that might overload Process a bit in VF)?


Small note about workflow. I’ve got no personal need to get all of this stuff defined before doing any coding! If the workflow involves addressing vocabulary standards and ontology during coding as you run into things, that seems totally OK.

And I don’t presume to impact your preferred workflow and methods, that is up to the team of course!


@fosterlynn great to get your input! Would be nice to have a turtle model of our vocab, just to have something to start coding.

After skimming other ontologies, I came to the conclusion that the vocab from the conceptual model of digital financial reporting might be quite helpful for us. Actually we are aiming at computing a good prediction of the coming year using last years annual financial statement, so compatibility with all sorts of financial application (at which XBRL is aiming) would be great. Although the complexity is owerwhelming for me at the moment, it seems to be wise to use some of their taxa. For activity we could use fact and skip the idea of nesting the lines directly in the datastructure using inheritance patterns. Better use abstracts for sorting the information.

@yala I like your graph, and it seems a good point thing to start upon, but I can’t find the property of the value of the activity anymore. This we definitely need. :wink:


After skimming other ontologies, I came to the conclusion that the vocab from the conceptual model of digital financial reporting might be quite helpful for us.

@yova where I am coming from is the ValueFlows ontology. (@yala is familiar.) If you have time, it would be great if you could take a look. It is based on an accounting model called REA (Resources-Events-Agents) that has a simple and clean base model to record any kind of economic activity, from which any standard accounting report can be built. But more importantly, we believe that it can support all the experimental alternatives going on now to figure out how to coordinate a post-capitalist networked economy. Including Solawis and other SFS’s, of course.

Sorry for the “sales pitch”, I don’t know you very well so I hope it isn’t too annoying. If you don’t want to use VF, no worries. :slight_smile: And VF doesn’t include budgeting yet, so we don’t have that part ready for instant adoption. But we’re interested in using your use case to develop that part in a way that it is integrated with planning, actual production and exchange, all of which we do have. (We always try to work in the context of an actual user group, to create something useful now and advance the vocabulary at the same time.)

Actually we are aiming at computing a good prediction of the coming year using last years annual financial statement

I did a forecast/budget system for a bottle cap factory many years ago, and that is how they did it. They took last year’s actual sales by product category (ResourceClassification), and created a starting point for their forecast from that. Then they talked to their customers and adjusted the forecast based on that. Then they used their forecast to generate a budget since they had recipes for what it took to produce their end products.

Anyhow, I will continue working on this. I might be too out of sync with the stage of your process, don’t know. I am not overwhelmed by the complexity, but definitely acknowledge that it exists if you want to support different use cases for budgeting. And it will take some more work to create a clean model that manages the complexity and also integrates with the rest of production, exchange, and accounting.

Happy to give you my first iteration of a turtle file when I get it working, as well as subsequent iterations. But you’ll have to adapt it to the model you decide to use, since I seem to keep making it more and more part of VF.

And I’m happy to continue to collaborate even if you don’t go in the VF direction. (I have a ton of modeling experience.) I’ve admired the good work you all have been doing for the past years, and am happy with any collaboration and getting to know you better. So feel free to ask questions if you like, and I’ll try to be useful.


Hi @yova and @fosterlynn

it seems the three of us have been working a lot behind the curtains tonight. I’ve spent some time porting the wikidata-graph-builder to work with our custom Wikibase. For that I had to close some of its eerier issues, and also uploaded a new RDF dump from Wikibase to the quad store Blazegraph, which sits behind the SPARQL waiting for your queries.

If we build the model as a strict taxonomy, it may be visualised with that tool.

It also has a so-called WDQS mode in which one can enter custom SPARQL queries to traverse the graph. If one manages to represent a nice model in Wikibase, and write the suitable query to receive it as a machine-readable data structure, we’d immediately be able to translate and describe our concepts in a familiar Wiki environment.

I am not sure how this helps the discussion, since we are progressing in parts together, but also diverging with our imaginaries again at times. Along the way I have found these useful resources for reference:

  • API sandbox - TransforMap Base
  • API:Cross-site requests - MediaWiki
  • Blazegraph Workbench
    prefix bd: <>
    prefix wikibase: <>
    prefix wdt: <>
    prefix wd: <>
    SELECT ?item ?property ?itemLabel ?linkTo {
      wd:Q238 ?property ?item
      OPTIONAL { ?item ?property ?linkTo }
      SERVICE wikibase:label {bd:serviceParam wikibase:language "en" }


Dear @fosterlynn, I appreciate the work you are doing with vf, but for our usecase, as we are only dealing with monetary influx / outflux this seems to be far too complex. Nonetheless it is very probably a good idea to implement a very similar budgeting functionality in the next gen NRP @bhaugen told about. But this is the next iteration. Right now we need a simple budget presentation and planning app that is compatible with as much as possible nowadays accounting practices which don’t differ from CSAs to other kinds of businesses. I don’t think we need REA here, as we don’t want to do bookkeeping, we just want to be able to import some simplified annual statements, display them and do some strategic adaptation.

@yala, that looks good, but I don’t really get for what we need this graphical representation. Did you already also manage to visualize the data you entered for solidbase into the wikibase?

The SolidBase budgeting use case for Value Flows accounting

it seems the three of us have been working a lot behind the curtains tonight.

It does. :slight_smile: I’ll stop though and deliver where I am at now. Then wait to see if there is a way we can converge later.

I don’t think we need REA here, as we don’t want to do bookkeeping,

REA and VF is to coordinate economic activity, both production and exchange - but can be used in pieces for small use cases. An advantage is it then will then give a path for the small use cases to connect when they are ready. Bookkeeping is just a useful side effect.

But that’s fine, of course we all should explore what works best for us for our short and long term goals. When they coincide, that’s great; if not, that’s fine too and maybe they will in the future. Again, I’ll stop for now.

If we build the model as a strict taxonomy, it may be visualised with that tool.

Nice taxonomy and visualization. Can you represent your budget model as a taxonomy? I haven’t experimented with SPARQL yet. All good explorations, I’ll watch with interest!

Here is a possible starting point. I’m sure not ready to code from though.

It makes this picture:

Here is another iteration of the UML:

The SolidBase budgeting use case for Value Flows accounting

@fosterlynn, that’s great! Thank you a lot. That is a good starting point for exploring the workflow with rdflib.js. I’m a bit distracted by the notion of the agent and agent relationships and don’t know for what we need the agent relationships here, but probably they could become useful for data exchange in the vf universe. The estimate is fine for me. we can go with that. function might work out, too. What do you think of calling this fact?

Do you actually use any enhanced software for creating the turtle files, or do you just write them in a text editor?

split this topic #33

A post was split to a new topic: The SolidBase budgeting use case for Value Flows accounting


Do you actually use any enhanced software for creating the turtle files, or do you just write them in a text editor?

No, I just write them in a text editor. If you find something, I’d be interested, took me a long time yesterday to find a period that should have been a colon. :sweat_smile:

What do you think of calling this fact ?

Well, the examples you have are Farming, Gardening, Planting. Seems like Fact encompasses a lot more than that. Also nowhere in a budgeting process are there any actual facts, except if people use last year’s production to seed the forecast. So I’m not fond of Fact for this.

I did a quick look at the thesaurus, didn’t see anything I was inspired by. We’re still thinking about it from the VF side.

I’m a bit distracted by the notion of the agent and agent relationships and don’t know for what we need the agent relationships here

That is just a flexible model for any agent relationships. You might want to know the members of the SFS, even not attached to a budget. You might want to know the suppliers of the SFS, as some purchased items might be part of the budget, I don’t know. It is very similar to the ActivityStreams model (used by ActivityPub), except this one allows user-defined types of relationships, which we continue to run into. Like a solawi might have different types of membership, like “whole share” and “half share” for example, and they might receive different portions of the budget. Or you might want to know the farmers or other workers involved in the solawi, who also might receive a share and thus be in some way a portion of the budget. There is a veggie CSA we’ve used in the past that allows people to work 3 hours/week harvesting to pay for their weekly box, instead of cash.

But if you don’t need it, then you could just drop those two classes and keep Agent. Or Person and Organization (subclasses of Agent). Or SFS if you like. You are in touch with your requirements better than I.


I am a bit struggling to find an authorative source of the glossary on which we want to build @yova. From the course of the discussion here I can not deduce a clear summary. It seems terms need to be fine with you, before they can count as accepted?

Maybe we rather keep a fluent model; here, in the data source pad, the other pad that I introduced, the actual implementation? I am also fine to continue without closing consensus, but would like to know where the discussion continues.

We can always use the Talk pages of the entities in Wikibase, and concepts in there have stable identifiers. This may also be good for keeping a revision log of how the model evolves.

This was previously called Endeavour or ESSGlobal:SSEInitiative. What is the right name here?
Transformap (talk) 22:41, 26 October 2018 (UTC)

A brief clarification on the collective workflow here would help me best directing my energies. If we don’t come up with a full-fledged ontology yet, we need at least a glossary (label, description), a small thesaurus (sameAs relationships) and finally some taxonomic order (either of has, subclass of, child of, parent) to an agreed set of terms.

In my understand a fact is the same as a statement, which would by any given triple. There is very fair chance that we are running into (onto-)logical problems, if we try to reuse very broad concepts for our very specific use case. A discussion on recently brought up this gem:

In this kind of theory, everything is relative, an individual’s “knowledge” is just “belief, held firmly”, and “facts” are “beliefs, held widely, by highly trustworthy sources”.

The triples that we formulate are already assertions, which we hope might be true. But we can never absolutely say for sure. Function may be a good compromise here on specificity and flexibility.

Further on we had the questions around effort, amount (“Where is the authorative list of terms, concepts that we are working with?”), which, after following the issue that @bhaugen curates parallely to here, I now tend to believe is simply cost. It can retain all the properties, like unit, value and factor.

Each risk is evaluated of terms of probability (statistics , unknowns, predictions etc) and impact (as a cost). A risk analysis, to be useful in construction, include mitigation measures as a cost item. For agriculture it would be somewhat of an insurance calculation; although it may be similar.

It is obvious that this discussion departs a lot from the original case, in which a training application for a training programme is requested. This shall be a quick and dirty resolution in the first attempt, and don’t recognise exteriors too much. But there is a lot to learn from existing budgeting practices, which may not be reflected in the trainers manual already.


A authoritative source we don’t have yet, but some stuff to start work with, for which I like @fosterlynn’s turtle file most.
Although I like the modelling with wikibase I don’t get yet how solid could get the data from there. Could you describe that a bit, @yala?
The workflow with plain turtle files would fit well into our used gitlab environment as we could discuss changes using PRs. For meta-discussion discourse seems to be still the best.

I can go with function, for my effort I would also be fine with @fosterlynn’s estimate.


Hi @yova just wanted to make sure you are aware of the conversation going on here too… starting here and going down… . Sorry we ended up in two places, it was Bob not having permissions…


Bob and I have been thinking about the naming of Activity/Process/Function and Effort/Estimate/Intent a bit.

We think it is good to use Process and Intent. This is because they are essentially enough like the Process and Intent that we have already in VF that it makes sense to not create new terms, at least from the VF perspective. (Understanding that within VF there will need to be discussion too.)

On the other hand, if you all don’t like those terms, we can take that into VF as a strong recommendation from you and make a change, and if we still decide to use Process and Intent and you decide to use something else, it is not a huge deal, it just means that if you want to communicate to other apps/etc. using VF, it gets translated on the way out and in. That will happen all over the place anyhow, for whatever standard becomes widely accepted.

For reference, our definition of Process is “An activity that changes inputs into outputs. It could transform or transport economic resource(s).” The definition probably should be broadened to encompass planning, intents, commitments, etc. that happen before the actual process becomes operational. We would add to VF that Processes can be nested into higher level Processes.

Our definition of Intent is not documented officially. Thus far, we have used it for offers and requests common in timebanks and ‘small ads’ apps. Using it as part of budgeting would broaden that scope, but it would still occupy basically the same place in the cycle of economic activity - intents then commitments then doing it. And would basically work for exchanges/transfers too. It broadens the initial thinking in that it is documented at a different level at least in terms of time interval (mostly), and often also in terms of level of resource classification.

What do you think? (I’ll also try to document that in more detail over in VF, and relate it more to the existing VF concepts.)


Hi guys! An update from the ValueFlows side: We are having discussions on budget/budget line item, and other cases of high level process, to approve those into VF. I think we’ll end up with a few changes to the turtle file I gave you. Just a heads-up, I’ll let you know when they are more finalized. And then of course you can choose to adopt them or not, depending on how much it affects your workflow and schedule, etc.

We’re also interested in feedback from you if you run into things that don’t work in the model and need to be changed, with thanks.


Hi @fosterlynn! I’m actually still fiddling around with LDP basics, so it will still take some time to discover weaknesses in your ontology. We’ve forked VF to our gitlab and are working with one of the first iterations of the budget.ttl you gave us. That’s fine for now.

In the meanwhile we’ve stumbled upon a ontology for public finance data from the EU:

It would probably be wise to keep some kind of compatibility with this.