Adding, thinking again about it, I think Product is too limited, there are also services for example.
cc @sir
Unless we have flexibility in the spec to point to the VF ResourceSpecification or the c07e Product (or schema.org Product)?
Checking while Iām looking around, what do you think about accountingUnit ?
How ResourceSpecification document should look like? Is there an example?
Feels a bit too broad / vague.
(i might be shooting myself in the leg), Product does make me feel limitedā¦ in a way.
the nice thing though is that there is a finite number of types like Product we can add to fill in the gap to represent a slightly more targeted use case for ecommerce implementers, such as Contract, Service, etc. Once we fill all of them in, we are covered.
however, outside of the scope of ecommerce (idk if i have thought this enough yet), i āthinkā there might be infinite different types, for example, Access for libraries or Lesson from teachers, etc.
the reason why i say this is that, i might be mixing physical vs. non-physical concepts too much, Note, Article can be both physical or non-physical, same idea goes with Product vs. Service.
another way i could look at this type generics is that, i could see type: Article as in how the Object appears or can be rendered as on the web, purely based in visualization. for example, a chair can be rendered as a Article, with summary, dimension, or whatever the implementer wants to add.
to represent the concept of an object for its intrinsic type, i could add a field intrinsic_type, and this field can be defined by implementer for whatever they want.
for a chair:
{
"name": "wooden chair",
"summary": "chair made of wood by a historic fediverse user potato. alice donated it to the museum of history",
"type": "Article",
"intrinsic_type": "Installment",
"attributed_to": "https://example.com/users/alice"
}
This is basically about how to describe resources (mostly types of resources, but not exclusively).
A few general thoughts, and I will check in with some people with specific use cases in the next days, and also gather some varied real examples.
Returning to this. I agreed above with adding resourceConformsTo (or wherever we land) to the minimal example. Thinking again, the most minimal might be a description or image, and in fact a lot of the informal offers/wants apps use only that, also often with a name/title. Often this is the case with timebanks, mutual aid offers/wants, and marketplaces or gifting sites that have mostly used items. They might also have tags or set categories to help with search.
Then there is a continuum of needs for specificity up to very exact specifications for something that has to be exactly the right bolt or whatever for manufacturing, including open design and fablabs.
I would be interested in opinions about what is appropriate for the fediverse, given its historical start with micro-blogging and gradual expansion from there. But basically āsocialā thus far, whatever we think that means. Our experience is that āsocialā and āeconomicā tend to become intertwined. But when you get to larger manufacturing, or even local small batch manufacturing, people tend to develop set suppliers and whole supply chains, and arenāt often looking on a marketplace. On the other side, all kinds of manufactured consumer goods for sure appear on various kinds of marketplaces, could be āold one speed bikeā or ānew Schwinn model number 12345ā with a link to the Schwinn specification.
And same question for this FEP, how limited should it be?
Iād like to think more about what would be most useful for sticking to 2 examples.
I think this will become a losing battle, there are many layers, and many paths into this. From VF doc: āEconomic Resources would typically be useful goods and services, but could also be money, credits, energy, knowledge, designs, skills, CO2, pollutants, water, or almost anything else that some Agents can agree should be accounted for in their economic networks.ā And when you start getting into resource taxonomies, it is hard to get a good top level, people tend to wander into multiple inheritance if they can.
This is why VF (from REA) has a very generic model, with focus on normalizing economic activity, including exchange. So, specifically, that is why we have one class for specifying an economic resource and one class for an actual economic resource. Then we have a relatively undefined way to classify them, which certainly could be defined further, but there are many varied needs in that area.
Iād add that imho Article.intrinsic_type should be avoided as it adds protocol decay in a similar way that Group.isLemmyGroup would add, which Iāve seen proposed in a different context.
im not familiar with the concept of protocol decay, can u explain more?
Sure. It is well-described in one of the IETF documents on protocol design: https://www.rfc-editor.org/rfc/rfc9413.html#name-protocol-decay. I forgot to link that, which I usually do. The fediverse has protocol decay all over the place, which makes ActivityPub less and less useful as an interoperability protocol and increases the time devs have to spend in whack-a-mole development and maintenance (to fix continuous breakages). FEPās help mitigate this a bit, but is insufficient in itself.
2 Likes
cool. now i agree using intrinsic_typeisnāt a great idea due to protocol decay. soā¦ mentally regarding the current object type the way as they are as a form of rendering preference is good enough. iāll try to implement VF in a POC to see how it works then.
1 Like
I made some proposed changes to the 2 examples in the FEP (minimal and full). Notes on what and why:
- I made the minimal one basically text-based, that is the case with some offers/requests apps.
- But I added the reciprocal side, if youād rather have that not there for the minimal example, I can take it back out. Seemed to me most marketplaces would want some kind of pricing, exceptions being timebanks and gifting apps.
- Took out OM2, that was pulled into VF namespace, subclassing OM2 properties. (Sorry had forgotten to convey that eariler.)
- Pulled all the text in the minimal into the
content, donāt know if apps would generate that or not? Like for apps rendering as Note? - Put ResourceSpecification properties in for resourceConformsTo. Do we need/want the type and id in there too? I noticed you donāt have for Measure quantities, but those donāt have any reason to access them directly. I still have a bunch of research to do in this area, it looks like in the (not finished I think) EU Digital Product Passport spec, there is an option for a url in addition to the GS1 identifier for products. And I donāt know how the need for global (or at least cross network) identification of resource types will develop, but it seems like for now, that is a ways off for the fediverse if ever?
- I made the full one unitBased so we have an example of that.
This also means we would make resourceConformsTo and resourceQuantity optional.
Your thoughts?
Minimal:
{
"@context": [
"https://www.w3.org/ns/activitystreams",
{
"vf": "https://w3id.org/valueflows/ont/vf#",
"Proposal": "vf:Proposal",
"Intent": "vf:Intent",
"action": "vf:action",
"purpose": "vf:purpose",
"publishes": "vf:publishes",
"reciprocal": "vf:reciprocal",
"note": "vf:note"
}
],
"type": "Proposal",
"id": "https://market.example/proposals/ddde9d6f-6f3b-4770-a966-3a18ef006930",
"purpose": "offer",
"attributedTo": "https://market.example/users/alice",
"name": "Offering used bike",
"content": "Blue one-speed bike, 15 years old, some rust. Near downtown Madison. $30 or best offer."
"publishes": {
"type": "Intent",
"id": "https://market.example/proposals/ddde9d6f-6f3b-4770-a966-3a18ef006930#primary",
"action": "transfer",
"note": "Blue one-speed bike, 15 years old, some rust. Near downtown Madison.",
},
"reciprocal": {
"type": "Intent",
"id": "https://market.example/proposals/ddde9d6f-6f3b-4770-a966-3a18ef006930#reciprocal",
"action": "transfer",
"note": "$30 or best offer.",
},
"to": "https://www.w3.org/ns/activitystreams#Public"
}
Full:
{
"@context": [
"https://www.w3.org/ns/activitystreams",
{
"vf": "https://w3id.org/valueflows/ont/vf#",
"Proposal": "vf:Proposal",
"Intent": "vf:Intent",
"action": "vf:action",
"purpose": "vf:purpose",
"unitBased": "vf:unitBased",
"publishes": "vf:publishes",
"reciprocal": "vf:reciprocal",
"resourceConformsTo": "vf:resourceConformsTo",
"resourceQuantity": "vf:resourceQuantity",
"availableQuantity": "vf:availableQuantity",
"minimumQuantity": "vf:minimumQuantity",
"hasUnit": "vf:hasUnit",
"hasNumericalValue": "vf:hasNumericalValue"
}
],
"type": "Proposal",
"id": "https://market.example/proposals/ddde9d6f-6f3b-4770-a966-3a18ef006930",
"purpose": "offer",
"attributedTo": "https://market.example/users/alice",
"name": "Local organic carrots",
"published": "2023-06-18T19:22:03.918737Z",
"location": {
"type": "Place",
"longitude": -71.0,
"latitude": 25.0
},
"unitBased": "true",
"publishes": {
"type": "Intent",
"id": "https://market.example/proposals/ddde9d6f-6f3b-4770-a966-3a18ef006930#primary",
"action": "transfer",
"resourceConformsTo": "{
"name": "Orange carrots, organic, grade A",
"image": "https://market.example/resources/ddde9d6f-6f3b-4770-a966-r98jewx230o9#image"
},
"note": "Great quality with all the rain, harvested yesterday.",
"resourceQuantity": {
"hasUnit": "pound",
"hasNumericalValue": "1"
},
"availableQuantity": {
"hasUnit": "pound",
"hasNumericalValue": "150"
},
"minimumQuantity": {
"hasUnit": "pound",
"hasNumericalValue": "5"
}
},
"reciprocal": {
"type": "Intent",
"id": "https://market.example/proposals/ddde9d6f-6f3b-4770-a966-3a18ef006930#reciprocal",
"action": "transfer",
"resourceConformsTo": {
"name": "USD"
},
"resourceQuantity": {
"hasUnit": "currencyAmount",
"hasNumericalValue": ".89"
}
},
"to": "https://www.w3.org/ns/activitystreams#Public"
}
cc @sir
1 Like
I think we should keep resourceQuantity. Applications could use ā1 itemā as a default.
The minimal example is supposed to have only REQUIRED properties, so only primary intent is included.
In real-life federated markets giving things for free is common. Hereās a random example from flohmarkt:
Yours for the cost of shipping.
I am not sure. If descriptions of intents are required, top-level name and content should probably be optional.
In Fediverse, type is usually present even if id is not.
It seems that resourceConformsTo and note serve the same purpose:
{
"resourceConformsTo": {
"name": "Blue one-speed bike, 15 years old, some rust. Near downtown Madison."
}
}
Tangential. The practice to map all properties to avoid namespace prefixes in JSON keys triggered me to write a post on Practices around JSON formatting of JSON-LD messages.
1 Like
Is this a FEP guideline? Iām fine taking out the reciprocal, Iāll do so before my next version. But curious why that is so?
Point taken. Nice to see flohmarkt in action, thanks!
In general, Iām struggling a bit here, because Iām trying to accommodate different use cases, which maybe I shouldnāt be so much? So for this, the note accommodates informal text-based marketplaces; resourceConformsTo accommodates more formal situations where the exact type of resource matters, and it being machine readable matters. There will be production oriented apps that want to do that, and note will be incidental; but even if someone is just looking for a specific part to fix their snowblower, the exact resource type will be important. So Iād be fine requiring one of: name, note, resourceConformsTo, but that gets more complicated, is it OK to just leave that to the app, and leave all optional?
I think I should just take out the content in the example, and I guess it should be optional anyhow. Proposal name too.
More later, still thinking about the restā¦.
1 Like
This is just my understanding of āminimal exampleā: an object than contains only required properties 
Having a āone ofā requirement sounds like a good idea. I think proposer MUST specify what is being proposed, one way or another.
I am not sure about resourceConformsTo vs note, though. I would prefer a single property that can contain anything from a simple text description to a complex object with many fields (e.g. Product).
FEP update: https://codeberg.org/fediverse/fep/pulls/816
- Removed om2 from
@context. - Updated full example to be unit based.
- Added flohmarkt and Fedify to implementation list.
Fedify is a toolkit for developers, so there is nothing to see yet. But some flohmarkt instances already updated to the latest version and we can look at published Proposals:
https://kleinanzeigen.bonn.digital/~bonndigital/48a0e2b7-f0d0-421b-9190-cc15306be6a3
1 Like
@silverpill Weirdly, I canāt find where we talked about currencyAmount, etc. So apologies for not connecting up the conversation.
I was talking about this new unit taxonomy I learned about from the UN. I finally got through the whole list, and have another proposal for the currency problem: monetaryValue. I donāt have a personal preference, just trying to stay within existing standards if possible, and am more comfortable adding a standard, or some specific units from a standard than adding one we made up within the fediverse.
EDIT: In VF, a group can always create their own label and symbol for a unit from the standard. That gives some flexibility, and is actually necessary for a lot of standard units. Then the unique id of the unit in the taxonomy provides the matching capability between networks/groups.
If there is an existing standard, I would also prefer to borrow a unit name from it. What is that standard?
It is this one https://untp.unece.org/docs/0.6.0/specification. But itās under development. The units are here unece:UnitMeasureCode. Not a very clean list, sort of random. But lots of things that we donāt have in the scientifically driven units of measure that we initially investigated some years ago, that would be useful.
I need to do a bunch of digging to see what is what, and connected to what, and at what stage, within this set of standards. We ran into it looking again at the EU DPP (Digital Product Passport) specs that are also still unfinished or at least unstable. But VF is ideal for DPP, even though VF and our fans have very little influence, possibly zero. And DPP is referencing this UN standard.
It wonāt be super quick to decide for VF probably. But that doesnāt mean implementations canāt start to experiment and use what works best for them, getting as close to the future as possible.
That said, Iāll try to get enough research done to have a sense of it, and report here.
1 Like
Am I understanding it correctly that they use M4, not monetaryValue?
Good question. I actually havenāt dug far enough to see if they have machine readable stuff, and if so what properties are available, and format it is. Iāll do that and report back here.
Iām also thinking about what all needs to be done on the VF end if we support multiple unit taxonomies, so that devs and others can easily access them.