Collections vs. Events

[vlad]

Hi Luc,

I know Im maybe driving this a bit far, but this time i want to know that im making the right choice and that I'm doing the right thing and do it the right way.

Isn't that overly ambitious (especially as we're talking about DAM, where there are so many choices and options)?

Or at least have myself convinced that its as close and as good i can currently do it.

That seems more realistic.

Keyword wise, im still wondering what to do with - let me stay with the Birthday example - the sublevel (if any) of the Birthday label. Im pretty sure I would not use something like Event::Birthday::Johns 40th Birthday as to stay consistent with this I would have a separate event for each and every birthday. With a huge family every year the number of Birthday labels would be a bit silly as I think that the "labels" should still be possible to be used then just at one single event or moment in time. For that singel event or moment in time I would see this more as a function of a collection.

For the sake of accuracy, I would say that the specific event is John's 40th Birthday, while Event::Birthday::John's Birthday would actually be a class of individual events like that one. OTOH, I agree that could be silly and impractical - so the pragmatical and sensible choice may be to go with Event::Birthday::John's Birthday as the (recurring) event that you want to record, even if it doesn't allow you by itself to discriminate the underlying specific year events.

Nevertheless, I still think that I would maybe not stop at the Birthday level but use Event::Birthday::John Smith's Birthday.

That seems a reasonable cut to me, although you could also cut it one level up or down. The way I see it, it's all a matter of personal tradeoff between how complex a label or portfolio hierarchy you want to maintain and how accurate/specific/discriminating you want to be.

It of course still leaves for each event a bit of a question to what level to go, and I believe that might be differently answered by each of us depending probably if,where and how you actually want to use the catalog.

Exactly my point.

Accordingly one could question, should I distinguish Summer Holiday from a Hiking Trip or is the Hiking Trip also just a summer holiday, assuming of course that you do the hiking trip in summer. Therefore if you would be doing the hiking in summer and winter, it might actually be more useful to have a classification of Event::Holiday::Hiking::Summer Hiking Trip// Winter Hiking Trip, instead the other way around, being Event::Holiday::Summer:: Summer Holiday // Hiking Trip.

At the risk of being pedantic, I would note (regarding the 2nd choice) that summer is neither a holiday nor an event, so I would also go with Event::Holiday::Hiking::Summer Hiking Trip or directly with Event::Holiday::Summer Hiking Trip (or even Event::Summer Hiking Trip - or simply Event::Hiking). No matter what level of detail you want to capture in your label hierarchy, chances are that at some point it's not going to be enough - so you may want to somewhat limit your specificity ambitions from the outset.

In this later case I would probably go for Event::Holiday::Family Summer Holiday // Family Skiing Holiday // Hiking trip with Louisa // Family Bike Holiday SO I would not have a Family Biking Holiday in France and Family Biking Holiday in Czech Republic as two different Events. The collections and potentially the location field can help me sufficient to distinguish that and at the ent the event is a Biking Trip, so selecting the event would give me all pictures of all biking trips we ever did, while for an individual trip I have the collection (which would be stored in the headline of the image too) and/or the location and date to filter it out.

That seems reaonable to me.

Oh... one more thing.... what about Event::BBQ and what if the BBQ was actually on someones Birthday ???? multiple Events

... question will be whats the main event I think ... Are we doing the BBQ because its his birthday or are we having a birthday because we do a BBQ.... Hmmm interesting

Haha, don't overthink it too much (...like I usually do it )!

Cheers,
Vlad

[chuckhebert40]

I would like to propose another way of looking at the issue of how to label (e.g.) Tim’s 30th Birthday.

In the discussion about People I believe that an important omission is that of role. When we discuss (in this forum) the category “People” we are implicitly considering people who might be the subject of photos, hence the mapping to PersonInImage. However, in considering birthdays we are talking about a person as the “Owner” (for want of a better word), and, depending (as always!) on what you’re trying to achieve, it might be worth considering setting up a new Category, which I’ll call “Owner” (= person in that role). Lest this seems to make things overly complicated, an example might help.

