pospi (01b1671f) at 14 Dec 00:15
bump version
This removes the RecipeResource class from the recipe. Since it is removed, the substitutable property was moved to ResourceSpecification. The relationship recipeFlowResource was changed to resourceConformsTo, in order to directly reference ResourceSpecification from RecipeFlow.
I'm not sure I did the bridging right, please review. Perhaps resourceConformsTo shouldn't be in the recipe.gql file, but only in bridging?
pospi (5e49081e) at 26 Oct 00:16
Merge branch 'recipe-resource' into 'sprout'
... and 3 more commits
Noting that substitutable
is intentionally nullable, so that an unknown value can be distinguished from either boolean option.
pospi (c1af5418) at 19 Oct 23:17
fix duplication of RecipeFlow -> ResourceSpecification edges
... and 1 more commit
Kinda related to #5 but there is now much more mess to clean up on this as we work through extracting UI kits from some Neighbourhoods projects into component repositories.
https://github.com/neighbour-hoods/bugs-n-features-requests/issues/4 is probably the best place to keep abreast of this conversation for now. Once we have some decisions, expect some of the recently added PNPM and Vite build configuration mess to be cleaned up and better managed.
At present the build system generates a bundled package for all components within the repository and all their dependencies, which is unnecessarily large. But it works well enough for inclusion in other projects which is the minimum-viable functionality.
For completeness, the projects containing generic components which are yet to be refactored out into this repo are:
pospi (00325ebc) at 25 Jul 04:27
change build config to generate UMD bundle as well as ESModule
... and 2 more commits
Refer to https://github.com/neighbour-hoods/timetracking-applet/issues/13 for more information on the implementation needs driving this proposal.
- the OM class of the unit (might be useful, might as well provide)
- also myApp:Unit (I don't understand this part)
These were just examples of how power-users familiar with RDF, OOP and other meta-terminologies might leverage the instanceOf
parameter— you could use it to group all the "standardized" OM2 units just as you could use it to sub-group and categorise them; and then query based on those categorisations (eg. "get me all the metric volume units", "get me all the units defined in the custom domain of my app").
We're still on the same page RE handling of OM2 Units
and how they should be integrated / initialised. I'm chasing some standardisation about how we refer to commonly used units so that UI controls can reliably know they're getting the right data.
the linked data string, like
om:metre
(I don't see much use for this in a graphql api)
The purpose here is that we have little guarantee that people enter "metre", maybe some enter "metres", maybe there are "meters" accidentally in there- know what I mean? And this gets worse with lesser-known Units
- there are many ways to describe them. The OM2 tables you've generated also indicate that there are no unique identifiers which we can reliably match these two fields on.
If we make this field a required field that obliges those entering the information to reach into an understanding of ontologies and unique identifiers for things; then we have more of a social guarantee that these commonly agreed-upon contracts will be honoured. Like if they ignore all advice and don't include it, then cool, when it comes time for them to integrate with a neighbouring economic network adding that field to their schema (or even hardcoding it) should be pretty easy.
Defines an optional core schema for measurement.filtering
which extends Query.units
with a filter
parameter.
The intention with the design of this input type is to require minimal bindings to the OM2 ontology in order to facilitate simpler implementation and reduce integration complexity. But, I would like a review on the chosen parameters to ensure we don't feel as though any flexibility or additional possibilities are being forfeited.
pospi (2c5f6614) at 04 Apr 07:13
note RE OM2 Unit subclasses and RDF query params
... and 1 more commit
heh, indeed it does. The reason for switching to it over the older unit ontology that VF previously recommended is that this model can do the kinds of complex inference you describe above without encountering logical uncertainty in ML Reasoner models. So, thankyou for the articulation
Am I hearing something about an ideal version of the Unit
zome which would include and index all the above metadata for querying and retrieval?
Time to start thinking about specs for retrieving and managing Unit
records and the OM ontology. See https://github.com/h-REA/hREA/pull/387#issuecomment-1426941156 for more.
Unit
records with an optional sameAs
field (corresponding to http://owl.semanticweb.org/page/Owl:sameAs.html). This would allow the GraphQL API to reference not only OM units, but units from other vocabs as well.filter
parameters to the units()
query API so that sameAs: [URI!]
can be used to select sub-sets of well-known units.Other questions:
owl:sameAs
the correct relationship to be modeling, or is this more of an rdfs:subClassOf
situation? I figure reasoning logic that makes any comparisons is going to have to recursively fetch and compare all references either way (eg. an hour
in the coffee shop's network is sameAs
an hour
in the bakery's network which is sameAs
the OM2.0 'hour' term).sameAs: URI
) sufficient, or would we prefer multiple (classifiedAs: [URI!]
)?sameAs
return a self-referential URI to its own Unit
record if no value is assigned? Should this be queryable for custom units?This also bloats out the GraphQL and creates a lot of implementer burden for little utility in actual real-world systems; see valueflows/vf-schemas/vf-graphql#101.
In regard to semantic rigour around a possible agentType
field— we can achieve this by defining values for vf:agentType
in the core grammar that implementations can refer to when defining well-known types. I think that would mean that we still have vf:Person
, vf:Organization
, vf:EcologicalAgent
etc but that these are just strings to be specified for vf:agentType
on any Agent
.
It would an expectation that access to any nonstandard data fields that implementors might keep against an Agent
would be conditionally coded to only be retrieved for specific (extended) Agent
types.