djodjoni commented 7 years ago

I need to prepare soon a minor food data sync mechanism so different hub nodes using different software can share data of producers and transporters. For now the data is mostly stable i.e. without transactional events. In the context of VF it is mostly Templates .

I would like to make it as much closer to VF as soon I will need to add the full planning and observation layers. I would appreciate a lot if I can get some feedback on both the logic/ideology and the RDF/LOD aspects.

you can check the current ontology here http://openthings-cc.github.io/openthings-food/ and here https://cdn.rawgit.com/openthings-cc/openthings-food/master/ofd-core.ttl

I also have open an issue there: https://github.com/openthings-cc/openthings-food/issues/2

fosterlynn commented 7 years ago

Cool! I will study. Also will have to get my head around the SKOS - OWL stuff. Others will need to actually provide feedback on the RDF/LOD aspects, I'm way behind you on that.

What is your timing? @djodjoni

djodjoni commented 7 years ago

I will give some small demos beginning of March and probably apply it soon after. Also the result I decided to be an open (for those who want their data open) discoverable (LOD) directory of Food and Food Actors Data (because I am fan of open data :) for now mostly for Belgium. Then 6th of March I want to present this to a local Open Knowledge Belgium Conference where to look for funding and cooperation as well. At the same time I am trying to fit in Open Food Network Project (OFN) to link with all data and possibly create a local instance where I can help OFN build up LOD Rest API . The data i will put on openfooddata.org.

So basically I don't want to rush things and this is why I am trying step by step to create stable data dictionary as a start and really try it in practice and learn how it can fit the best. :) So whatever I do we can change later it is still a draft but in action :)

fosterlynn commented 7 years ago

Thanks @djodjoni . That sounds like a really sound approach to me. I think it will be really useful to see very concretely how VF will support a specific domain like food. Several of us are OFN fans too. :)

draft but in action

:+1: :+1: :+1:

pmackay commented 7 years ago

@djodjoni just wondering, do you have any example RDF, JSON-LD, etc of some data represented by this vocab?

pmackay commented 7 years ago

@djodjoni I've had a look at the TTL file. I guess this relates to #182 - you've defined OFD terms for everything. Is that something that can be avoided? If VF can reuse terms from other vocabs, could OFD reuse that reuse? :)

Also related to reusing terms, is it not possible to simply use the Agrovoc terms directly, rather than defining your own set of terms for Food, Meat, Fungi, etc?

pmackay commented 7 years ago

Also as these parallel efforts are literally happening now, worth checking https://community.openfoodnetwork.org/t/data-food-consortium-making-food-platforms-interoperable/772/9 and http://datafoodconsortium.org/en/ if you've not seen that.

fosterlynn commented 7 years ago

@djodjoni I put some comments into your ttl, here: https://gist.github.com/fosterlynn/cbb5a21982dab283a6f8e525ca554416. They all say "VF:".

Hope this helps. I think some of it may require more discussion....

djodjoni commented 7 years ago

@pmackay thx for looking into it ! :)

just wondering, do you have any example RDF, JSON-LD, etc of some data represented by this vocab?

I will probably have time to do the examples Sunday evening. So soon :)

I've had a look at the TTL file. I guess this relates to #182 - you've defined OFD terms for everything. Is that something that can be avoided?

I try to define a minimum set of Classes specific to that 'Food Context' and those are also concepts so they can be extended and reuse in various ways. I also try to relate those to VF vocab.

The main ones are: FoodType wich is essentially subclass of vf:Category FoodProduct subclassOf vf:MaterialtemTemplate FoodService subclassOf vf:ServiceTemplate FoodActor which is just a category for the foaf:Actors

Do you have any concrete suggestions for those?

If VF can reuse terms from other vocabs, could OFD reuse that reuse? :) Of course and this is why I am trying to sync, with the Actor thing for example :)

Also related to reusing terms, is it not possible to simply use the Agrovoc terms directly, rather than defining your own set of terms for Food, Meat, Fungi, etc?

All the "SubConcepts" there are for basic guidance of the user of this vocabulary. The food specific types (Food, Meat, Fungi) I am not sure if I want to keep them at all in the core vocab, but in practice I see lots of different hierarchies and thus copies of the same concepts but the important thing is to reference the main ones and this is why there are broaderWikidata, broaderAgrovoc, and etc.