Let’s suppose we want to be able to identify the birthdays of 20 people. If we want to do this for (say) 10 years’ worth of birthdays, then that would require 200 entries in the Catalog of the “Tim’s 30th Birthday” variety. However, if you were to set up 20 entries (people) under the Category “Owner”, then Event=Birthday + Owner=Tim gives you all Tim’s birthdays, and this doesn’t get confused by the issue of whether Tim is in the picture or not. Add People=Tim to the enquiry and you get those images of his birthdays in which he appears, and add the year to the enquiry to get pictures of Tim at a specific birthday.

This does raise the issue, mentioned in various places, of duplicated names, but I would think that can be got round by using Owner labels of the form “Tim’s”. Whether you would want to set up Tim in a hierarchy as under People (Jones Family’s::Tim’s etc) would depend on whether you want to be able to identify easily all Jones Family’s birthdays.

I would make a couple of other observations about this as a general approach.

Firstly, it would cover other “ownership” situations. If several of my relatives, including Tim, collect works of art, or cars, then I can use the label “Tim’s” to identify pictures of his works of art / cars. This also makes evident that “Owner” does not, of course, have to be a person – works of art could be owned by galleries, for example.

The other point is that this principle can apply in other areas. In the case of holidays, then the idea of using Place (country or city, as appropriate) seems perfectly reasonable (Event=Skiing Holiday + City=Chamonix), and again, adding year will give you a specific holiday (depending on how many you have per year in the same place, of course!). What has concerned me, personally, more, when it comes to places, is distinguishing between the subject of a photo and the location it’s taken from. I have been contemplating creating a second places category (say “Location”) for this purpose, where the issue is significant. I’m not an astronaut, but thinking about pictures taken from a space station (or a high mountain) does point up the need to separate the subject location of a picture and the location of the camera (and in connection with this, I’d remark that the GEO coordinates written to an image by the camera obviously correspond to the camera location, not the subject of the picture).

[vlad]

Charles, thanks for offering a new perspective on this issue (which concerns DAM and semantic systems in general) - it's always refreshing to see someone thinking outside the box.

However, I am not yet 100% sold on the ownership hierarchy idea: besides the incurred label/keyword overload (which may be unavoidable, as I also remarked in my previous posts), that may open a can of worms regarding multiple ownerships and who owns what. For example, how do you suggest to handle an image of Bart's and Lisa's funny hats, taken at Homer's birthday party?

On the slightly different subject of locations:

I’m not an astronaut, but thinking about pictures taken from a space station (or a high mountain) does point up the need to separate the subject location of a picture and the location of the camera

