Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Harmonize vocabulary #11

Open
Tracked by #70
CharlesNepote opened this issue May 7, 2021 · 6 comments
Open
Tracked by #70

Harmonize vocabulary #11

CharlesNepote opened this issue May 7, 2021 · 6 comments

Comments

@CharlesNepote
Copy link
Member

In the API documentation we use:

  • mainly "tag"/"tags":
    • "Product Tags List"
    • "Product Tag"
    • "Product Tag Delete"
    • etc.
  • "k" and "v", with no explication of their meaning (=> key, value)

Tag, key/value

In the general public, a tag is only a keyword, not a combination of a property and a value. This meaning is shared by:

  • hashtags
  • microformats (where the rel-tag property is for decentralized tagging (Folksonomy) (source Wikipedia))

The OpenStreetMap community is using the "tag" term: A tag consists of two items, a key and a value (source). But OpenStreetMap mappers are often techies who know what is key and a value. A key is probably not very instinctive for Open Food Facts contributors.

Pros:

  • already use in OpenStreetMap community

Cons:

  • how to create simple tags (eg. (k="tag" and v="tobedeled") if the "tag" term is already used for the whole key/value pair?

Pair (or triple or triple tag), property, value

Pros:

  • property and value are easy to understand for the general public
  • these notions are used by the semantic web community
  • "tag" can be a property to allow simple tags (Eg. "tag" => "to be deleted")

Cons:

  • the name of the property/value pair is not very clear: a pair? a triple (like in the semantic web community)

Other?

@stephanegigandet
Copy link

I much prefer property and value. e.g. this product has the value "Green" for the property "Color". I don't see the need to introduce the notion of a pair (property + value). e.g. for the OFF API, we never say "you can set a pair of field + value", we just say that you can set the value for some field. Same here, we can read or write the value for a property.

@aadarsh-ram
Copy link
Contributor

I agree with @stephanegigandet. I had a confusion regarding 'k' and 'v' when I first tried using Folksonomy Engine. Renaming it as 'property' and 'value' would be much better, as it accurately conveys it's meaning. If required, the (property+value) pair could be named as a 'couple' instead. According to me, other people would be able to instinctively understand that a 'couple' = ('property' + 'value').

@CharlesNepote @stephanegigandet, does this make any sense?

@stephanegigandet
Copy link

Thanks @aadarsh-ram . Renaming k and v to property and value makes sense to me.

@puneeth072003
Copy link

hey i'm new to this community where shall i start

@puneeth072003
Copy link

Can i get any guidance, like what should i learn then how can i contribute in this project

@alexgarel
Copy link
Member

Hi @puneeth072003 can you join on slack ? (we should limit off-topic discussion on the issue).

For this project, key knowledge is Postgresql, Python and FastAPI. You are really welcome to contribute :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: No status
Development

No branches or pull requests

5 participants