For example the current category menus of Producers and Shops are actually the vf:Category and those are part of their data/knowledge base, those Actors will not change their data but may well reference to the global ones or other custom ones.

I am not really clear how it will work in practice so any specific suggestion is welcome :)

Also as these parallel efforts are literally happening now, worth checking https://community.openfoodnetwork.org/t/data-food-consortium-making-food-platforms-interoperable/772/9 and http://datafoodconsortium.org/en/ if you've not seen that.

Indeed I am aware of this and I had a call with Myriam yesterday so we can sync and not compete rather collaborate. So we agreed indeed to collaborate but they are too early in discussions and does not have anything clear however hopefully soon they will open those discussions. On the other hand I need this in practical use-case now and since I am doing it why not try to make as close to VF and be reusable by others. So this may not go any further or be used by their vocabulary or some others who knows :) Anyway Myriam is in close contact with @elf-pavlik so I am sure they will come up with something useful :)

djodjoni commented 7 years ago

@fosterlynn thx ! I will the comments here :)

[VF: foaf:member would be an agent relationship. That structure allows any kind of relationship using the same structure. (For example, Sensorica decided their members are called "affiliates" as that expresses it better to them.) Here's a json-ld example from way back. At one point, we were going to define at least a first layer of relationship properties that have different behavior, like member behavior is different than childOf (or partOf) between 2 organizations. So memberOf is a start at that, but we never finished it and maybe shouldn't have any defined in VF?]

foaf:member is a group to agent relationship indeed so all subclasses goes in here. this however is some default template I use and metadata for the ontology only.

ofd:broaderSchemaOrg a owl:ObjectProperty ; rdfs:label "broaderSchemaOrg" ; rdfs:domain skos:Concept ; rdfs:range schema:Thing .

[VF: ??]

the '??' I suppose are for the broaderSchemaOrg. The purpose of those is to link with other common vocabs. For this I can also use owl:sameAs however there are many reasons why I prefer custom 'context based relationship'. one nice article about that is https://www.w3.org/2009/12/rdf-ws/papers/ws21 .

ofd:FoodActorType a owl:Class ; rdfs:label "Food Actor" ; rdfs:subClassOf skos:Concept .

[VF: This might overlap with the agent relationships, where the role would be between 2 agents. But I think you mean each agent (food actor) is of a type? For agent types (so possibly food actor types), we are using subclassing, so Person and Group (and I hope Organization but not agreed to) are subclasses of Agent. Those can be further subclassed. Although in my mind, what you have below as FoodActorTypes are more roles than types. An agent might have more than one role, like be a FoodHub and a FoodDistributor. In LOD that is not so much of a problem, in other technologies, it might be? Or maybe you are thinking each FoodActor could have 1:m FoodActorTypes as roles? If so, maybe VF needs to support that in some way. Hope that wasn't hopelessly confusing.]

Very good point ! :)

so ofd:FoodActorType is mean to be the class, which instances will classify Actors/Agents(Persons or Groups). All its Individuals/Instances are just categories for foaf:Agent. This is indeed Roles as you suggested. Do you think FoodActorRole is more clear ? Btw I don't really see a need to subclass foafAgent more than Person and Groups as in reality it is just that the rest are Roles isn't it ?

[VF: Are these categories? Or ResourceTemplates? Or classes which will have instances that are food products, food services, etc.? If they are categories (they sound like it), seems like they can work basically as is, but not linking up with any template classes. You are just setting up your own taxonomy of resource categories, which VF doesn't have an opinion about, although maybe it would encourage people to use existing ones. Also I notice that only the food products are put into a hierarchy of categories. Not sure why the non-food and food service types would be different? Maybe we would need to discuss this a bit, I probably don't understand the vowl model well enough...]

So those are ResourceTemplates according to what we have agreed that categories will be more generic and well known that Templates. For example TransportService would have some specific data than SorageService for example. Also FoodProductType is a template for Food Resources where FoodType is a category for food.

If they are categories (they sound like it), seems like they can work basically as is, but not linking up with any template classes

Why categories would work but TemplateClasses wouldn't ?

ofd:offersProduct a owl:ObjectProperty ; rdfs:label "offersProduct" ; rdfs:domain foaf:Agent ; rdfs:range ofd:FoodProductType.

