valueflows issueshttps://lab.allmende.io/valueflows/valueflows/-/issues2024-02-09T22:45:02Zhttps://lab.allmende.io/valueflows/valueflows/-/issues/126IRI's2024-02-09T22:45:02ZLynn FosterIRI's@elf-pavlik provided this link: https://tools.ietf.org/html/rfc3987.
My understanding from a skim of the spec: IRI's were created to expand URI's to be international by expanding the character set. There is an algorithm to create a UR...@elf-pavlik provided this link: https://tools.ietf.org/html/rfc3987.
My understanding from a skim of the spec: IRI's were created to expand URI's to be international by expanding the character set. There is an algorithm to create a URI from an IRI. A URI can be considered an IRI.
So, seems to me we should use IRI for all our current and future references to URI's. What do you all think? Especially Pavlik.elf Pavlikelf Pavlikhttps://lab.allmende.io/valueflows/valueflows/-/issues/308Recurrence Rules2019-01-30T20:08:38Zelf PavlikRecurrence RulesSome resources which should help with designing recurrence for flows:
* https://icalendar.org/iCalendar-RFC-5545/3-8-5-3-recurrence-rule.html
* https://icalendar.org/rrule-tool.html
* https://developers.google.com/calendar/concepts/...Some resources which should help with designing recurrence for flows:
* https://icalendar.org/iCalendar-RFC-5545/3-8-5-3-recurrence-rule.html
* https://icalendar.org/rrule-tool.html
* https://developers.google.com/calendar/concepts/events-calendars#recurring_events
* https://developers.google.com/calendar/recurringevents
I find it interesting that google calendar seems to still create event *instances* which reference recurring event with `recurringEventId`
I think we could consider defining generic `vf:ReccurrenceRule` which actual flows could reference and this way keep flows similar to those event *instances* in google calendar.elf Pavlikelf Pavlikhttps://lab.allmende.io/valueflows/valueflows/-/issues/603Proposal: "measurement observations" and EconomicResource dimensionality2022-05-16T21:08:40ZpospiProposal: "measurement observations" and EconomicResource dimensionalityA conversation has come up in a beef industry use-case regarding the tracking of custom measurements against resources. I'm opening this up as a broader conversation as it has implications for the way we conceptualise the domain of Value...A conversation has come up in a beef industry use-case regarding the tracking of custom measurements against resources. I'm opening this up as a broader conversation as it has implications for the way we conceptualise the domain of ValueFlows as a grammar.
The short version is that there is a `ResourceSpecification` for *"boxed beef"*. This ontology includes additional attributes, such as the cut of meet, breed of cow etc. `EconomicResource` instances which `conformsTo` this `ResourceSpecification` have an additional `temperature` measurement, which is tracked along the supply chain as an indicator to the quality of the final consumer product.
**Option A: extensions to `EconomicEvent`**
An original suggestion of mine was that this could be managed via the tracking of a *"measure temperature"* `Process`, where the `modify` output of the `Process` would include the temperature reading as part of the `EconomicEvent` (likely via an extended schema field, `observedTemperature`). The system would have custom logic extending the core VF vocabulary that would handle the update of `EconomicResource.temperature` in response to the `observedTemperature` attribute of inbound `EconomicEvents`.
In this implementation we are pushing this use-case into "nonstandard extensions", and essentially stating that ValueFlows does not consider such measurements within the domain of its model.
**Option B: implement `MeasurementEvent`**
@fosterlynn had the suggestion that we create "a very simple non-economic event, some kind of observation data recording for a resource. Seems like most often it would be very simple, and very repetitive, especially if it comes from sensors. But perhaps sometimes it could require a process to make it happen, like if someone has to go make the measurement and they want work recorded at that level of detail."
IMO this is a pretty elegant way of handling it (certainly fewer null fields being stored unnecessarily). In this case, in the process of including measurement-specific concepts in the grammar, we begin to acknowledge ValueFlows as a *measurement ontology* - not just an *economic ontology*. I'm a fan of movement in this direction as it acknowledges both the higher forms of abstraction at play and also the interaction between these areas of expertise in the real world.
This is about as far as we spoke about this, which is why I'd like to extend that idea with...
**Option B+1: multi-dimensional `EconomicResource` measurements**
Taking Lynn's suggestion further and thinking about how we might represent these recordings as data leads me to this idea.
One reason to like it is that it gives `EconomicResource.unitOfEffort` more utility- so far, I've yet to see much use for this field other than initialising the units of resource quantities. I also see this evolution in a similar light to the new metadata attributes added to `Actions`- they provide additional semantic structure that makes reasoning about the semantics of ValueFlows much easier. Anyway, consider this proposal:
- We extend `EconomicResources` to allow them to be measured by multiple units, in parallel dimensions. We would add an array of `Measures` to the record (call it `EconomicResource.currentMeasurements`?)
- Resources retain a *"primary dimension"* that we still refer to as their `unitOfEffort`. All accounting math done via `EconomicEvent` operates on the measurement dimension of `unitOfEffort`; if a conversion to that unit is not possible, the `EconomicEvent` is in error.
- Other *"secondary dimensions"* may be arbitrarily declared on the `EconomicResource`. These are manipulated via `MeasurementEvents`. Like `EconomicEvents`, `MeasurementEvents` are used both to initialise new measurement dimensions on the resource and to update the value of the field.
- Unlike `EconomicEvents`, the quantities specified with `MeasurementEvents` are given as absolute values, and the result of the action is simply to directly update the value of the measurement against the `EconomicResource`.
To run through this logic for the *"boxed beef"* use-case, consider the following flow:
1. A `raise` `EconomicEvent` is logged to initialise inventory tracking of the beef boxes as usual.
2. Movement of the boxes through the supply chain primarily occurs via VF's existing `transfer-*`, `move`, `pickup` and `dropoff` actions on `EconomicEvent`.
3. Thermal checks of the boxes are periodically performed by logging `MeasurementEvents` with `{ observedQuantity: { hasNumericValue: XX, hasUnit: 'degrees_celsius' } }`. Each `MeasurementEvent` logs a timestamp and observing agent automatically.
From my perspective, this ties off a few loose ends in the grammar and sets us up for the broadest possible spectrum of use-cases moving forward. Interested in hearing other reflections.https://lab.allmende.io/valueflows/valueflows/-/issues/605Facets as part of VF?2024-02-07T14:40:51ZLynn FosterFacets as part of VF?This came up here. https://github.com/valueflows/valueflows/issues/603
I'm wondering if we want to explicitly include a model for facets and facet values as part of VF knowledge layer? I've always kind of boxed them into resource clas...This came up here. https://github.com/valueflows/valueflows/issues/603
I'm wondering if we want to explicitly include a model for facets and facet values as part of VF knowledge layer? I've always kind of boxed them into resource classifications, but they do have a more complex structure and are ubiquitous in e-commerce. Example: Shirt. Size: 12, Color: Red. Or Boxed Beef. Cut: Round steak. Weight: 2 lb. Pastured 100%: true. I think that mostly, all these would also be part of the ResourceSpecification, as they are all part of a specification specific enough to actually order, like a "size 12 red shirt", but they are kind of buried there without a model.
I looked in GoodRelations and did not find this structure. I also don't see it in schema.org, but it is a bit hard to see all of their model.
But I can see that there might be standard definitions that would be re-used among agents.1.0.0Lynn FosterLynn Fosterhttps://lab.allmende.io/valueflows/valueflows/-/issues/609Add other formats to w3id.org links2024-01-28T20:11:32ZFlorian KleedorferAdd other formats to w3id.org linksThe VF ontology states its URI as [https://w3id.org/valueflows/](https://w3id.org/valueflows/), its Version IRI is [https://w3id.org/valueflows/0.4/](https://w3id.org/valueflows/0.4/). The former redirects to [https://valueflo.ws](https:...The VF ontology states its URI as [https://w3id.org/valueflows/](https://w3id.org/valueflows/), its Version IRI is [https://w3id.org/valueflows/0.4/](https://w3id.org/valueflows/0.4/). The former redirects to [https://valueflo.ws](https://valueflo.ws), the valueflows landing page, the latter to [https://valueflo.ws/0.4/](https://valueflo.ws/0.4/), which returns a 404.
While it is possible to find the [current version of the ontology](http://150.146.207.114/lode/extract?owlapi=true&url=https://raw.githubusercontent.com/valueflows/valueflows/master/release-doc-in-process/all_vf.TTL) within a few clicks, for automation reasons it would be nicer if the `w3id.org` URIs redirected to the ontology directly, ideally with content negotiation.1.0.0https://lab.allmende.io/valueflows/valueflows/-/issues/613Questions regarding transport-with-transfer.yaml2024-01-18T19:41:37ZFlorian KleedorferQuestions regarding transport-with-transfer.yamlAs I am trying to wrap my head around modelling in VF, I have a few questions regarding `/valueflows/examples/transport-with-transfer.yaml`:
- **redundant data:** there seem to be more `vf:resourceQuantity` and `vf:resourceClassifiedAs`...As I am trying to wrap my head around modelling in VF, I have a few questions regarding `/valueflows/examples/transport-with-transfer.yaml`:
- **redundant data:** there seem to be more `vf:resourceQuantity` and `vf:resourceClassifiedAs` statements than necessary, repeating '30 kg of apples' many times in events. For example the pickup/dropoff events (eg claudia:856c43b1-0a63-445f-a56f-707b257f086e), could they not just reference claudia's economic resource representing the apples? Doesn't this invite inconsistencies?
- **Bob is not mentioned in the agreement:** In the agreement, there is no mention of Bob or his address. I would expect that in `urn:uuid:c7897c39-7f05-4a5d-a487-80e130a2414a` (the service commitment). The actual EconomicEvent that fulfills the Commitment, `urn:uuid:68cabaf3-deb8-4bd5-a439-798263abe35a` doesn't mention Bob, either. This is just for brevity, I assume?
- **handovers are not committed to:** I'm surprised that the transfer-custody from Claudia to Bob is not somehow required in the agreement or necessary for fulfillment of the 'service' Commitment. When the transfer-custody to Bob takes place (urn:uuid:7a63ea10-b1c3-441a-9a08-fb8630c02614), it seems that the transport Agreement is already fulfilled. However, I'd argue that, even with FOB transport, the transport isn't finished until the intended recipient has custody of the object, so the transfer-custody should be required for Fulfillment. No?
- **data visibility:** the modelling seems to account for different agents having only a partial view of the data: each agent has their own URI space that is used for EconomicResources; events are identified by UUIDs so they are independent of agent URI spaces. However, when you try to trace the Fulfillment of the Agreement from Alice's point of view, I think she needs access to both Claudia's and Bob's data in order to verify that bob has actually received the apples. Are there any assumptions in VF as to data visibility/ownership etc?
- **two processes:** there is no connection between the two consecutive processes claudia uses to transport the apples, apart from the resource being the same. I would expect some storage location where she drops off the apples and picks them up later - which would also make sense tracking-wise; moreover I had expected the processes to cause an update to claudia's resource location. Is it correct to assume that data has been left out for brevity that would normally be there?
Thanks!1.0.0https://lab.allmende.io/valueflows/valueflows/-/issues/617Further needs for geo shapes2024-01-18T19:41:08ZLynn FosterFurther needs for geo shapesWe have a request from a project to include more than points in our geo (location) references - more for completeness than any immediate need. There is experience using geoJson on that project. Currently we are using SpatialThing from ...We have a request from a project to include more than points in our geo (location) references - more for completeness than any immediate need. There is experience using geoJson on that project. Currently we are using SpatialThing from the Basic Geo vocabulary https://www.w3.org/2003/01/geo/, with lat, long, alt. We picked it because is very simple, and attempts somewhat to bridge competing standards.
I found a really helpful document from the W3C discussing options, https://www.w3.org/TR/sdw-bp/, here are some especially useful sections:
* concepts https://www.w3.org/TR/sdw-bp/#spatial-things-features-and-geometry
* best practices https://www.w3.org/TR/sdw-bp/#bp-summary
* comparison tables here https://www.w3.org/TR/sdw-bp/#applicability-formatVbp
I'm still mulling over the best way to think about it for VF, but thought I would get the issue out here so others can connect if they want. And have time. :) [edit: but not required, I'll put out a proposal after I have settled some of this in my head, and then there will be something to really comment on]1.0.0https://lab.allmende.io/valueflows/valueflows/-/issues/623RDF/Owl schema: arrays vs singular values2024-01-06T17:32:16ZAndrewRDF/Owl schema: arrays vs singular valuesCurrently in the Owl spec from what I can tell there's no concept of whether a value is singular or one-to-many. For instance `RecipeProcess::processClassifiedAs` is labeled as an array in both the JSON/GQL schemas, but I see nothing tha...Currently in the Owl spec from what I can tell there's no concept of whether a value is singular or one-to-many. For instance `RecipeProcess::processClassifiedAs` is labeled as an array in both the JSON/GQL schemas, but I see nothing that differentiates it from other values that show up as singular in those schemas.
One thing I've come across in my research is that `owl:FunctionalProperty` might be used to signify a *singular* value, but by default all values can be multiple. I've also read that `owl:FunctionalProperty` is additive such that it can be specified alongside `owl:ObjectProperty`.
It might make sense to define which fields in the classes are singular. As a usual caveat, I don't know much about RDF/owl so I might be totally off-base by suggesting `owl:FunctionalProperty` to accomplish this.1.0.0https://lab.allmende.io/valueflows/valueflows/-/issues/624RDF/Owl schema: required/optional fields2024-01-06T17:31:58ZAndrewRDF/Owl schema: required/optional fieldsAfter spending a while on google, I'm still not clear on how (or even if) Owl determines whether a datatype is required or optional. The concept seems present in both json schemas and graphql, but I'm not seeing a differentiation in the ...After spending a while on google, I'm still not clear on how (or even if) Owl determines whether a datatype is required or optional. The concept seems present in both json schemas and graphql, but I'm not seeing a differentiation in the object properties in the owl schema.
Because I don't know the best way to do this (maybe `owl:cardinality`??) I can't make any useful suggestions yet. I'd be happy to help out with a PR if we find an idiomatic way of handling this.1.0.0https://lab.allmende.io/valueflows/valueflows/-/issues/630Immutability and monotonic reasoning for VF2024-02-07T14:38:59ZFlorian KleedorferImmutability and monotonic reasoning for VFI am building a SHACL-based system for automatically making all the inferences in a VF model expressed in RDF. The goal is that this gives you a VF engine that does ALL the calculations that VF prescribes, so if you build your applicatio...I am building a SHACL-based system for automatically making all the inferences in a VF model expressed in RDF. The goal is that this gives you a VF engine that does ALL the calculations that VF prescribes, so if you build your application based on it, you can focus on providing the inputs and handling the outputs. Inputs are rejected if they violate the rules. Outputs are `Fulfillments`, `Claims`, `Satisfactions`, changes to `EconomicResources` (and probably some more).
The technique I am using is being developed as [SHACL Advanced Features](https://www.w3.org/TR/shacl-af/), especially the new Rules feature, which does monotonic reasoning. It allows you to *generate* triples in response to certain conditions present in the data, but not delete any triples.
Unfortunately, the VF model does not lend itself to monotonic reasoning in its current state. One problem is that an `EconomicEvent` can change an `EconomicResource`'s `(accounting|onhand)Quantity` (or `currentLocation`, or `primaryAccountable` - which means deleting a triple and generating a new triple. So, I am thinking about tweaking the model to accommodate for that, and I appreciate any comments:
Essentially, `EconomicResources` need to become immutable, and an `EconomicEvent` that involves an `EconomicResource` *always* generates a new object - the next version or next state of the resource. Consequently an `EconomicResource` can only ever be involved with one event. With that change, the VF model becomes a complete history of all resource modifications. This would require a new relationship, eg. `vf:previousState`, and disallow any `EconomicEvents` on `EconomicResource` instances that have a `vf:previousState` relationship pointing at them. Thus, the latest version of an `EconomicResource` is the head of a linked list of versions, and each version is connected to the `EconomicEvent` that caused the change. If you have a planning or recipe entity that references an `EconomicResource`, let's say, a `Commitment`, and you now want to generate the `EconomicEvent` that will fulfill it, it is possible that the referenced `EconomicResource` has already been involved with other `EconomicEvents`. In that case, it would not be the head of the `vf:previousState` chain and you would have to find the head of that chain in order to instantiate your `EconomicEvent`.
Currently, I can't think of another entity in the VF model that currently needs to be mutable, so that would be the only major change. Am I missing one?Bob HaugenBob Haugenhttps://lab.allmende.io/valueflows/valueflows/-/issues/636Questions from WoN exploration2024-01-18T19:39:19ZLynn FosterQuestions from WoN explorationFrom @fkleedorfer in the welcome chat. [edit] Maybe we can just keep a running list of smaller questions here?
>For example: an event with move action has either one or two resources attached, If it has only one, it a) must not have a ...From @fkleedorfer in the welcome chat. [edit] Maybe we can just keep a running list of smaller questions here?
>For example: an event with move action has either one or two resources attached, If it has only one, it a) must not have a quantity, or b) may have no quantity, or its quantity must be equal to the resource's onhandQuantity, or c) it must have a quantity that is equal to the resource's onhand quantity?
>Or another: vf:primaryAccountable seems to be the relationship affected by events with vf:transfer and vf:transfer-all-rights actions.
Is there a relationship of the resource that is affected by vf:transfer-custody?1.0.0-dochttps://lab.allmende.io/valueflows/valueflows/-/issues/644How should adaptations from different contexts make it back into VF?2020-06-10T20:44:45ZBob HaugenHow should adaptations from different contexts make it back into VF?This issue emerged from a question from @fkleedorfer in https://github.com/valueflows/valueflows/issues/636#issuecomment-641810339
VF emerged from a long series of participatory action research projects and now is going back into new ...This issue emerged from a question from @fkleedorfer in https://github.com/valueflows/valueflows/issues/636#issuecomment-641810339
VF emerged from a long series of participatory action research projects and now is going back into new projects which are deliberately using VF. We (me and @fosterlynn , anyway) see this as a spiral, learning from particular experiments, summarizing into more-general conclusions (making it back into VF), and then going back into practice (more particular experiments).
Some experiments will want to change or extend the vocabulary and model. Some of those changes might be accepted into VF as-is, and some might want to be listed or linked in the VF repositories as extensions or variations that might be useful for more than the original context.
For example, the [Data Food Consortium](https://datafoodconsortium.gitbook.io/dfc-standard-documentation/) has developed a vocabulary that can be mapped to and from ValueFlows. It would seem possible for a project to merge those vocabularies into something new that could be used in a data food context and also connect to other kinds of economic activities that could occur in the same economic network. I'm not sure what to call it: a fork, a mixin, a merger, or what. It would probably want to live in its own repository but link back to ValueFlows and DataFood. How would they handle upstream changes? I don't know. But I could foresee things like that happening and being useful, for example, for community economic systems.
I don't think I am anywhere near done with this issue yet. Looking for a better word for extensions and variations and mergers that would have their own repos but also be mentioned in VF as stuff you could use. And maybe other variations on the theme of how to bring back good ideas from the wild...;-)https://lab.allmende.io/valueflows/valueflows/-/issues/646How to use examples?2024-01-18T19:38:40ZJohannes Winteryova@freedomhost.deHow to use examples?I'd like to visualize the [examples](https://lab.allmende.io/valueflows/valueflows/-/tree/master/examples), but am not sure whether I'm doing it efficiently. I figured out to [convert the yaml to json](https://www.json2yaml.com/convert-y...I'd like to visualize the [examples](https://lab.allmende.io/valueflows/valueflows/-/tree/master/examples), but am not sure whether I'm doing it efficiently. I figured out to [convert the yaml to json](https://www.json2yaml.com/convert-yaml-to-json) and then loading it into the [json-ld playground](https://json-ld.org/playground/). But I'm unhappy with the result, as it only dumps the graphs and doesn't display the relationships between the agents in the `agents.yaml` example.
I was also looking for import possibilities of the examples into the [django-vocabulator](https://lab.allmende.io/valueflows/vf-code-experiments/django-vocabulator), but didn't find any. Did I oversaw something? Intuitively I would use such a tool for modelling valueflows...
The explanation for using the examples in the [CONTRIBUTING.md](https://lab.allmende.io/valueflows/valueflows/-/blob/master/CONTRIBUTING.md#examples) could be refined.
Related:
- https://lab.allmende.io/valueflows/valueflows/-/issues/122
- https://lab.allmende.io/valueflows/valueflows/-/issues/5021.0.0-dochttps://lab.allmende.io/valueflows/valueflows/-/issues/649Graphical represenation of examples does not match code2024-01-18T19:38:01ZJohannes Winteryova@freedomhost.deGraphical represenation of examples does not match codeI was particularly looking at: https://valueflo.ws/examples/ex-planning.html#proposal-for-work-commitment
In the graph its written `intent to find someone to work`, and in the code the corresponding name of the intent is `Help with R&D ...I was particularly looking at: https://valueflo.ws/examples/ex-planning.html#proposal-for-work-commitment
In the graph its written `intent to find someone to work`, and in the code the corresponding name of the intent is `Help with R&D for the sensor`.
I suppose the reciprocal intent to the provision of cash is not the finding of the fitting person, but the work that dude is doing.
The graphical representation of the proposal is `Proposal: request for work` and the name in the code is `Electrochemical engineering skills`. That are different abstraction levels, but I think that fits anyway.
I would find it generally useful to use the names of the classes in the code as labels in the graph.
`Income distribution agreement` has no representation as code. The explanation of this in the text only makes little sense to me, as I think the agreement can only happen when two persons agreed to the proposal. Propably the sense ahall be, that the agreement is guided by previously established value equations.
related: #6461.0.0-dochttps://lab.allmende.io/valueflows/valueflows/-/issues/651Improve doc from new people's experience2024-01-18T19:37:35ZLynn FosterImprove doc from new people's experienceGo through the discussion created as part of @yova 's work, and improve the doc based on the questions and answers.Go through the discussion created as part of @yova 's work, and improve the doc based on the questions and answers.1.0.0-docLynn FosterLynn Fosterhttps://lab.allmende.io/valueflows/valueflows/-/issues/653Value equations refactor for VF2023-03-30T15:57:09ZLynn FosterValue equations refactor for VFI think it might be time to try to get value equations into VF. Thus far I've felt that we didn't know enough to make things generic. I'm hoping that maybe the time has come, we'll see as we try to do it.
Context: [DisCO project needs...I think it might be time to try to get value equations into VF. Thus far I've felt that we didn't know enough to make things generic. I'm hoping that maybe the time has come, we'll see as we try to do it.
Context: [DisCO project needs them](https://wiki.guerrillamediacollective.org/The_DisCO_Project_Matrix#2:_DisCO_DECK:_Value_Tracking_Platform). They have a handful of new pilots plus their experience in Guerrilla Media Collective. We have a handful of experiences with Sensorica and others who have forked NRP. So, it's starting to add up.
I'm going to first gather that experience, as much as possible, and document it here.
Related, we're doing a piece of value equations [here](https://lab.allmende.io/valueflows/vf-app-specs/vf-value-equations/-/issues/1), which is starting to reveal ways to think about modularizing this beast so it's manageable for people with very simple requirements.
[Concepts/Tutorial from NRP](https://speakerdeck.com/mikorizal/10-nrp-value-equation-concepts-and-tutorial)
[Old reference doc with some pseudo-code](https://docs.google.com/document/d/1zCVoADNHcr46HSdab2NrT0cBvB9c8Cmq2oaHitbYekc/edit?usp=sharing)
Also note Sensorica (who named them in the first place) has changed the name to "benefit distribution algorithm". Or at least @TibreriusB has done so. I like the name change, it is more clear.Lynn FosterLynn Fosterhttps://lab.allmende.io/valueflows/valueflows/-/issues/654Agent agreement on events, commitments, claims2024-01-23T16:49:30ZLynn FosterAgent agreement on events, commitments, claimsThis has come up in several groups who want to validate or check events logged by members. We expect it will also come up with transfers. Basically, wherever there is a provider and a receiver, they should agree that the record is corre...This has come up in several groups who want to validate or check events logged by members. We expect it will also come up with transfers. Basically, wherever there is a provider and a receiver, they should agree that the record is correct. This becomes more critical in distributed systems, and feedback from people with that experience would be helpful. @pospi @bhaugen @mayel and anyone!
Bob's initial thought is to create some kind of state or status for those records, which could include things like "data was received" (for distributed systems), "provider asserted", "receiver agreed" or whatever names we like or are standard in other places. Might be the same as "signed", "counter-signed".
Also I don't know if this belongs in the vocabulary, or should be considered a different level - but I think it would be helpful in the vocab. It will probably be exposed in some user interfaces, where the receiver agreement cannot be fully automated.https://lab.allmende.io/valueflows/valueflows/-/issues/660ShEx and Shacl representations of VF2024-02-07T14:38:59ZLynn FosterShEx and Shacl representations of VFMoving parts of a discussion started in gitter here, for more permanence. OK to continue here?
@elf-pavlik : In Solid Interoperability Panel we use data shapes quite heavily (one of the participants actually leads https://shex.io/ effo...Moving parts of a discussion started in gitter here, for more permanence. OK to continue here?
@elf-pavlik : In Solid Interoperability Panel we use data shapes quite heavily (one of the participants actually leads https://shex.io/ effort) I think writing up some data shapes might help implementations a lot. While RDFS definitions, for example rdfs:domain and rdfs:range, don't restrict anything only lead to additional statements being inferred. ShEx Triple Constaints provide a clear way to define valid set of values. One could think of it as JSON Schema for RDF.
@hoijui : automatic translation is preferable in my eyes, because defining the same thing manually in two different formats, leads to problems, same like copy&pasting code files and then changing minimal parts of them.
@lynnfoster : yes absolutely if we can do an automatic translation, that would be great! The problem I see is that a reason to use ShEx is to add cardenalities and other constraints that aren't in the turtle file. Unless we decide to use some OWL 2 elements maybe? But, yes, if there is a translator available, let's try it out - at least it would get us 90% of the way there, or something like that.
@hoijui : Having slept over it, I though, as we are auto generating, we can do both formats, which fits what you wrote ("... should support any format anyone wants.").
they should both be quite easy, though as Shacl is RDF too, it could be a bit easier even -> use an RDF library, read the ontology, translate/map RDF to Shacl properties, write to Shacl file using the same RDF library.
for ShEx, if there is no library, we will have to write code that writes the correct syntax ourselfs, but that should be doable in a few lines of code as well.
Here is an (almost) Open Source tool for OWL->Shacl:
https://astrea.linkeddata.es/
source: https://github.com/oeg-upm/Astrea
I did not find anythign for OWL->ShEx, nor Shacl->ShEx.
(except weso/shaclex#113)
... I would not claim that my search was extensive though.
@elf-pavlik : I think whichever one you choose you probably would want to write your shapes yourself. At least I wouldn't rely on what you can get given OWL as input.
One of the reason we start with ShEx in solid is simply that one of main authors is an active group participant, this way we can clarify any doubts related to our usage of ShEx very easily.
BTW ShEx also can be expresed as RDF https://shex.io/shex-semantics/#shexj
In the end I think it would be good to have both ShEx and SHACL shapes. In that case we might want to have some sample data which will pass and fail consistently across both shape formats.
@hoijui : my idea then would be, to add the OWL 2 things to the ontology, run the auto conversion to Shacl, and .. then you could maybe have a look at that outcome, and indicate the issues. then we could adapt the ontology, think about improving the conversion tool, asking upsteam to do so, write a post-proccesing script, or in the worst case, just use that generated result as a base and fixing it manually (though if one can do it manually, one can also do it by script).https://lab.allmende.io/valueflows/valueflows/-/issues/666Add Space (Recipe|Plan|Observation) info to the subjects in RDF2024-01-18T19:35:39ZRobin VobrubaAdd Space (Recipe|Plan|Observation) info to the subjects in RDFFor example, by one of these two options:
```turtle
vf:SomeThing
vf:space vf:Recipe|Plan|Observation # 1.
vf:recipeParent vf:RecipeXxx ; # 2.1. for Plan subjects, or
vf:planParent vf:PlanXxx ; # 2.2. for Observ...For example, by one of these two options:
```turtle
vf:SomeThing
vf:space vf:Recipe|Plan|Observation # 1.
vf:recipeParent vf:RecipeXxx ; # 2.1. for Plan subjects, or
vf:planParent vf:PlanXxx ; # 2.2. for Observation subjects
.
```
related chat discussion around here:
https://matrix.to/#/!fOTCtWgVCPrvYrYWRc:matrix.allmende.io/$163663099639TdUis:fabcity.hamburg?via=matrix.org&via=gitter.im&via=fabcity.hamburg1.0.0Robin VobrubaRobin Vobrubahttps://lab.allmende.io/valueflows/valueflows/-/issues/667Recipe variants and forking2024-01-06T18:01:04ZLynn FosterRecipe variants and forkingWe are talking with the [FabCity:Hamburg project](https://www.fabcity.hamburg/en/fab-city-os-projekt-interfacer/), which wants to implement open source hardware recipes, is using VF, and also has other open source hardware connections. ...We are talking with the [FabCity:Hamburg project](https://www.fabcity.hamburg/en/fab-city-os-projekt-interfacer/), which wants to implement open source hardware recipes, is using VF, and also has other open source hardware connections. At the same time, we are talking to the [GitBuilding project](https://gitbuilding.io/), which is developing markdown-based documentation to share recipes. Since it is text-based, it can be stored in git repositories to support forking and versioning, which we have known is a requirement for VF but haven't added. Here is [an example](https://build.openflexure.org/openflexure-microscope/v7.0.0-alpha1/low_cost_microscope.html) of GitBuilding doc.
So we are using this opportunity to coordinate upgrading the VF recipe model to support the features these and possibly other groups are interested in, and also to see if we can create a round trip between Gitbuilding and VF software. The conversation is still developing.
This issue is for documenting the ongoing discussion, and to work on the VF model.1.0.0