Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Classes and their instances #14

Closed
elf-pavlik opened this issue Dec 12, 2014 · 17 comments
Closed

Classes and their instances #14

elf-pavlik opened this issue Dec 12, 2014 · 17 comments

Comments

@elf-pavlik
Copy link
Member

Where do I find information, preferably with examples, on how you use Classes and Instances of those classes?

I see common pattern like ovn:Resource and ovn:ResourceType, looking at Relationship I notice

  • type: "object" | why not "@type": "rdfs:Class"?
  • ovn:relationshipType as I interpret it has rdfs:range ovn:RelationshipType | why not "@type" with value of some [ rdfs:subClassOf ovn:Relationship]?
  • Do you use rdfs:subClassOf in your modeling at all?

I must admit just starting process of understanding your modeling so please excuse me my ignorance 👶

@fosterlynn
Copy link
Contributor

I'll let Mikey respond to the notation question, I'm not up on it.

In general - In NRP, we are not using subclasses, for technical reasons related to having a relational database underneath. In OVN Vocab however, we are using subclasses when we think appropriate, currently for Agent and for Economic Interaction, but not where we want to support user defined types, like Relationship Type or Resource Type. See http://www.cs.ox.ac.uk/jeremy.gibbons/dpa/typeobject.pdf for discussion of Type Pattern. And just for reference, here is a loomio discussion on this - https://www.loomio.org/d/5WOvZfEq/linked-open-data?page=2.

@fosterlynn
Copy link
Contributor

In terms of info and examples, there is a new picture on the readme on the front page of this repository that shows the subclasses and the type classes. Here are some examples, all related to ResourceType.

https://docs.google.com/presentation/d/1ztnDX-Cf-PmQPUNxAfntNBBpLH9mhsQ2lrJ77Ty8Plw/edit#slide=id.g1d8603b48_025, slides 9 - 11

NRP - Sensorica: http://valnet.webfactional.com/accounting/inventory/

NRP - DHEN: http://dhen.webfactional.com/accounting/inventory/

@elf-pavlik
Copy link
Member Author

Thank you @fosterlynn, now I start recalling this conversation 🌁
https://www.loomio.org/d/5WOvZfEq/linked-open-data?page=2#comment-285465

http://www.cs.ox.ac.uk/jeremy.gibbons/dpa/typeobject.pdf doesn't work for me, do you maybe have a copy available from different url?

I would also recommend adding a paragraph here to README here about building around this pattern!

@bhaugen
Copy link

bhaugen commented Dec 13, 2014