[VF: In VF this wouldn't be a direct relationship, it would be an Offer, with an agent, food product, action, and whatever else you wanted, like dates, etc. We haven't done a lot of examples of this yet. We want to try to mimic the commitments and events by using an Action verb, but I don't know if this will be too cumbersome. We could try it with your use case. :) And same comment for the next 2 offer properties.)

It depends how exactly would you define an Offer(as it is not yet clear for me in context of VF), but this is definitely not as direct relationship probably an Offer or Template for Offer. I see it as just stating here I am Producer A and I offer 5kg red hot chili peppers. Examples would bre great indeed :)

ofd:producedBy a owl:ObjectProperty ; rdfs:label "producedBy" ; rdfs:domain ofd:FoodProductType; rdfs:range foaf:Agent .

[VF: Not sure where to take this one; in a full implementation, this would be part of the IPO history. But it would apply to an actual resource, not a resource template. Yours means it is generally produced by, or sometimes produced by, or? Would you have different instances of the food product if there are different producers?]

For example, you have FoodHub A which offers Template [5kg red hot chili peppers] and this is beacuse you have an agreement with Farmer1 who produces those, so those are actually "produced By that Farmer". Now when consumerX buys your things from a webshop, by accepting his request you commit to deliver those and then a Resource(Instance) of [5kg red hot chili peppers for ConsumerX] is created goes with the Flow. It is of course form template [5kg red hot chili peppers], which we know where it is produced. Of course this is can be without a template but in those transparent Food Chains I imagine it is nice to know where the products come form in the planning stage. I hope I was not too confusing :)

[VF: This would be the recipe I think, which in the UML is the ResourceTemplate, EventTemplate, ProcessTemplate. So it would include quantities of each input and output food product, as well as other inputs including work (optionally). Here is an example: https://docs.google.com/presentation/d/127Tplhg-XtEJjxSftzhcfmhjHxLsz7wZmeQly8a8BfA/edit#slide=id.g1081630ddf_0_51, second slide. Unfortunately that one doesn't get down to the actual food inputs. I think you could create this as a really simple recipe using VF, eliminating most of the detail - depending on its purpose.]

Well this is more like vf:contains which I will change to. Ffor example Resource VeggieBox for Y contains different vegetables. However the Process template is very nice and I need to explore this more in in details.

[VF: All of these seem like in VF they might be vf:Relationship again. It would be interesting to compare your structuring of it with ours (vf:subject, vf:relationship, vf:obect) among the LOD literate. The relatedService is interesting though, and not part of vf:Relationship, although it could be. There was a long gitter chat with Paul Mackay about that today. We were calling it Relationship++ because it includes the resource related info (probably vf:category). I think he ended up thinking he would try Intent for what seems like a similar concept to yours. Something along the lines of Agent X offers ofd:ServiceHosting to Agent Y, but using the vf:action verb instead of offers; let's see what he comes up with.]

Indeed these now are THE relationships :). IMO the best way to relate Subject and Object is predicate :)which is essentially RDF. Indeed I add optional Concept in that relationship so it can bring more Context if needed. I think also @elf-pavlik mentioned he wanted something similar. About the vf:Action I would love to see more examples @pmackay what exactly do you have in mind ?

thanks @fosterlynn for the feedback! :)

djodjoni commented 7 years ago

Another question related to Offer as we mentioned here. Would you see a use of OfferTemplate for example and offer with unknown duration, validity actors etc? Or probably looking it from another angle: does Offer(Intent) belongs to the Recipe layer or planning (where there is Commitment) ?

elf-pavlik commented 7 years ago

I haven't had time to read the whole thread, just quickly responding to last comment

Or probably looking it from another angle: does Offer(Intent) belongs to the Recipe layer or planning (where there is Commitment) ?

I currently look at Intents as something that leads to Events with possible commitments in between, as on this diagram:

copy of process-oriented flow

To get something similar to http://schema.org/Offer & http://schema.org/Demand I would look at creating ExchangeTemplate (so we get to Recipes here) which would include reciprocal pair of intents to issue (eg. particular food product) and receive (eg. cash but could support barter for other products, or exchanges including work, usage, services etc.) https://github.com/valueflows/intent/issues/5

Just as Templates in Process recipes can scale (eg. x5) exchange templates also should have a way to scale (eg. x5)

The whole part including intents, Conversation for Action etc. still needs quite a bit of work.

fosterlynn commented 7 years ago

The whole part including intents, Conversation for Action etc. still needs quite a bit of work.

Yes indeed it does. :)

Or probably looking it from another angle: does Offer(Intent) belongs to the Recipe layer or planning (where there is Commitment) ?

I currently look at Intents as something that leads to Events with possible commitments in between, as on this diagram:

:+1:

fosterlynn commented 7 years ago

@djodjoni

For example the current category menus of Producers and Shops are actually the vf:Category and those are part of their data/knowledge base, those Actors will not change their data but may well reference to the global ones or other custom ones.

Yes, I agree, VF can encourage people to use or map to the standard category taxonomies, but if people have their own already, or want to define their own for whatever reason, I think we should support all equally.

foaf:member is a group to agent relationship indeed so all subclasses goes in here.

A side note: groups can be members of groups too. This is true in Freedom Coop and Sensorica, for example. (Not sure how foaf defines it.)

one nice article about that is https://www.w3.org/2009/12/rdf-ws/papers/ws21

thanks :blush:

so ofd:FoodActorType is mean to be the class, which instances will classify Actors/Agents(Persons or Groups). All its Individuals/Instances are just categories for foaf:Agent. This is indeed Roles as you suggested. Do you think FoodActorRole is more clear ?

So, do I understand you correctly? An instance of say some foodhub who also does transportation would be an instance of Group. Instances of FoodActorRole (or Type, I think either is fine as long as they aren't subclasses of Agent) would be labeled say "Foodhub" and "FoodTransporter". The group foodhub would maybe reference those instances of FoodActorRole as their ofd:role or something like that?

Btw I don't really see a need to subclass foafAgent more than Person and Groups as in reality it is just that the rest are Roles isn't it ?

Yes. (Except the possibility of adding Organization.)

Why categories would work but TemplateClasses wouldn't ?

I don't remember why I thought that. :( What I hear you saying then is that for food, you want to use more general categories; while for non-food items and services, they will be more specific things, possibly produced only by one agent. If so, I get it now. Although I'm still not sure I would want to limit those in that way.

fosterlynn commented 7 years ago

@djodjoni I'm still working through the conversation above.... :)

For example, you have FoodHub A which offers Template [5kg red hot chili peppers] and this is beacuse you have an agreement with Farmer1 who produces those, so those are actually "produced By that Farmer". Now when consumerX buys your things from a webshop, by accepting his request you commit to deliver those and then a Resource(Instance) of [5kg red hot chili peppers for ConsumerX] is created goes with the Flow. It is of course form template [5kg red hot chili peppers], which we know where it is produced. Of course this is can be without a template but in those transparent Food Chains I imagine it is nice to know where the products come form in the planning stage. I hope I was not too confusing :)

I'm going to try to reflect back how I would see this in VF, but it is going to involve going deeper into the model, below the "top/template/recipe" layer. Might be too much for your initial scope, I don't know. But here goes. So, I think "red hot chili peppers" can be a template (or category), but 5kg of them is not, it is an offer (Intent), and is on the "plan" layer. (Right now I am using template==type, the thing on the "top" layer.) The offer will include the quantity and refer to the template, and to Farmer1. For this offer, FoodHub A knows where the 5kg will come from, based on a general agreement with Farmer1. Or in a similar scenario, FoodHub A could know this because of a commitment (which we can think of as a specific agreement), or even event from Farmer1 which already delivered them to FoodHub1.

When ConsumerX orders lets say 1kg of red hot chili peppers based on your offer, there is a commitment from FoodHubA to give (for lack of a better word at the moment) ConsumerX those chili peppers, and a commitment from ConsumerX to give FoodHubA whatever they agree on in reciprocity. There is also whatever processes are needed to get the chili peppers from Farmer1 to FoodHubA, if they are not there already. Farmer1 could have to start by putting seeds in the ground, who knows. Unlikely in the case of food because it takes too long, but this often happens in manufacturing.

[edit] Referring to #185 because I think you and Pavlik are thinking of templates in the same way. I'll add some thoughts over there. I still think we need both.

elf-pavlik commented 7 years ago

For example the current category menus of Producers and Shops are actually the vf:Category and those are part of their data/knowledge base, those Actors will not change their data but may well reference to the global ones or other custom ones.

Yes, I agree, VF can encourage people to use or map to the standard category taxonomies, but if people have their own already, or want to define their own for whatever reason, I think we should support all equally.

We don't have to define rdfs:range for vf:category which would allow anything (all instances of owl:Thing which includes any possible instance), this way vocab supports using any URI as category. At the same time we should provide guidance that possibly internally defined self defined categories will not get recognized by any other agent so they serve only for 'internal' tags to agent who defined them.

