search

valueflows / vf-graphql

vf-graphql has moved to https://lab.allmende.io/valueflows/vf-graphql
Other
22 stars 3 forks source link

Deprecation of `EconomicResourceCategory` et al #10

Closed pospi closed 5 years ago

pospi commented 5 years ago

Would appreciate some pointers on what to swap things out for after latest updates. I'm getting compile errors about EconomicResourceCategory and am presuming those have been renamed to ResourceSpecification, but would be good to be certain before proceeding with changing & have a mapping for the others (:

pospi commented 5 years ago

I think these are the changed names I need resolved: EconomicResourceCategory OrganizationClassification ResourceClassification AgentResourceClassification ProcessClassification

pospi commented 5 years ago

Now that I'm looking at these I don't think this is a deprecation thing so much as a "new functionality" thing. Can I have an explainer of why we have Specifications as complex objects and Classifications as simple strings, and what the two are meant to be used for?

pospi commented 5 years ago

Latest work on the initial cleanup / sense-checking is at https://github.com/valueflows/vf-graphql/tree/feature/coherent-mutation-fields - I think all these fields are gone now, but I'd still be interested in some information as to why (:

fosterlynn commented 5 years ago

Can I have an explainer of why we have Specifications as complex objects and Classifications as simple strings, and what the two are meant to be used for?

First to note, these have undergone a lot of name and definition changing over time and discussions. I think we are fairly settled on what we have now.

The ResourceSpecification is part of VF, and part of the recipe. It is used when you need to have more definition than you can find in a simple taxonomy, whether there is a recipe or not, but is required in a recipe.

All the classification references are meant for existing taxonomies on the web, such as wikidata and others. So they are all urls. Those taxonomies are outside of VF. They can be used as a fairly specific definition, or as a list of more general classifications that can be used in matching / searching.

I think these need more explanation in our doc, will create an issue on that side of the house.

pospi commented 5 years ago

That sounds... a little bit awkward to deal with? Like, if I am going to build a UI that deals with these, I want more information than just the classification URL present in my system in order to display it nicely to my users, don't I?

fosterlynn commented 5 years ago

I think these are the changed names I need resolved: EconomicResourceCategory OrganizationClassification ResourceClassification AgentResourceClassification ProcessClassification

OrganizationClassification may need to come back. It is in OCP because we allow user definitions of types of agents. In VF we have Person and Organization, and haven't really nailed down a need for types of organization.

AgentResourceClassification also may need to come back, probably with a different name. In OCP there is an agent-resource-role kind of thing. Still thinking in VF if we want that. It is part of the "transfer" discussions currently.

ProcessClassification has basically the same explanation as above for resources, except that you wouldn't use RecipeProcess unless it is part of a recipe.

fosterlynn commented 5 years ago

That sounds... a little bit awkward to deal with? Like, if I am going to build a UI that deals with these, I want more information than just the classification URL present in my system in order to display it nicely to my users, don't I?

I can see it makes some UIs a more complex. But we do want to support classifications that are publicly available and cross scopes or contexts, that people will use to coordinate their types of resources (mostly). And we do need more information than that for recipes and possibly other configuration.

pospi commented 5 years ago

I think what we want then in any serious ValueFlows system, is a normalised taxonomy for classification URLs, and some SemWeb integration / conversion engine that brings things like http://www.productontology.org/ into a platform-native datastore for querying back out.

Or do you see it more as... have the client UI fetch the classification metadata at runtime using web tech in hybrid with Scuttlebutt / Holochain / ActivityPub, and the UI be coded such that it understands the format of the external ontology that you're referencing? I guess what I'm sounding out is where the ideal architectural layer for the data normalisation occurs... I suppose either is possible relatively easily.

Is this where we start talking about extensions to the VF spec, and composable economic data APIs?

fosterlynn commented 5 years ago

Or do you see it more as... have the client UI fetch the classification metadata at runtime using web tech in hybrid with Scuttlebutt / Holochain / ActivityPub, and the UI be coded such that it understands the format of the external ontology that you're referencing?

I have sort of vaguely seen it that way. Lacking any experience, of course. Your first way seems also possible. I defer to others with actual experience on architecture that will actually work. It does seem to me there will be a number of things, including classifications and recipes (think open source hardware), that should be available on the open web, which I don't think is going anywhere soon. I don't see ssb or holochain taking over the world in a way that they become the new web.

Great topic, and good thing to experiment with as we get farther along the holochain path.

pospi commented 5 years ago

It's interesting. Whether we go down @bhaugen's vocabulator route and say, hey, the current web is too clunky and we don't want to have to deal with it; or we keep doing those kinds of "glue-heavy" API bindings in our client apps. fetch makes things reasonably lightweight, even if it is a terrible name. Maybe if libs converge on what browsers support out of the box there is hope for lightweight and simple bindings into the SemWeb ecosystem...

bhaugen commented 5 years ago

@pospi

Whether we go down @bhaugen's vocabulator route and say, hey, the current web is too clunky and we don't want to have to deal with it;

Not sure what you meant. The vocabulator was just a demo/experiment for the vocabulary. Was not intended as a statement about the current web.

SSB is a statement about the current web (for some of the scuttlebutts, but not all).

I think the current web is here to stay for a long time.

If you want simple bindings into the SemWeb that would be interesting but I think that's one alternative infrastructure (with ActivityPub, Holo, and SSB). https://solidbase.info/first-budget/ is using VF + Solid. For now, I think we need to support all of them.

I'm not sure how "solid" SolidBase is, though: I mean, I don't know how much of their stack is SemWeb.

I hope I am responding in some part of what you have in mind....?

bhaugen commented 5 years ago

SSB is a statement about the current web (for some of the scuttlebutts, but not all).

To clarify, some of the scuttlebutts do not want to be on the current web at all.

pospi commented 5 years ago

For those who may come across this issue in future: *Category fields have been replaced with combinations of *ClassifiedAs (ontology URL) and *ConformsTo (ResourceSpecification), now detailed in the schema.