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

Have a platform *dependent* way of contacting author(s) #7

Open
hoijui opened this issue Aug 1, 2023 · 3 comments
Open

Have a platform *dependent* way of contacting author(s) #7

hoijui opened this issue Aug 1, 2023 · 3 comments
Assignees
Labels
workable Ready to be worked on

Comments

@hoijui
Copy link
Collaborator

hoijui commented Aug 1, 2023

As discussed in #19,
we do not and very likely never will have a platform independent way of contacting the author(s)/licensor(s)
directly from the OKH data.
What would be practically achievable though,
is to have a platform dependent way of contacting, say:

  • link to users profile page on thingivierse
  • email of git authors or issues page for github, gitlab, gitea & co.
  • ...

So.. this is kind of a request for discussion of whether we want a new field called ... okh:contact or the like.
And whether it should be mandatory. I would say: yes, mandatory.

Summary

Proposal: okh:contact, type: URL, cardinality: 1+, required: yes, content: email, telegram (person|group), platform contact page, github/gitlab issues page, ...

@hoijui hoijui self-assigned this Aug 1, 2023
@hoijui hoijui added the question Further information is requested label Aug 1, 2023
@moedn
Copy link

moedn commented Aug 3, 2023

not quite sure about this… of course it's beneficial to be able to contact the originator, but:

  • if the they choose to share their contact details with the world wide web, they should do so in the original repo; I feel that contact sharing goes beyond the scope of OKH
    • it's a general concern; not sure if the manifest file would be the right place to share the contact details and having the same data in multiple locations (unsynced) is generally a bad idea :)
    • btw some licenses already include contact details, such as MIT
  • anyone can create manifest files, so I don't expect a consistent use of this field

@hoijui
Copy link
Collaborator Author

hoijui commented Aug 4, 2023

I did not think of having it as a (TOML) manifest entry, but rather only in RDF, and generate it while crawling.
Having it really mandatory though, would mean we would exclude platforms/projects that really leave no way of contacting, which.. I can not think of any right now, but to some extend makes sense to me. Then again, we could also decide to not make it mandatory.

@hoijui
Copy link
Collaborator Author

hoijui commented Aug 4, 2023

In the meeting we had this morning, @moedn and me came to the conclusion, that this makes sense as an RDF-only info, created by the crawler, but not manually definable in the (TOML) manifest. It should also not be mandatory, as for not to exclude platforms that may not support this at all, or alternative (non krawler based) ways of coming up with the RDF data, which might not be able to supply this.

@hoijui hoijui added workable Ready to be worked on and removed question Further information is requested labels Aug 4, 2023
@hoijui hoijui transferred this issue from OPEN-NEXT/OKH-LOSH May 30, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
workable Ready to be worked on
Projects
None yet
Development

No branches or pull requests

2 participants