If 'self defined' categories 'extend' some common Taxonomy, in practice other agents will match based on those common Taxonomies, while we still don't have clear mechanism to define such 'extended' categories. I think agents may want to follow approach similar to Materialized Inferences and reference those common categories directly.

Actors will not change their data but may well reference to the global ones or other custom ones.

While we don't have defined way to 'extend' common categories. Instead of having those 'extended categories' referencing 'common categories' whatever instance would reference that 'extended category' can also directly reference those 'common categories' as well.

fosterlynn commented 7 years ago

About the vf:Action I would love to see more examples

This is what we have as of now, copied from the release doc. But it tends to grow. It will appear in events and commitments, and we hope intents. It defines in some ways the "type" of event, how the event behaves.

vf:use - for example a tool used in process, after the process, the tool still exists [may go away in favor of the usage being a resource in itself]
vf:consume - for example an ingredient composed into the output, after the process the ingredient is gone
vf:cite - for example a design file, neither used nor consumed, the file remains available at all times
vf:work - labor power towards a process
vf:accept - in processes like repair or maintentance, same resource will appear in output with vf:improve verb
vf:load - transported resource enters the process
vf:produce - new resource created in that process
vf:improve - in processes like repair or maintentance, same resource will appear in input with vf:accept verb - I think we changed this to vf:change?
vf:unload - transported resource leaves the process

Here's some more we have discussed since:

vf:issue
vf:receive
vf:service, or vf:provideService, or vf:provide, or something for service as an output event

If we ever do transfers (no process involved at all), we could have vf:give and vf:take, but we are not anywhere near figuring that out.

elf-pavlik commented 7 years ago

vf:service, or vf:provideService, or vf:provide, or something for service as an output event

I remember discussing service as event that can connect/bridge two processes directly (so no resource 'in between' output and input), so output and/or input event (not just as an output event)

fosterlynn commented 7 years ago

I remember discussing service as event that can connect/bridge two processes directly (so no resource 'in between' output and input), so output and/or input event (not just as an output event)

I stand corrected, and that is where I'd like to go with that one rather than creating some service resource.

pmackay commented 7 years ago

I'd just like to dig a bit more into the definition of new classes. Partly also cos its pertinent to VF too and I'm trying to understand where there are strong benefits to defining new terms vs reusing :)

FoodType wich is essentially subclass of vf:Category

In what ways does a new class help for OFD? Could it just be that you define a constrained set of terms that are used, but their class could still be vf:Category?

For the names of all the classes, if new classes are defined, do they all need to start with "Food"? Can that be inferred from the namespace/use of the OFD vocab generally? (I could see dropping the prefix aligning more closely with OFN BTW)

djodjoni commented 7 years ago

Ill start with the last one :)

In what ways does a new class help for OFD? Could it just be that you define a constrained set of terms that are used, but their class could still be vf:Category?

So we agree that in any case, one needs set define some set of terms that they use :) So in OFD their class is essentially Category the subclassing is for clarity and easiness when you define new "categories".

so I do

 ofd:FoodType a owl:Class ;
rdfs:subClassOf skos:Concept , vf:Category .

in order to be able to do:

ofd:Meat a ofd:FoodType ;

which I can also write as:

ofd:Meat a skos:Concept , vf:Category ;

On top of that, you can add some extra values specific to food types such as min/max temp, season etc. I cannot say this is better but it is easier for me. If you have some suggestions please dig into it more :)

As for subclassing and why I use SKOS. When you create a FoodHub for example, I can create my own taxonomy (as I probably had one alredy) it is OK to be different as the bookmarks classifications we have, but I wouldn't create subclass hierarchies rather Concept hierarchies as it better fits building taxonomies of this sort.

So In other words, I do not expect to see more subclasses of Category/FoodType but more Concepts of it which can then be related in various ways while classes relations in OWL are quite limited.

This is again purely Linked Data specific when you implement it and create you 'Model' in some programming language different rules, considerations and practices may apply. For example in Java most of people use Enums, those however could be a memory overkill for embedded devices thus one may use simple double array of primitives.

For the names of all the classes, if new classes are defined, do they all need to start with "Food"? Can that be inferred from the namespace/use of the OFD vocab generally?