Fortunately, this is addressed by the spec: Location shown in the image vs Location in which the image was created. PSU is aware of both kinds of fields, although the current status is unclear to me and there may be some room for improvement (see Mantis #2103).

(and in connection with this, I’d remark that the GEO coordinates written to an image by the camera obviously correspond to the camera location, not the subject of the picture).

I don't know how metering works in modern cameras and how sophisticated the system could become, but I imagine it would be sweet for a sensor equipped camera of the future to optionally compute and record the aproximate coordinates of the photographed subject (with the aim of eventually applying reverse geocoding) based on:
- the current GPS coordinates of the camera
- the relative orientation of the camera (computable via gyroscope, gravity sensor or what not)
- the relative distance of the subject, as determined by the metering system and the settings configured by the photographer

Of course, one could never have a unique and meaningful set of GPS coordinates for something like a landscape spanning a vast space - but there should still be room for improvement, in theory, at least when there is a single point (or a limited area) of focus. (Mount Fuji is still Mount Fuji, no matter where you shoot it from.)

[Mke]

While I have the images labeled to People, Events etc I have Portfolios/Collections of the images similar to how one would have the old foto albums, which I understand is the purpose of the Collections.

Personally, I use of labels and portfolios/collections for entirely separate purposes. I use labels exclusively to describe the content of the image (who, what, where, when, why, etc.), and portfolios / collections exclusively to to distinguish how the images have been used - or how they are to be used - (images that have been published to the web, printed as a gift, to show to a particular audience, etc.).

I think that Hert's more general advice is to define hierarchical labels using terms that explicitly describe ISA specializations ("ïs a [specific, kind of]"):

Holiday is a kind of Event
Holiday in France is a kind of Holiday
Family Holiday in France is a kind of Holiday in France

I mostly agree with Hert and would also note that France is not a specific Holiday or a kind of Holiday, so defining a Event::Holiday::France label will probably lead (sooner or later) to the kind of problems noted by Luc. Following this reasoning, I would say that the event corresponding to John Smith's birthday is naturally - and unambiguously - represented by the following hierarchy: Event::Birthday:: John Smith's Birthday. (Please note that this is completely different than: Event::Birthday::John Smith, since John Smith is not a specific birthday, while John Smith's Birthday is.)

I agree with this - though I go slightly further and add the year, rather than collate all of John Smith's birthdays together, and also put the words in a specific order for display purposes. For example:

• event::private event::John Smith birthday party 2014
  event::private event::John Smith birthday bbq 2015

Keyword wise, im still wondering what to do with - let me stay with the Birthday example - the sublevel (if any) of the Birthday label. Im pretty sure I would not use something like Event::Birthday::Johns 40th Birthday as to stay consistent with this I would have a separate event for each and every birthday. With a huge family every year the number of Birthday labels would be a bit silly as I think that the "labels" should still be possible to be used then just at one single event or moment in time.

As you may have gathered from the above, I'd do the opposite!

Nevertheless, I still think that I would maybe not stop at the Birthday level but use Event::Birthday::John Smith's Birthday.
Why? (Feel free to share your suggestion/comments/advice/...)
I can identify an individual birthday of John by the collection and that would be easy, because if i know that I want to get the pictures of his birthday party last year I probably know its in the portfolio 2014 and can go to eg the collection 2014::Johns 40th Birthday party. And he probably does not have that many in a single year

...and then I wouldn't need to create a collection for John's 40th Birthday party

If I want to get all of his birthday party pictures, (or all ski holidays or something like that) I could go to Events::Birthday::John's Birthday and I would get all pictures from each and every of his birthdays, which would be a bit more difficult doing this with collections as I would have to select the pictures of each of his birthday party's in each of the different year portfolios. So for the Birthdays I believe im there.

If I regularly wanted to view all his birthday party pictures, I'd add another level in my label hierarchy - event::private event::John Smith birthday::John Smith birthday party 2014
More likely, I'd want to show a selection of just the best photos from John's various birthdays - and I'd create a collection for that.

...Therefore if you would be doing the hiking in summer and winter, it might actually be more useful to have a classification of Event::Holiday::Hiking::Summer Hiking Trip// Winter Hiking Trip, instead the other way around, being Event::Holiday::Summer:: Summer Holiday // Hiking Trip.
In this later case I would probably go for Event::Holiday::Family Summer Holiday // Family Skiing Holiday // Hiking trip with Louisa // Family Bike Holiday
SO I would not have a Family Biking Holiday in France and Family Biking Holiday in Czech Republic as two different Events. The collections and potentially the location field can help me sufficient to distinguish that and at the ent the event is a Biking Trip, so selecting the event would give me all pictures of all biking trips we ever did, while for an individual trip I have the collection (which would be stored in the headline of the image too) and/or the location and date to filter it out.

Again, I wouldn't mix labels and collections in this way. I'd use only labels:

• event::private event::holiday::Smith family holiday Czech Republic biking 2014
  event::private event::holiday::Smith family holiday France skiing 2015
  event::private event::holiday::Smith + Louisa holiday France hiking 2015

(and would also add labels such as activity::physical activity::skiing and location::Europe::France, etc.)

Hope that contributes something to your thought process...

[vlad]

Mke, thanks for your insights - the distinction between image content (labels) vs. image use (portfolios) is very clear and neat, although I'm not sure it works for everyone. (I'm mostly thinking of amateurs like myself, who may employ collections simply to organize pictures based on some subjective, not that well defined criteria, rather than a specific use.) And I do agree that something like "Smith family holiday Czech Republic biking 2014" seems like a good description to fill the Event field.

I have a couple of questions regarding PSU practicalities, please:

1. Don't you end up with a lot of verbose labels with similar names (in particular, with common starting words)?
2. If so, does the label overload create any issue or drawback in practice? For example, have you ever found yourself assigning the wrong label by mistake? Do you have any relevant tips and tricks to share?

Cheers,
Vlad

[chuckhebert40]

Vlad, you say

I am not yet 100% sold on the ownership hierarchy idea:

Nor me neither! The key issue, for all of us, surely, is “horses for courses”. I was addressing the issue of birthdays, not multiple ownership & funny hats! It all comes down to what you want to achieve, and I’m not sold on any solution as a panacea. There's plenty of scope for pragmatism (e.g. Paul’s use of the Description field), and enormous flexibility in the facilities available, and the best mix will obviously be a personal one. I don’t have a great need to find all Tim’s birthdays. I store all my images in a date-based folder hierarchy (year\month\day), and where the photos on any one day are of one subject I add to the folder name (e.g. 2015/04/30 – Tim’s birthday party), and it would be pretty quick to find his birthdays if I wanted to. This scheme also means that I can quickly find all the pictures relating to a specific holiday - or even several holidays - without using Event.

If I want to find a number of pictures with particular characteristics (e.g. mountain sunsets), then a reasonable amount of work on Catalog labels enables me to do that, and picking up Mke’s point, I’d maybe create a collection if I thought I might want to use that selection again. More difficult is the real-life query. “Do you remember that picture of Bart & Lisa wearing funny hats? I think it was maybe 10 or 15 years ago”. As long as I can home in on a few screenloads of thumbnails and find it by visual scanning, I’ll do that - and if not I'll tell my wife she's out of luck. (But if I do find the picture I'd probably label or mark it in some way, even though next time she'll want something else!).

On the question of places / location, I accept that there are different metadata fields for camera location and subject location, but in line with a point made by Hert in another conversation, I don’t want to have to tinker with metadata directly, but manage it through the Catalog. This requires labels which are differently mapped, and if the GEO data provided by my camera is to be used it has to be linked to the fields dealing with camera location, and not necessarily with the subject (although for practical purposes they may often be the same).

[chuckhebert40]

Perhaps a different topic, but since you’ve raised a question here, Vlad, about assigning the correct label….

If I start up PSU with a Folder displayed, I can open up the Catalog, and expand bits of it using the little black triangles next to the labels. I can then drag thumbnails from the folder over the labels to assign them. In many instances I find this convenient, and, with the Catalog hierarchy displayed I can be reasonably sure I’ve picked up the right label.

However, as soon as I click on a label in the Catalog (by accident, or deliberately to select pictures with a particular label assigned), or if I start PSU when the Catalog is displayed, I have found no way of viewing the pictures in a folder and at the same time having the Catalog displayed in the left panel. Is there some way to switch to viewing a folder’s contents and at the same time seeing the Catalog (other than by re-starting PSU)?

[vlad]

Hi Charles,

The key issue, for all of us, surely, is “horses for courses”. I was addressing the issue of birthdays, not multiple ownership & funny hats! It all comes down to what you want to achieve, and I’m not sold on any solution as a panacea. There's plenty of scope for pragmatism (e.g. Paul’s use of the Description field), and enormous flexibility in the facilities available, and the best mix will obviously be a personal one.

Fair enough: we can certainly agree on all of the above.

when the Catalog is displayed, I have found no way of viewing the pictures in a folder and at the same time having the Catalog displayed in the left panel. Is there some way to switch to viewing a folder’s contents and at the same time seeing the Catalog (other than by re-starting PSU)?

Yes, there is: select Catalog->All, then browse the bottom section and select the desired folder. You could then scroll up the Catalog Explorer to see other catalog items (in partcular, catalog labels) - just don't click on any item or you'll lose the current folder collection! (Of course, you could then press the Back button, but unfortunately this is now going to display the folder content in the Folders view rather than the Catalog->All view, which I find frustrating. I think I'm going to log this behavior as a bug, unless someone objects with good reason.)

The above workflow is not quite ideal, since opening the label hierarchy while viewing a folder collection always requires scrolling, plus you need to be careful to not click a label node instead of clicking the black arrow next to it. One small change (improvement?) that I see possible is for PSU to allow the switching between the Catalog and the Folders views without switching the current collection view. In other words, if I look at a folder content in the Folders view and then click back on the Catalog tab, why not preserve the current collection in the collection viewer, without switching back to the previous collection ? The current behavior was most likely preferable before introducing the multi-tabbed collection viewer in PSU V3, but I'm not at all sure it is still optimal. (Perhaps the catalog view should still remember which catalog item had been previously selected and make that item node always visible without scrolling, but leave the option of reselecting it up to the user rather than selecting it by default.)

Does that make sense to anyone else?

[HCS]

...
Yes, there is: select Catalog->All, then browse the bottom section and select the desired folder. You could then scroll up the Catalog Explorer to see other catalog items (in partcular, catalog labels) - just don't click on any item or you'll lose the current folder collection! (Of course, you could then press the Back button, but unfortunately this is now going to display the folder content in the Folders view rather than the Catalog->All view, which I find frustrating. I think I'm going to log this behavior as a bug, unless someone objects with good reason.)

The above workflow is not quite ideal, since opening the label hierarchy while viewing a folder collection always requires scrolling, plus you need to be careful to not click a label node instead of clicking the black arrow next to it. One small change (improvement?) that I see possible is for PSU to allow the switching between the Catalog and the Folders views without switching the current collection view. In other words, if I look at a folder content in the Folders view and then click back on the Catalog tab, why not preserve the current collection in the collection viewer, without switching back to the previous collection ? The current behavior was most likely preferable before introducing the multi-tabbed collection viewer in PSU V3, but I'm not at all sure it is still optimal. (Perhaps the catalog view should still remember which catalog item had been previously selected and make that item node always visible without scrolling, but leave the option of reselecting it up to the user rather than selecting it by default.)

Does that make sense to anyone else?

I agree, Vlad. I've noticed too that the All Catalog view is very sensitive to clicks. You have to click in exactly the right spot otherwise you get what you describe.

I'm now also moving to the multi-tab workflow, where i select the desired folder on the second tab. PSU now does support dragging and dropping files between tabs, that's enough for my workflow.

[Mke]

Mke, thanks for your insights - the distinction between image content (labels) vs. image use (portfolios) is very clear and neat, although I'm not sure it works for everyone. (I'm mostly thinking of amateurs like myself, who may employ collections simply to organize pictures based on some subjective, not that well defined criteria, rather than a specific use.) And I do agree that something like "Smith family holiday Czech Republic biking 2014" seems like a good description to fill the Event field.

I have a couple of questions regarding PSU practicalities, please:

1. Don't you end up with a lot of verbose labels with similar names (in particular, with common starting words)?
2. If so, does the label overload create any issue or drawback in practice? For example, have you ever found yourself assigning the wrong label by mistake? Do you have any relevant tips and tricks to share?

Cheers,
Vlad

Hi Vlad

Most of my labels aren't as verbose, but yes, in the events category there are rather a lot of longer labels with similar starting words. I don't find that a problem in practice though. For ad-hoc use I find it easier to locate the label I want if the wording follows a set pattern. But generally when I create a new event label it appears in the 'Recently Used' list and I select all images and apply it right away - so no, I've never yet assigned the wrong (event) label by mistake

[vlad]

PSU now does support dragging and dropping files between tabs

Sweet! Thanks for the tip. Mke, thanks for your answers too.

[chuckhebert40]

Thanks, Vlad, HCS - very helpful (so much to learn, with such a flexible - and evolving - system).

I see that dragging an image to a label-related tab (e.g. John Doe) is exactly the same as dragging to the Catalog label (so it doesn’t work if the tab is associated with more than one label, and it doesn’t revoke the label if it’s already assigned)- that's fine. I also notice that having dragged images to another tab the view of that tab needs to be refreshed – would be nice if that wasn’t necessary. [The biggest problem I have with tabs is that the text on the non-active tab (dull grey on black) is not particularly visible. I wonder how many others have this difficulty; I know my eyesight is rubbish! I realise that pointing at the tab causes the text to be displayed more brightly.]

Although dragging to a tab is a handy additional way of assigning labels, given the way I sometimes work it’s not a substitute for being able to see and use the Catalog tree. The Catalog -> all mechanism you suggest, Vlad, is certainly workable, but I agree it’s not ideal as it stands. What I personally have in mind is along the lines of selecting a folder using the Folder button, and then clicking on the Catalog button in such a way (maybe shift-click or similar) that it comes up in what in IDImager was called, I think, “assign mode”. In this mode it should be possible to click on a label, for example, or expand a hierarchy with the * key, without the system moving from the Folder view to a Catalog view. If a photo is selected, then clicking on a label, or dragging, would assign that label.

[vlad]

I also notice that having dragged images to another tab the view of that tab needs to be refreshed – would be nice if that wasn’t necessary.

Frankly, refreshing issues are fairly pervasive in PSU. (And, yes, I did report a couple of refreshing issues in Mantis.) They are annoying, but not showstoppers by any means.

[The biggest problem I have with tabs is that the text on the non-active tab (dull grey on black) is not particularly visible. I wonder how many others have this difficulty; I know my eyesight is rubbish! I realise that pointing at the tab causes the text to be displayed more brightly.]

I completely agree. As user friendly as the interface generally is, I would appreciate if it was in some places a tad more eye friendly too - with the tab text being a case in point. (Yes, I know: it's hard to acommodate or balance a wide range of eyesight and personal preferences. And no, I'm not suggesting a everything-configurable, make-your-own-interface kind of design. I'm all for a modern and consistent look-and-feel, although offering a choice between two or three standard schemas - or font sizes, at least - could still be considered, IMHO.)

Although dragging to a tab is a handy additional way of assigning labels, given the way I sometimes work it’s not a substitute for being able to see and use the Catalog tree. The Catalog -> all mechanism you suggest, Vlad, is certainly workable, but I agree it’s not ideal as it stands. What I personally have in mind is along the lines of selecting a folder using the Folder button, and then clicking on the Catalog button in such a way (maybe shift-click or similar) that it comes up in what in IDImager was called, I think, “assign mode”. In this mode it should be possible to click on a label, for example, or expand a hierarchy with the * key, without the system moving from the Folder view to a Catalog view. If a photo is selected, then clicking on a label, or dragging, would assign that label.

Charles, I think you might be happy to read my latest tip here: http://forum.idimager.com/viewtopic.php ... 15#p107349

Hope that helps,
Vlad

[HCS]

...
Charles, I think you might be happy to read my latest tip here: http://forum.idimager.com/viewtopic.php ... 15#p107349

Hope that helps,
Vlad

Good tip Vlad! I'd actually like the interface to always be like this (and the current way an option).

[HCS]

Thanks, Vlad, HCS - very helpful (so much to learn, with such a flexible - and evolving - system).

I see that dragging an image to a label-related tab (e.g. John Doe) is exactly the same as dragging to the Catalog label (so it doesn’t work if the tab is associated with more than one label, and it doesn’t revoke the label if it’s already assigned)- that's fine. I also notice that having dragged images to another tab the view of that tab needs to be refreshed – would be nice if that wasn’t necessary. [The biggest problem I have with tabs is that the text on the non-active tab (dull grey on black) is not particularly visible. I wonder how many others have this difficulty; I know my eyesight is rubbish! I realise that pointing at the tab causes the text to be displayed more brightly.]

Although dragging to a tab is a handy additional way of assigning labels, given the way I sometimes work it’s not a substitute for being able to see and use the Catalog tree. The Catalog -> all mechanism you suggest, Vlad, is certainly workable, but I agree it’s not ideal as it stands. What I personally have in mind is along the lines of selecting a folder using the Folder button, and then clicking on the Catalog button in such a way (maybe shift-click or similar) that it comes up in what in IDImager was called, I think, “assign mode”. In this mode it should be possible to click on a label, for example, or expand a hierarchy with the * key, without the system moving from the Folder view to a Catalog view. If a photo is selected, then clicking on a label, or dragging, would assign that label.

To be honest, i only ever use the drag&drop to a different tab to move my pictures from my "inbox" directory to the archive directory.

Regarding the assign mode you mention, there are more than one other catalog tools that actually offer the option to have a second catalog window open (i mean the selection tree) in order to do the dragging and dropping without risk to accidentally click a "wrong" label.

Another way would be to offer the option to "lock" the selection. Food for thought and perhaps a ticket in Mantis (i haven't raised one yet).