Unfortunately, that typeobject paper link might be dead. Not responding for me now either, but it did 2 days ago. Hmm...too bad, now the only version might be in the book. [No, the original paper link was back as of 2014-12-13. Maybe it's just spotty. I downloaded a copy, just in case.]

Here's a more elaborate (and open) version from Dirk Riehle with Ralph Johnson from the original paper as a co-author:
http://www.cs.sjsu.edu/~pearce/oom/patterns/new/Riehle.pdf

@bhaugen
Copy link

bhaugen commented Dec 14, 2014

One more angle on classes and subclasses: Lynn described how we do not use subclasses because we are using a relational database and the alternatives for subclassing relational tables are all ugly.

But we probably will do more subclassing in the ovn vocab. For example, most people who do REA models subclass EconomicEvents into InputEvents and OutputEvents; we might do the same. And we might want to subclass work resource types, for another example. But those would be combined with more extensive use of type objects.

All of these refinements, however, will evolve as the vocab gets used, as the refinements are required.

@elf-pavlik
Copy link
Member Author

@bhaugen have you seen http://schema.org/IndividualProduct ?
Martin Hepp will work on documenting better integration of GoodRelations in schema.org schemaorg/schemaorg#134 (comment)

@bhaugen
Copy link

bhaugen commented Dec 17, 2014

Studying more of Hepp's work. Would be interesting to unify GR's Agent-Promise-Object-Compensation Model with REA (basis of OVN). APOC fits within REA.
http://wiki.goodrelations-vocabulary.org/Documentation/Conceptual_model

Agent is obvious. Promise = Commitment. Object is ambiquous: Resource or Resource Type?

Compensation is more complicated. On the simple level, it's just another Resource or Resource Type. On another level, it's part of an Exchange.

But we should be able to interoperate with that model.

@elf-pavlik
Copy link
Member Author

I see some significant differences between Compensation and Resource. For example I wouldn't treat euros as a Resource, but just as one of possible means of securing some actual Resources. Also when it comes to Reputation, if someone grants you an access to some resource just based on portfolio of your past contributions, it changes a lot how we nowadays tend to think about Exchanges... In general I prefer to clearly distinguish the actual resources that production process has hard dependency on, from social conventions we may or may not use while coordinating allocations of those actual resources!

@bhaugen
Copy link

bhaugen commented Dec 19, 2014

This is, fortunately or unfortunately, a deep philosophical question that has a lot of implications.

I started to write a reply but a text box is a bit limiting. Am discussing with Lynn over breakfast. Maybe we could find a different medium? Or maybe write more, here or elsewhere, and then talk,, and then come back here for the sake of anybody else who might wonder where we went?

@bhaugen
Copy link

bhaugen commented Dec 19, 2014

I'll start a response by explaining a bit about the model we use (REA) and why it is the way it is.

It attempts to represent any economic interaction using the smallest number of components, such that every interaction follows the same pattern, and the interactions can be freely connected with each other into economic networks and also composed into larger and larger nodes that follow the same pattern.

For example, both production and exchange follow the same pattern at the most abstract level, and then they start to take on different behaviors as they become more concrete.

The result is a model that is symmetrical, fractal and holonic.

The basic pattern is give and take: you give some resources, and take some other resources.

The relationship between the gives and takes is called Duality, which in essence means "why did you do that?"

So you could give something in exchange for money, or to produce something else, or to trade for some other resources, or to benefit your family or community, or to comply with social expectations, or to improve your reputation, or to improve the ecosystem.

Duality is the pattern behind double-entry bookkeeping, but it's deeper.

This all came from Bill McCarthy when he was this young guy from nowhere who was a student of Peter Chen. Chen told him that accounting should be totally remodeled, and McCarthy researched it for some years and came up with the smallest number of moving parts.

I changed it in the 1990's to make it into a general-purpose economic network model.

We've changed it some more lately to try to prepare for a different economic system, as you may have read.

It would be possible to change it more yet, but first you should understand why it is the way it is, and what you might give up if you break it.

Back to money: it has many faces, but one of those faces is as a medium of exchange. That is, you can exchange money for other resources. It also can be an Asset (an Economic Resource that is owned or controlled by an Economic Agent), and as such is actually just bits in a bank ledger. But you can still exchange those bits for other resources (or other bits).

You can also exchange resources for other resources that are not money (e.g. barter), or the exchange itself can be much more abstract (as described above).

Lots of economic resources have different aspects like that. You can trade food for money or for different food, or you can grow it, or eat it, or compost it.

This gets back into classes and subclasses, too. REA is a domain ontology, which means that all the concepts are not connected to Thing. The most abstract level is Economic Resources, Economic Agents and Economic Events. (You could connect REA to one of several upper ontologies, and people have done so, but we don't.)

Economic Resources start to differentiate almost immediately. Food has different behavior from microscopes, work has different behavior from iron ore, energy has different behavior from money, etc etc. So it would be useful to subclass some of that stuff to some extent. But then pretty soon you get into too many subclasses, and they are no longer user-definable. So as usual a sweet spot emerges in the spectrum from too-general to too-particular.

So, on to Compensation: it is just one side of an exchange. Could be a swap. Or I could you give some money first, and then you could give me something else later. If I give you something that is not money, and you give me something that is not money, who is compensating whom? The one who gives last? A bit arbitrary. Does Compensation only apply to money?

So to conclude for now, Money will need to be differentiated from other economic resources at the first subclass level, but if you differentiate it at the top level, I think you will end up with a non-symmetric, non-fractal and non-holonic model of economic networks. (And yes, I can always be wrong...)

@bhaugen
Copy link

bhaugen commented Dec 19, 2014

P.S. IPOTables totally fit into that model. APOC can, too, but you would need to understand Compensation as a relationship between Economic Events and not a Thing.

@fosterlynn
Copy link
Contributor

@elf-pavlik said: I would also recommend adding a paragraph here to README here about building around this pattern! (Referring to the type pattern.)

Bob and I have been having some interesting discussion around this. In fact, we are using 2 different "types" of the type pattern. Basically different patterns. Our Resource Type and Process Type represent the most common usage - most are user defined of necessity, for example. You would not consider implementing them as subclasses (although we might want some subclasses in addition, like work or money). A Resource Type and a Resource could be thought of more like a class and an instance of that class. Event Type is different, it developed out of the need to delineate behavioral (mostly) differences in events. Our Event Type is hard-coded, not user defined. It is something that could be implemented as subclasses. Or as something like an Event Behavior class.

I'm not sure we want to have both of those "types" in the same domain ontology using the same name, seems confusing. But still thinking. It would be good to work this out with all interested parties - you all ! - in the context of doing the open vocab!

@elf-pavlik
Copy link
Member Author

@fosterlynn where do I find all the Event Types that you use?

@bhaugen thanks you for those clarifications!
I definitely don't want to break anything in your model 😉 Just wanted to put some emphasis on IMO crucial difference. While physical resources have strongly set relationship governed by physical laws, money as just a man made convention works very different. When you often have hard dependency on some inputs eg. you need water + heat to get steam. Money always acts as soft dependency which you can remove from the equation just by adjusting your relationship with all the other human beings that you would use this money to engage in performing financial transactions (which we can consider as a kind of ritualistic behaviour)
If someone puts money as input, it in a way obscures the actual inputs - what real assets (products/services) do you want to get using this money? When it comes to money on output, AFAIK for currencies with ISO 4217 codes banks have monopoly on the 'production' so other peers can only act as sort of conducting nodes, as of today in practice just perpetuating the debt...
I would propose starting new issue if we want to discuss currencies and money further!

@bhaugen
Copy link

bhaugen commented Dec 19, 2014

@elf-pavlik - sorry about the breaking the model comment, it was a bit over the top. I understand lots of differences between resource types, all of which need to be considered, but they apply at the next subclass level (in a subclassable model like this one, at least- in our current software, they are buried in the code). Money has its own behaviors, as you mentioned. Human labor has another set of behaviors. So does energy.

@elf-pavlik - I started issue #10 to discuss resource type subclasses, and kicked it off with tools and a bit about food. I agree with your comments about money. Please explore more over there? And feel free to improve my starting points as well.

@fosterlynn
Copy link
Contributor

@elf-pavlik I'm giving you a snapshot here, should probably document somewhere else too at some point. The only ones that would apply to IPOtables would be the process related event types, and possibly only the top set.

eventtypes

@bhaugen
Copy link

bhaugen commented Dec 20, 2014

The possibly cryptic "Create Changeable" and "Change" have to do with resources which are changed by a process. That is, the same resource is both an input and the output. For example, a translation that is edited, or a machine that is repaired.

@elf-pavlik elf-pavlik transferred this issue from valueflows/valueflows Jan 30, 2019
@almereyda
Copy link
Member

We have moved the ValueFlows organization from GitHub to https://lab.allmende.io/valueflows.

This issue has been closed here, and all further discussion on this issue can be done at

https://lab.allmende.io/valueflows/forum-valueflo-ws/-/issues/14.

If you have not done so, you are very welcome to register at https://lab.allmende.io and join the ValueFlows organization there.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants