Can a process have an owner? What does it mean?

Read credentials(7), fork(2), execve(2). The fork system call is the way processes are created (today, fork is often implemented with clone(2) but you can see that as an implementation detail). The exec system call is the way executable programs are started. Remember that everything is done from some process with some system calls (listed in syscalls(2)). The very first process (init or systemd) has been started magically by the kernel at boot time. Other processes have been started by fork(2). Modern Linux kernels sometimes - but rarely - start magically a few special processes (e.g. /sbin/hotplug) or kernel threads (e.g. kworker, kswapd ....).

So yes, every process (and every file) has some owner (technically the uid, a small non-negative number) and group (the gid). The 0 uid is for root and has extra permissions.

Read also about setuid (and setreuid(2)...) It is tricky.

does it mean the other owner cannot run that process?

A process is already running (but it could be idle or waiting), so no one can run it again. Don't confuse a process (something dynamic) with the program (an executable file, often in ELF format) running inside it.

A given program (e.g. /bin/bash) can be executed in several processes. Many executables stay on your disk without having (at a given instant) any processes running them.

On Linux, proc(5) is very useful to query the kernel about the state of processes. Try for examples cat /proc/$$/status and cat /proc/self/maps. See also pgrep(1), ps(1), top(1).

Each process has its own virtual address space, its own file descriptor table, its own working directory, (and often several threads, see pthreads(7)) etc etc...

does it mean that other owners cannot run/kill/resume that process?

Running a process don't make any sense (it is already running). However, the executable of process of pid 1234 is available as the /proc/1234/exe symlink, and you might use that for execve(2) - but you probably should not -. The permission rules for execve applies.

To kill(2) a process, you generally should have the same uid. However, the documentation tells:

  For a process to have permission to send a signal, it must either be
   privileged (under Linux: have the CAP_KILL capability in the user
   namespace of the target process), or the real or effective user ID of
   the sending process must equal the real or saved set-user-ID of the
   target process.  In the case of SIGCONT, it suffices when the sending
   and receiving processes belong to the same session. 

To stop a process, use the SIGSTOP (or SIGTSTP) signal used with kill(2). See signal(7).

To resume a stopped process, use the SIGCONT signal.

The owner is usually the user that launched that process. The command might be executable by other users, but that would be a different process.

does it mean the other owner cannot run that process?

There is no other owner. Don't confuse programs (executable files) and processes (running programs).

Does it mean that other owners cannot run / kill / resume that process?

The single owner already launched the process. If you mean other users, not owners, that depends.

Root, i.e. a user with uid equal to 0, has full power. Other users sharing the same uid are, from the OS point of view, the same user, so have full power on the process too.

Users with a different uid won't be able to kill/stop/resume the process, unless they are allowed to switch to either the owner or root privilege through sudo or similar command or, to a lesser extent, if they are related to that process from their hierarchy.