Is there already an ActivityPub vocabulary for job openings, or cvs?
General Discussion
15
Posts
3
Posters
60
Views
-
Is there already an ActivityPub vocabulary for job openings, or cvs?
I'm trying to make my CV-webpage more visible, and also create a job-bot, that everyone can set up with their sources, and queries.
Obviously the idea is, to help people find jobs, and fill vacancies, without having to resort to a centralized network, like e.g. LinkedIn.
I'm aware of these efforts, though they're not ActivityPub related:
https://microformats.org/wiki/job-listing
https://microformats.org/wiki/h-resume -
Is there already an ActivityPub vocabulary for job openings, or cvs?
I'm trying to make my CV-webpage more visible, and also create a job-bot, that everyone can set up with their sources, and queries.
Obviously the idea is, to help people find jobs, and fill vacancies, without having to resort to a centralized network, like e.g. LinkedIn.
I'm aware of these efforts, though they're not ActivityPub related:
https://microformats.org/wiki/job-listing
https://microformats.org/wiki/h-resumeYou could, for example, use h-resume with ActivityPub.
ActivityPub is, in some ways, just another JSON-LD name-space.
Just use h-resume as another JSON-LD name-space along with ActivityPub.
-
You could, for example, use h-resume with ActivityPub.
ActivityPub is, in some ways, just another JSON-LD name-space.
Just use h-resume as another JSON-LD name-space along with ActivityPub.
Yes, as a starting point, that's what I thought as well. Just if there already would have been sinething, I wouldn't try and reinvent the wheel.
One issue with blindly adopting #h-resume is, that in an #ActivityPub context, you usually don't just state "here is my resume", but also e.g. "I have a new job", which then is an update to your resume. A use case, that never existed for h-resume.
So there's still work to do. But it's definitively a good start.
-
Yes, as a starting point, that's what I thought as well. Just if there already would have been sinething, I wouldn't try and reinvent the wheel.
One issue with blindly adopting #h-resume is, that in an #ActivityPub context, you usually don't just state "here is my resume", but also e.g. "I have a new job", which then is an update to your resume. A use case, that never existed for h-resume.
So there's still work to do. But it's definitively a good start.
Regarding:
"but also e.g. "I have a new job""You could either do that with a custom Object type.
Or, using an existing Object type — such as Note, or one of the others.
-
Regarding:
"but also e.g. "I have a new job""You could either do that with a custom Object type.
Or, using an existing Object type — such as Note, or one of the others.
Are you thinking of coding something for this?
-
Are you thinking of coding something for this?
I'm still in the phase of finding out, if there might already be all the tools available, but it seems, I won't get around writing at least some code for it.
I'll probably start extending an existing AP implementation, or using a library, instead of writing everything from scratch. But nothing is set in stone yet. Do you have any suggestions?
-
I'm still in the phase of finding out, if there might already be all the tools available, but it seems, I won't get around writing at least some code for it.
I'll probably start extending an existing AP implementation, or using a library, instead of writing everything from scratch. But nothing is set in stone yet. Do you have any suggestions?
@cdonat @reiver my main concern with such a system is it encourages the centralisation and the "big instance" problem, because of the nature of job ads and CV/resume posters. If you're looking for a job, you want your CV federated to as many potential employers as possible, and if you're hiring, you want your job as to be seen as much. I love the idea but without a good relay network it would be difficult to make it cohesive.
-
@cdonat @reiver my main concern with such a system is it encourages the centralisation and the "big instance" problem, because of the nature of job ads and CV/resume posters. If you're looking for a job, you want your CV federated to as many potential employers as possible, and if you're hiring, you want your job as to be seen as much. I love the idea but without a good relay network it would be difficult to make it cohesive.
I get your concerns. As @reiver already pointed out, the issue could be solved by federated search engines. They can also have federated indices.
Please allow me to respond with a longer thread, to describe my vision. It might change, over time, of course.
1/n
-
Let's assume I set up a search engine, that uses a hand full of sources known to me, that indexes software developer positions in Switzerland, because that covers broadly, what I'm interested in.
Other search engines as well as AP-Users can then subscribe to a query at my search engine. Whenever my crawler finishes, it publishes the newly found jobs, that match their queries.
2/n
-
Let's assume I set up a search engine, that uses a hand full of sources known to me, that indexes software developer positions in Switzerland, because that covers broadly, what I'm interested in.
Other search engines as well as AP-Users can then subscribe to a query at my search engine. Whenever my crawler finishes, it publishes the newly found jobs, that match their queries.
2/n
Now the other search engines have a new source. I can also subscribe to their search engines with my search term, and so find job openings, that I wasn't aware of before, because they have other sources.
After I add a job opening from those other search engines to my index, I also match it to my subscribers queries, and push it to them. Since I don't forward jobs, that I already have in my index, this breaks possible loops.
3/n
-
Now the other search engines have a new source. I can also subscribe to their search engines with my search term, and so find job openings, that I wasn't aware of before, because they have other sources.
After I add a job opening from those other search engines to my index, I also match it to my subscribers queries, and push it to them. Since I don't forward jobs, that I already have in my index, this breaks possible loops.
3/n
In the opposite direction, a search engine for recruiters can work similarly. They query known instances for resumes, that match their broad query and then use AP to distribute their results. The federated results can be used by the search engine admin to extend the list of known instances.
4/n
-
In the opposite direction, a search engine for recruiters can work similarly. They query known instances for resumes, that match their broad query and then use AP to distribute their results. The federated results can be used by the search engine admin to extend the list of known instances.
4/n
As job seeker, I subscribe to query, that describes the jobs, I'm interested in, and find job openings in my feed.
As recruiter, I subscribe to a query, that describes the candidates for my job openings, and will find matching candidates in my feed.
5/5
-
@cdonat @reiver I like the idea in principal, do you see those secondary subscribe actions as manual or automatic? I can see pros and cons to both but I feel automatic is the way forward for adoption, perhaps with an option to queue like moderation tools would have for those who don't want it? I'm getting into details here but I feel like a recommendation in the protocol/design doc would be worthwhile. How about multiple CVs for the same person? I have alt. ones for types of jobs for instance.
-
@cdonat @reiver I like the idea in principal, do you see those secondary subscribe actions as manual or automatic? I can see pros and cons to both but I feel automatic is the way forward for adoption, perhaps with an option to queue like moderation tools would have for those who don't want it? I'm getting into details here but I feel like a recommendation in the protocol/design doc would be worthwhile. How about multiple CVs for the same person? I have alt. ones for types of jobs for instance.
The idea currently isn't in the state, that I started thinking of that. 🙂 It's good to discuss all these details, I haven't thought about yet. Thank you for that.
Automatic subscription: I think, we have to distinguish between user, and search engine. The search engines will probably want to add new subscriptions automatically. The user probably wants to only subscribe to his chosen search engine.
-
@cdonat @reiver I like the idea in principal, do you see those secondary subscribe actions as manual or automatic? I can see pros and cons to both but I feel automatic is the way forward for adoption, perhaps with an option to queue like moderation tools would have for those who don't want it? I'm getting into details here but I feel like a recommendation in the protocol/design doc would be worthwhile. How about multiple CVs for the same person? I have alt. ones for types of jobs for instance.
Gli ultimi otto messaggi ricevuti dalla Federazione
-
Resurrected the nodeinfo helper service for the #FedBOX generic #ActivityPub service.
Hopefully this will lead to better integration with other federated services, but I find very little practical use for these hamfisted .well-known APIs integrated into the fediverse...
-
@Edent At least one atproto client can show Unicode handles https://atproto.at://did:plc:2h3l5x5ocsko5cabbqwksg2r/app.bsky.feed.post/3mggmlk25f5gf i.e. using IDN. Interaction etc. probably would probably need deeper support in server implementations.
On the ActivtyPub side, non-ascii usernames needs to be generally supported before @bsky.brid.gy can convert the handle @xn--atmosfrisk-i6a.xn--rdsei-vua.no correctly
-
@lexinova
A desktop app is planned, but a web interface is not something we will build. The core principle of Holos is that your data stays on your device, not on a remote server serving web pages.
-
I get that part. But somehow the wording you used in your initial post made it sound like the local transcoding was something undesirable and unusual...
-
@agowa338
Holos runs an ActivityPub server on your phone. Transcoding locally is not a workaround, it follows the same logic: your device is the server. The cloud storage part (S3/WebDAV) is there so your media stays reachable when your phone is offline. The goal is to give regular users full ownership of their data while staying part of the Fediverse.
-
@apps what still miss is a way to log (even remotely) on a web portal (meaning having something similar to web mastodon) for when we use a computer.
-
@apps So basically just like "Enhanced Broadcasting " on services like twitch.
You kinda make it sound like this was a drawback of using "non big us cloud" services...
-
RE: https://mastodon.social/@HolosSocial/116183535316096143
Some news from #HolosSocial development. The latest release moves media processing to the device. Videos are transcoded locally before upload. Users can store media on their own S3 or WebDAV server, and the resulting URLs are used directly in #ActivityPub activities. The relay server handles neither transcoding nor media storage. Each user brings their own resources to the #Fediverse.
