Bug 146865

Mik,

I would to start a reflexion about this B.K.O entry...

Mik, my vision is like your one : a computer host pictures + database. Remote computers  mount the file system shared over the network to play with images. Also Remote computers need to query remote database.

To share files, it's not a problem to use network file system (NFS-SAMBA for ex.) KDE4 version of digiKam _now_ support remote file systems (and multiple roots path).

For the Database, I see 2 solutions :

- using a deamon running on server and to query over the network. Dedicaced protocol will be used to query the deamon (XML based will be nice). This solution is undependant of the Database format/program (we can continue to use Sqlite3). This way do not require to change anything in SQL queries from digiKam DB interface

- using a database as MySql wich provide a deamon than it's possible to query using database protocol. This solution is dependant of the Database format/program and require a more unified database backend (for ex. based on QtSQl). This way require to touch/adapt/change few SQL queries from digiKam DB interface.

I'm not a Database specialist. So tip from guru are welcome to guide us on this subject. Thanks in advance...

Gilles Caulier

Of course (and   pity :( ) I am not database  guru but I'd like to see
other feature:

Break users into Administrators and Users. Admins have rw access to
database, Users only r-. It is possible to store in database some
predefined values and later users can fill metadata forms from drop-down
menus without adding new entries. Even without segregation of users it
could lead to faster filling of forms. One one computer you could make
it with form history (as seen eg in Konqueror) but how to propagate it
between remote computers?

I am afraid it would require changes in DB layout so probably it is too
late :(

ps. It is idea from FotoStation.

Break users into Administrators and Users. Admins have rw access to
database, Users only r-. It is possible to store in database some
predefined values and later users can fill metadata forms from drop-down
menus without adding new entries. 

sure.

Even without segregation of users it
could lead to faster filling of forms. One one computer you could make
it with form history (as seen eg in Konqueror) but how to propagate it
between remote computers?

This is the concept of client/server with admin messages to post.

I am afraid it would require changes in DB layout so probably it is too
late :( 

DB schema is not yet frozen (:=)))

Gilles

I threw in a few votes just so that I don't forget this issue. I've worked with a few things like this. In my previous job, I worked with the photo galleries of http://my.opera.com/ In my experience, the relational model is rather inflexible and not very well suited for extensible data models. It can be replaced by something that's more flexible, the RDF model. So, I'd like to advocate that at some point, and I would like to contribute time to do it too, I'm just not ready to do it yet... 

Also, for even more finegrained control, have a look at http://www.policyawareweb.org/ where they have been prototyping stuff to make statements about who should be able to edit, who should be able to see a picture (in Norway, there is a legal requirement that identifiable persons must be able to approve  that their picture is published).

I would agree on the benefits of using an RDF model in this case given the tight constraints of a traditional relational model. Unfortunately its not unlike using an OODBMS, not too many people are familiar with them and you sometimes get knee-jerk reactions.

I'd like to help with the RDF approach if/when it might get underway.

Does the "RDF model" correspond to "Resource Description Framework"
http://www.w3.org/TR/REC-rdf-syntax/
(Currently I have no idea what this would achieve for digikam,
and in particular how it is related to the original wish;
so before reading the RDF primer I want to be sure that this is the 
right pointer ;-)

Arnd,

yes, RDF = Resource Description Framework. This one is already used with XMP metadata for ex.

Gilles

Nepomuk is based on RDF.
You do not define tables, but always have a triple: "subject - predicate - object" (would be the linguistic approach), ex. "image xy - height - 1024". You can then freely define "ontologies", which is roughly a list of attributes (an image has width, height, rating, comment). This is my understanding, I am not an expert and might get things wrong.
In my personal opinion, this is without doubt the right choice for a framework like nepomuk which aims to integrate not only traditional metadata of a wealth of formats, but also in the future more context metadata ("which image was sent to me by this person by mail?") - at least I hope so.

For our purposes, there are several problems:
- the depth of integration. Digikam is not accessing a data storage, it is deeply based on it, and stores not only metadata information.
- specialization on images: we do not need the general approach. We can define what we want.
- ease of implementation: Basing everything on RDF would mean a lot of complexity to bring all information together.
- existing source code: It would require a significant rewrite.

I think something like this should be created as an add-on,
digikam can have its main database (so that if the share cannot be mounted, digikam can still run) 
you could choose to add a remote database and the database would be saved in a folder above the networked pictures, then all the images in the database would have relative filenames)