the namespace can definitely be used so you talk about FoodActorType, FoodProductType and FoodServiceType and all the narrower concepts (as in the other 2 'Food' has actual meaning there) ?

djodjoni commented 7 years ago

@elf-pavlik

To get something similar to http://schema.org/Offer & http://schema.org/Demand I would look at creating ExchangeTemplate (so we get to Recipes here) which would include reciprocal pair of intents to issue (eg. particular food product) and receive

What if the food product is not that particular for example a Farmer may generally offer Apples but the price nor the stock qty are known would you still consider as an Offer? Of course, the idea here is that when a Hub/Consumer finds an offer negotiations can happen leading to more concrete Offer followed by Commitments, etc.

pmackay commented 7 years ago

So we agree that in any case, one needs set define some set of terms that they use :)

We might be coming at this from slightly different perspectives :) Perhaps this is also related to centralized vs decentralized. I was thinking, when building an app, you would need to create a specific set of categories. These could come from Agrovoc or Wikidata, but you would select the relevant ones. So why not use http://aims.fao.org/skosmos/agrovoc/en/page/c_4680 or https://www.wikidata.org/wiki/Q10990, rather than defining a new term?

However, if you want a separate constrained vocab on the web and reference it via a SPARQL or other LD lookup, I could see more logic to having your own taxonomy - is that more how you're seeing it?

But, to achieve better reuse, could you use a skos:Collection to define your taxonomy and simply include a bunch of terms from Agrovoc, etc?

djodjoni commented 7 years ago

why not use http://aims.fao.org/skosmos/agrovoc/en/page/c_4680 or https://www.wikidata.org/wiki/Q10990, rather than defining a new term?

I am not saying 'NOT' to that :) but if you have a lot of terms and ones which are differnt/extra from the common ones it might be easier to manage those in your won separate thesaurus.

However, if you want a separate constrained vocab on the web and reference it via a SPARQL or other LD lookup, I could see more logic to having your own taxonomy - is that more how you're seeing it?

Yes, I believe for most of the cases this could be the case.

But, to achieve better reuse, could you use a skos:Collection to define your taxonomy and simply include a bunch of terms from Agrovoc, etc?

Not relly becuase you need levels, probably relate to some more Things on the web line wikidata Items, schemaOrg Things and Dbpedia whatever.

Btw

We might be coming at this from slightly different perspectives

what is your perspective ? :)

elf-pavlik commented 7 years ago

so I do
ofd:FoodType a owl:Class ;
rdfs:subClassOf skos:Concept , vf:Category .
in order to be able to do:
ofd:Meat a ofd:FoodType ;
which I can also write as:
ofd:Meat a skos:Concept , vf:Category ;

First of all I don't think we have to define vf:Category and could possibly just rely on skos:Concept. Second it seems that ofd namespace mixes vocab/ontology with taxonomy.

ofd:FoodType - part of ontology
ofd:Meat - part of taxonomy

If some coopx: already has their own definitions of food categories, why they would map it to taxonomy in ofd namspace instead directly mapping them to more established Wikidata or Agrovoc taxonomies?

pmackay commented 7 years ago

We might be coming at this from slightly different perspectives

I just mean perhaps we're thinking differently about how this might be realised in SW. For example, OFN is "centralized" - the taxonomy terms are saved in the db as Spree config. So it is by nature constrained because someone has to select what terms to use, even if they were to use exactly terms from Agrovoc (which they dont). Agrovoc would not work for OFN because its too large.

What would be neat is some form of taxonomy commons that would allow a small, simple taxonomy for apps like OFN to be built by selecting and adding to terms from Agrovoc and then have tools to serve as SKOS or download as CSV for import into OFN (or similar app). Anyone know of a good tool like that? I've scanned a few taxonomy tools but they all seem a bit non-web/hard to use....

bhaugen commented 7 years ago

This is a sidelight to your conversation above, but it might help to consider one of the reasons that food networks might want to use something like VF and LOD: lot tracking and tracing. Especially when batches of food cross from one food network to another.

We worked with one food network when the mad cow scare was happening, and another when e-coli was appearing in lettuce. In both cases, it was necessary to be able trace back to the source animal or field. The tracing needs to be able to follow the resource flows backward from where the problem was detected, through chains of exchanges and processes, to where the lot originated, and then track forward again, to wherever parts of the lot went.

Such tracking and tracing require some common vocabulary of resource identification as well as common understandings of relationships between economic events, exchanges, and processes. In the commercial world, in the US, this common understanding is mandated in FDA good manufacturing practice rules.

