singnet
Enhanced Service metadata
As we look to refactor the DApp we would like to capture more metadata about a service so that we can provider richer information to the end users on our clients. Additional information that we would like to capture
- A hero image for the service which is a visual representation of the service
- A category to group the service. Ideally this should be a list the platform exposes and the service developer can assign to the relevant category
- Documentation / Tutorial in markdown - #176 captures
- Version and license type
- Image gallery if more images help describe the service better
Related issue #173
cc @astroseger @ferrouswheel @arturgontijo
If we store all documentation directly in IPFS metadata (not as simple link to github wiki, but directly in metadata) then each change in documentation will force change in on-chain registry. @raamb or it is what you want for sake of curation?
@raamb , how category is different from tag?
Not all that different, as I understand its a way to group services under a standard classification. We could always make the case that we can just use tags and dont need an explicit category as such
If we store all documentation directly in IPFS metadata (not as simple link to github wiki, but directly in metadata) then each change in documentation will force change in on-chain registry. @raamb or it is what you want for sake of curation?
Yes, we need this for the sake of curation.
-
hero image / image gallery - can this be stored on ipfs or provided by the daemon? Would be good to avoid the service author needing to host it somewhere (for the same reasons I'm keen for the documentation published to IPFS).
-
category - I think tags are better at the service metadata level. The marketplace might have some category system that we curate, but it seems unnecessary to add this. How will we prevent people creating new categories? I think a big problem with the current tagging is that people used really bizarre tags.... like using "action" and "selection" instead of "action-selection". one guidance might be to confirm with user if they are sure the tag is useful before the service is published. if it's the only service with the tag, then the marketplace could filter the tag to get rid of the tags that have no value.
-
version needs to have some semantic info so that people can determine whether a version change breaks the API. they could partly determine that from the protobuf model spec, but implicit behaviour of the service might have changed. it'd be nice if the cli would automatically increment the version and ask the user to confirm, for obvious changes, like a changed model, or a change of pricing strategy. Basically anything that will break the service for downstream users.
-
what is the license going to be? a free text field for the full LICENSE file, or a short string like "MIT", "GPL" etc. Does this make sense for a service? The service isn't providing code, so I'd be expecting a "Terms of Use" or "Privacy Agreement" more than a license.
- hero image / image gallery - can this be stored on ipfs or provided by the daemon? Would be good to avoid the service author needing to host it somewhere (for the same reasons I'm keen for the documentation published to IPFS).
Yes, the data will be stored in IPFS. The marketplace service will handle hosting by using an appropriate mechanism. The author does not need to worry about hosting.
- category - I think tags are better at the service metadata level. The marketplace might have some category system that we curate, but it seems unnecessary to add this. How will we prevent people creating new categories? I think a big problem with the current tagging is that people used really bizarre tags.... like using "action" and "selection" instead of "action-selection". one guidance might be to confirm with user if they are sure the tag is useful before the service is published. if it's the only service with the tag, then the marketplace could filter the tag to get rid of the tags that have no value.
Agree with this.
- version needs to have some semantic info so that people can determine whether a version change breaks the API. they could partly determine that from the protobuf model spec, but implicit behaviour of the service might have changed. it'd be nice if the cli would automatically increment the version and ask the user to confirm, for obvious changes, like a changed model, or a change of pricing strategy. Basically anything that will break the service for downstream users.
For starters we will accept a version from the developer, this can be an optional field meaning that the user does not necessarily need to provide it. In subsequent iterations, we can explore the option of having the snet-cli increment version of the service
- what is the license going to be? a free text field for the full LICENSE file, or a short string like "MIT", "GPL" etc. Does this make sense for a service? The service isn't providing code, so I'd be expecting a "Terms of Use" or "Privacy Agreement" more than a license.
This is a great point. I agree that we convert this to Terms of Use.
Hi guys. this is Greg the UX designer working with @raamb team
- Joel's comment category - I think tags are better at the service metadata level. The marketplace might have some category system that we curate, but it seems unnecessary to add this. How will we prevent people creating new categories? I think a big problem with the current tagging is that people used really bizarre tags.... like using "action" and "selection" instead of "action-selection". one guidance might be to confirm with user if they are sure the tag is useful before the service is published. if it's the only service with the tag, then the marketplace could filter the tag to get rid of the tags that have no value.
The UX goal was to have a way for users on the marketplace to browse/search/view a collections of ai services. Yes, this is more for the marketplace curation level. For my designs, I going for that each AI service would have primary category (single) with any additional categories would be secondary (could be 0 or multiple). From the Card / List view of the AI services, we wanted to display the primary categories and also allow users to filter by these. Each AI service will have a profile page that will have the full summary description, install / run instructions, tutorials, review info and also additional meta data like secondary categories.
Are categories actually just tags? sure, you can call them tags. Do we want custom tags. No, not really. We could offer controlled tag system and a limited customized one (probably used for another reason) As you see current on DAPP, people are already abusing the custom tags to be very useless and confusing. There is also a risk of redundant tags.
When a service provider publishes their AI service with use, I believe we should give them a list of primary categories/tags to choose from that best describes their service. If they don't choose a category then, it will either default to "miscellaneous" or "other". The secondary categories would be other categories the service may overlap into or service provide thinks it is also associated with. I think the secondary category could be multiple items or tags. This would be controlled list as well OR we can allow users to submit a single custom one (but this may have to be reviewed by SNET reviewers).
The goal for the curation of the marketplace is NOT to have a 1,000 tags/categories. These tags/categories will be tied into filter mechanism on the site as well a future search functions. If we have more than 15 categories, the UI / UX will hide any categories after 15 (users will have to click More to see more). From the UX standpoint, I was thinking we start with 8 - 15 categories.
What is this the current list of categories? I'll leave that up to SNET group to decide what the final list be. My designs have 8-9 items that I found to describe a majority of services. I based these category labels on what I have seen other similar marketplaces and our current DAPP beta.
Can this category list change over time? Yeah sure. It probably should slowly grow as the marketplace grows (not to a super large list where everything becomes a useless taxonomy system). I'm sure new categories will emerge, but I would say it should be determined by the SNET / reviewers of the AI services.
I think we should distinguish what the marketplace needs from what the platform needs. We need KYC for the marketplace anyhow, so users should be able log in and claim ai services and then assign them to categories or set other marketplace metadata config on the marketplace.
We shouldn't try to do this on the blockchain or even necessarily the tooling for a decentralized ecosystem of services. And unless we hard code the categories in the blockchain contracts or something, then people will still be able set whatever category they like because we don't have absolute control of the metadata upload process.
Maybe for convenience the client could set a category for a service via a marketplace API.
On Fri, 5 Jul 2019, 8:32 PM Greg, [email protected] wrote:
Hi guys. this is Greg the UX designer working with @raamb https://github.com/raamb team
- Joel's comment category - I think tags are better at the service metadata level. The marketplace might have some category system that we curate, but it seems unnecessary to add this. How will we prevent people creating new categories? I think a big problem with the current tagging is that people used really bizarre tags.... like using "action" and "selection" instead of "action-selection". one guidance might be to confirm with user if they are sure the tag is useful before the service is published. if it's the only service with the tag, then the marketplace could filter the tag to get rid of the tags that have no value.
The UX goal was to have a way for users on the marketplace to browse/search/view a collections of ai services. Yes, this is more for the marketplace curation level. For my designs, I going for that each AI service would have primary category (single) with any additional categories would be secondary (could be 0 or multiple). From the Card / List view of the AI services, we wanted to display the primary categories and also allow users to filter by these. Each AI service will have a profile page that will have the full summary description, install / run instructions, tutorials, review info and also additional meta data like secondary categories.
Are categories actually just tags? sure, you can call them tags. Do we want custom tags. No, not really. We could offer controlled tag system and a limited customized one (probably used for another reason) As you see current on DAPP, people are already abusing the custom tags to be very useless and confusing. There is also a risk of redundant tags.
When a service provider publishes their AI service with use, I believe we should give them a list of primary categories/tags to choose from that best describes their service. If they don't choose a category then, it will either default to "miscellaneous" or "other". The secondary categories would be other categories the service may overlap into or service provide thinks it is also associated with. I think the secondary category could be multiple items or tags. This would be controlled list as well OR we can allow users to submit a single custom one (but this may have to be reviewed by SNET reviewers).
The goal for the curation of the marketplace is NOT to have a 1,000 tags/categories. These tags/categories will be tied into filter mechanism on the site as well a future search functions. If we have more than 15 categories, the UI / UX will hide any categories after 15 (users will have to click More to see more). From the UX standpoint, I was thinking we start with 8 - 15 categories.
What is this the current list of categories? I'll leave that up to SNET group to decide what the final list be. My designs have 8-9 items that I found to describe a majority of services. I based these category labels on what I have seen other similar marketplaces and our current DAPP beta.
Can this category list change over time? Yeah sure. It probably should slowly grow as the marketplace grows (not to a super large list where everything becomes a useless taxonomy system). I'm sure new categories will emerge, but I would say it should be determined by the SNET / reviewers of the AI services.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/singnet/snet-cli/issues/259?email_source=notifications&email_token=AAA5MB2S5FOGARTO3IVSEZLP54BILA5CNFSM4H2MFVD2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZI5FFY#issuecomment-508678807, or mute the thread https://github.com/notifications/unsubscribe-auth/AAA5MB7XCOMFTLPTA5YDKVLP54BILANCNFSM4H2MFVDQ .