I also really like the idea for having different levels of access (admin-user setup) but I also think that would take a lot of change to the coding, so I think that my idea could be a quick fix/compromise, to get us what we want and require minimal coding.

This is now becoming possible within the Solid Project, https://solidproject.org/ . We recently published the 0.9 version of the protocol spec:
https://solidproject.org/TR/protocol

The way this could be done on Solid is to create an add-on that it is a Solid client. That client has to have a concept of users and authorization policies, but as a first iteration, it could be done as simple as "just me" and "everyone else", that would still be useful, I think.

The images themselves would be PUT to the server, and the metadata would be written along with it in what is in Solid an auxiliary resource, specifically a Resource Description.

(In reply to Kjetil Kjernsmo from comment #10)
> This is now becoming possible within the Solid Project,
> https://solidproject.org/ . We recently published the 0.9 version of the
> protocol spec:
> https://solidproject.org/TR/protocol
Kjetil,

I believe this feature request was requesting the ability to have multiple users work on a collection at the same time. In a studio setting, for example, you would want multiple editors to be able to access photos from a recent shoot to expedite the tagging and rating of photos from a recent photoshoot. For a home user, alternatively, they may want to have a photo library stored on network attached storage but have the freedom to edit from multiple computers.

It also seems like *parts* of this have been implemented--excepting some caveats regarding simultaneous updates not refreshing the UI of other users. Might be worth closing this in favor of a newer ticket that better reflects the current state of things.
see this article from 2018 about migrating your digikam database to MySQL and a NAS:
    https://www.digikam.org/news/2018-10-20_digikam_nas_mariadb/ 
and this documentation about how to handle a non-sqlite backend:
https://docs.kde.org/trunk5/en/digikam-doc/digikam/using-setup.html#using-setup-database
and this fixed bug-report about using a separate thumbnail database:
https://bugs.kde.org/show_bug.cgi?id=297922
and this still open one about absolute paths being stored in the database:
https://bugs.kde.org/show_bug.cgi?id=275261

(In reply to Kjetil Kjernsmo from comment #10)
> This is now becoming possible within the Solid Project,
> https://solidproject.org/ . We recently published the 0.9 version of the
> protocol spec:
> https://solidproject.org/TR/protocol

solidproject seems better suited to replicating the feature-set of a photo library like google photos. Allowing users to share photos/albums with a larger audience. While this seems like a cool idea, it seems like you didn't read the rest of the thread before necro'ing this feature request to promote a project you work on...

https://solidproject.org/team#kjetil-kjernsmo

(In reply to Dan Fallon from comment #11)
> While this seems like a cool idea, it seems like you didn't
> read the rest of the thread before necro'ing this feature request to promote
> a project you work on...
> 
> https://solidproject.org/team#kjetil-kjernsmo

With all due respect, Dan, but if you read the thread, you'd see that I was participating in this thread 15 years ago, and at that time, there were several who were open to the consideration that using RDF might be the right way to implement the use cases behind this issue. Solid basically provides the technical infrastructure to use RDF this way.

I was using Digikam with a collection on an NFS share when this issue was created, and with a remote MySQL database for the last decade. Recently, I have set up MySQL so that my daughter can use Digikam on a different machine, but she hasn't done it a lot and certainly not concurrently with me. I am aware that this can be done right now, but for more advanced use cases, I would probably look to other technologies. I think your comment was rather undue, as my comment was a follow-up from the discussion that happened 15 years ago.

Please note that the database connection test is only a test of the database, username and password. The tables are created much later after the first start dialog.

Maik

The Comment 13 is posted incorrectly here.

Maik