djodjoni commented 7 years ago

@pmackay cool :)

I just mean perhaps we're thinking differently about how this might be realised in SW. For example, OFN is "centralized" - the taxonomy terms are saved in the db as Spree config. So it is by nature constrained because someone has to select what terms to use, even if they were to use exactly terms from Agrovoc (which they dont). Agrovoc would not work for OFN because its too large.

Exactly ! This is why in the example here https://github.com/valueflows/valueflows/issues/186#issuecomment-282778056

the shops use custom terms.

What would be neat is some form of taxonomy commons that would allow a small, simple taxonomy for apps like OFN to be built by selecting and adding to terms from Agrovoc and then have tools to serve as SKOS or download as CSV for import into OFN (or similar app). Anyone know of a good tool like that? I've scanned a few taxonomy tools but they all seem a bit non-web/hard to use....

indeed . I am actually trying to do now in for specifically for wordpress now. I also haven't find any 'useful' tools I personally can generate stuff quite fast with Jena, but i'd love to have nice web interface :)

djodjoni commented 7 years ago

@elf-pavlik

Second it seems that ofd namespace mixes vocab/ontology with taxonomy.

yes it has ontology classes as well as a minimum set of base Concepts which can be defined as well as NamedIndividual in order to be used along with the ontology. I am not sure however if this is needed .

djodjoni commented 7 years ago

@bhaugen thx for the link !

@elf-pavlik another thing I forgot to answer (on a larger screen I see more :)

If some coopx: already has their own definitions of food categories, why they would map it to taxonomy in ofd namspace instead directly mapping them to more established Wikidata or Agrovoc taxonomies?

The thing is that they should use Wikidata or Agrovoc or others. I mean for OFD to be used with those and to have basis for describing food related Things, not to define another generic Taxonomy and compete with Agrovoc.

The FoodTypes base Concepts(like Meat) I have put there in order to provide a 'bootstrap' to create food category list as Agrovoc and Wikidata(even more) are too complicated for most of the needs a specific software has. Right now I am dropping this idea rather use tools to create/map custom taxonomies out of those still based on the OFD's few extended root Concepts.

Again the main idea behind those root Concepts/Classes is to use the SKOS and the extended OFD semantic relation properties in the various applications to build a simple hierarchy specific for one's needs but in a 'similar manner'.

For now this is the best way I have thought of to handle at the same time the uniqueness and the linking of various taxonomies.

elf-pavlik commented 7 years ago

I guess everyone on this issue also have seen this comment https://github.com/ouisharelabs/food-dashboard/issues/1#issuecomment-283310608

It think we should coordinate with http://datafoodconsortium.org/ and work with existing platforms already deployed and used by people. This way we will make sure we cover all the existing use cases. I'd like to organize call with developers of

http://openfoodnetwork.org/ @pmackay (as well as Myriam)
https://www.foodcoops.net/ (Foodsoft)
http://www.katuma.org/ @enricostano
http://cobuy.nz/ ? @ahdinosaur
http://www.cagette.net/
??? @djodjoni

We could focus on use-case where producers and distributors manage their inventories using accounts on any number of many different platforms but they still want to have possibility that any producer can supply any distributor no matter which platform they use to manage their inventories and orders. IMO working just with use cases of centralized silo will not help us with facing the main challenge of ValueFlows where we want to allow interoperability between autonomous instances powered by many different software stacks.

fosterlynn commented 7 years ago

I'd like to organize call with developers

@elf-pavlik I think that would be amazing. It would be really good to see how VF can help with this ongoing work in food. And I agree with the use case, needs to want some interoperability.

@djodjoni you are involved with all of this, what do you think?

djodjoni commented 7 years ago

I totally agree that this would be amazing. i wanted this for a long time :)On 1 Mar 2017 17:01, Lynn Foster notifications@github.com wrote: I'd like to organize call with developers

@elf-pavlik I think that would be amazing. It would be really good to see how VF can help with this ongoing work in food. And I agree with the use case, needs to want some interoperability. @djodjoni you are involved with all of this, what do you think?

—You are receiving this because you were mentioned.Reply to this email directly, view it on GitHub, or mute the thread.

almereyda commented 4 years ago

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/93.

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

valueflows / forum.valueflo.ws

basic food vocab based on VF #93

[VF: ??]