Hi all, there is a new release of ValueFlows ready at https://valueflo.ws/. We will keep this version as stable as possible for the projects that are now using or getting ready to use it. Then iterate from there based on those projects’ combined feedback. So looking forward to that collaboration!
ValueFlows (VF) is the REA vocabulary that we are using in HoloREA. Besides the vocab, lots of conceptual info is available on the website. A note for people who have read about REA from other sources, including Hruby’s book, which was mentioned in the old mattermost channel: You will find some differences, from subtle to a couple more noticeable ones, based on our operational experience and other people’s inputs to ValueFlows. But its still all REA.
Questions welcome! And I’m very happy to work directly with anyone implementing VF, figuring out the best way to make it work well for your project. It helps the vocabulary as well as the project, all good.
Thanks a lot for this great work. I didn’t knew much about REA and started reading the website yesterday and another door opened. This makes so much sense and is so needed in the world of today. I am going to dig deeper and learn as much as possible about REA and HoloREA. I shared it with Peter Mika who worked a lot on/with RDF and schema.org. Will continue to share with my network of people who are in the research community. Thanks for the amazing work.
A very clear and helpful overview; thank you! Makes life a lot easier because even as a non-coder (but Holo-entrepreneur) I can well understand all the elements.
Hi @lynnfoster. I studie the VF UML model and copied it to EA Sparx UML for a more complete documentation and to use it in my projects.
I used it also to compare the JSON-schema with the UML schema and I noticed a number of differences.
I used it also to compare the JSON-schema with the UML schema and I noticed a number of differences. Can I send my notes to you?
@yeff yes please! All of that was done by hand, so I’m not surprised there are some differences. We figured we would fix anything wrong when we use it, but I’m very happy you looked closely at the definition, thank you!
I will fix all and let you know. And explain anything that was an intentional difference.
UPDATE: I did a cross-check with the ontology and I found more inconsistencies. Please check version 2 of the PDF here.
Here’s a link to the UML view I made with EA Sparx
It includes data types and dictionaire of classes and attributes in notes, but you can’t see that in the diagram.
The advantage of using this is that I can use this as a meta-model, so that I can put “stereotypes” on UML classes and then make specific models for specific use cases with the EA Sparx tool.
I can then make a diagram for each process of the use case and make an overview diagram of all processes involved in a use case.
@yeff Again, many thanks, and very clearly documented! I’m making some fixes, but it may be a few days because of guests at our house. Can get you answers to each point in the meantime if you would like it sooner.
A little progress, but not much. Traveling with our guests and other meetings now, back home Tuesday and back to more focused work. Sorry, we usually have more work time than we have had this month, this is unusual for us.
In the meantime, what I think we will do, some of it subject to some discussion:
Action should be “label”, will fix.
Removed email from Agent, if we do contact info, it should be modeled better. In general I think we will just use other vocabularies for most Agent properties.
Agent uri looks like copy/paste error, might be same as above for email, not sure.
AgentRelationship should have inScopeOf property
AgentRelationshipRole should have note property
dcterms:created good catch, we need to add it to our External Terms page
name, image, etc. without domain - those can go many places, so we left it looser in the rdf definition, using the UML to tighten that up - I’m interested in feedback on that practice
currentLocation, yes should be SpatialThing
inScopeOf is usually a group/organization Agent (always in our experience so far), but in the VF team there was a desire to open it up more, for example for regional or ecosystem accounting, and I think we still have to work out better the conceptual definition - I tightened it up in the json-schema in the meantime as I wasn’t sure how to do something more general there, and our current projects will probably all use Agent as the range - I want to do a PR on that for further discussion
Again, thanks for your detailed notes and good catches, I wish we had spent one more day proof-reading. And if you have opinions on any of it, or anything else in VF, they are very welcome. I should also note that although I have a modeling background, I have no practical linked open data / rdf background, although I have learned a lot working on VF. We mostly rely on Pavlik in the VF team for that.
Also when I have more time, I am happy to work directly with you (or anyone) on mapping VF to your specific use cases, I hope that will help both projects.
The “name” property hasn’t got a domain in the ontology. Is this correct?Idem for “image”, “uri”, “finished”, “mappable addres” and “current location”…
If I may give my opinion on the value type of “inScopeOf”, then I would say that I’m in favour as well to open it up and not limit it to “Agent”. Let’s say we want to have the option to use either “Agent” or “uri”.
In UML this can be solved via assigning a value type that is the union of both “Agent” and “uri”. This can be modelled as well in the ontology using the union on the range and in the JSON-schema with a “one of” construct (I think).
The same trick can be applied on the “agreedIn” property with a union of both “Agreement” and “uri” as value type/range.
Hi @pospi, I have to look into ontologies, but everything ISO is a pretty good starting point, which strongly enough is not mentioned in that issue comment.
Here is a link to ISO Unit of Measure codelist, not an ontology, but in any case super handy to have in Value Flows, I would say.
Staying with the current usage of the “qudt:QuantityValue” datatype now used in Value Flows, the “qudt:unit” allows for any type of Unit of Measure, so the ISO Unit of Measure could be used.
An alternative approach would be to make your own “vf:QuantityValue” datatype, with “vf:numericValue” and “vf:unit” properties and create a “vf:Unit” class - and use that as the range for “vf:unit” - with two properties: one with the “vf:uomNS” (uri) an a “vf:uomCode” (string). This way you could use any value (coded value) from any codelist (namespace).
This wouldn’t give you any fancy reasoning capabilities, but it wouldn’t give you the related issues either.
Thanks for your usual attention to detail and documentation! Can I ask, what source are you using to generate your UML diagram? And what tool? It would be great to be able to generate that and not have to do manual synchronizing.
If I may give my opinion on the value type of “inScopeOf”, then I would say that I’m in favour as well to open it up and not limit it to “Agent”. Let’s say we want to have the option to use either “Agent” or “uri”.
Glad to have some other eyes on the unit of measure questions.
Here is a link to ISO Unit of Measure codelist, not an ontology, but in any case super handy to have in Value Flows, I would say.
Missing the link? My experience with ISO is that most or all of it unfortunately costs money, including the units of measure, as far as I could tell. I would be happy to be wrong. But for me, that eliminates it for use in next-economy projects.
I’m using the Enterprise Architect tool of Sparx for my UML modelling. I come from a background in using this tool for GML-based INSPIRE data specifications (as co-editor of the INSPIRE Utility & Governmental Services and a few others based on that in Flanders projects, like Klip).
I used the GML profile in combination with the open source ShapeChange tool, which allows generating all sorts of “target” outputs: XMLSchema, JSON-Schema, RDF/OWL, SQL-DLL, documentation, etc.
So the source in this case is the UML and not RDF/OWL, there’s the difference, I think.