What if we make the lineage part of DBTC optional?

[richiev]

I'm guessing there's strong opinions on this, so apologies if I'm poking a bear. I back in the day ran a site called reef lines. The purpose was to allow people to track their coral lineage, ideally encouraging people to find lineages that were multiple steps removed from wild caught. Also to allow folks to see how theirs do over time, compared to other people's. I eventually shut it down, and I think I open sourced it but I'll need to double check my GitHub.

I mention that because I'm all for having metadata about tracking lineage. I think it's cool and useful.

That being said, I feel DBTC is more focused on the lineage than I'd expect. In my version the center was the coral, and lineages were extra, best effort, metadata. My use case was different though, in that I wasn't fully oriented around the free trade chain.

DBTC I think is great, and a lot of time must've went into it (is it open source?). I'm wondering if it'd make sense, or be possible, to make it similarly orient more around the coral.

As an example, I have a bunch of purple stylo frags. I'm certain a ton of people have purple stylo and would be willing to give it out. It feels weird though to create my own chain for it. The alternative is I hunt down the original DBTC creator for a stylo, and get them to fake give me a frag. I think that'd work, but is a lot of overhead.

My proposal(s):
1. Have some default DBTCs or DBTC templates. Have default rules (very open rules being the default, maybe options for more strict defaults)
2. Have the DBTC UI let you add your own frags to a DBTC, without needing sign off from others (if this is really something people are against, then make it a flag that someone can uncheck if they really feel like doing so)
3. Consolidate some basic corals into DBTCs that are setup that way. Do the same for some things like chaeto which everyone asks about and people could just use the DBTC.

This all is stuff I could do, if people agreed and given access to the source (is it open source?).

Thoughts?

 

[Coral reefer]

If you don’t want to make your own chain just pif?
If you want to be part of a chain join one. If you want to make your own make it. If not just share your coral through pay it forward.
I do think it makes sense keeping lineage straight.
Always open to input and improvements.
In this case I’m not sure what the improvements would be? Besides taking away the tracking of lineage to have less chains in some cases for what may or may not be the exact same coral? But I also suck at computers terribly so maybe I’m missing the point.
If that is the problem maybe under each section of Dbtc there could be a list of chains, and for “purple stylo” there could be a collapsable and expandable section to show the different options when you want to see them and hide them when you don’t so they don’t obscure all the other chains?
I don’t see a problem with how it is currently so I’m probably missing the point.
As for how it came to be @svreef made it because he is a golden god
He’s less involved right now and I’m sure it would be great to have someone else interested in taking the ball and running with it at some point now that he’s made the ball

 

[Chromis]

I agree with @Coral reefer if a coral seems unworthy of its own DBTC, or you don’t want to create one just for that coral, just put it in the pay it forward (PIF) thread. Problems with adding an unrelated coral into an existing chain: loss of traceability and muddling the lineage. What if it’s not the same coral after all?

I really like the idea of reeflines. Maybe some day there will even be a 23andme for corals and we can trace them back to what reef they came from and find out what aquarium environment they prefer… ha.

 

[JVU]

I wondered the same thing when I was newer to BAR (and before BARCode existed). It seemed confusing and not very efficient to have a bunch of different DBTC chains for the same coral. To answer what I believe is the specific question- There are a few reasons in favor of tracking as specific coral lineages from a specific originator member, as opposed to having one DBTC for each type/name of coral.

1. Because it is more common than you think that people are talking about different corals when they use the same name. Similar, but not the same. Sometimes this matters and sometimes it doesn’t, and generally you can’t tell until later. Since there is no real way to double check this when someone is joining someone else’s chain with their own coral, it’s cleaner if they just start their own chain.

2. Because there is also the coral banking aspect of DBTC. Originators of the chain get first dibs on later frags if they lose theirs. Although this isn’t generally a problem in real life since everyone is so generous, it is a reason to start your own chain as opposed to joining someone else’s.

3. Chains rules are set by the originator. Most of us use the generic rules, but some people add their own rules. And some people change the rules after they start the chain. If one person started the chain and then 2 other people add their own later (kind of like restarting the chain), then we don’t have a policy how to deal with differences in rules. For example if the originator has strict rules or makes them stricter later, and the future new-frag contributor wants looser rules or has a different interpretation of the rules, you can create conflict. It may sound unlikely but this has happened. With the current system we can just say whoever started the chain makes the rules. If multiple people added their own frags separately, it is less straightforward.

4. People take pride in starting chains, completing their 2 links in other people’s chains, and other metrics being tracked. This could be incorporated with this alternative approach, but isn’t currently.

None of these are deal-breakers, but you asked why we aren’t already doing it more focused on the corals as opposed to lineage.

BARCode is the creation of Pablo @svreef and any changes or updates would need to go through him (in addition to being big-picture approved by the club/DBTC Chair/Board). It would be very useful to have someone else in the club with the technical know-how and enthusiasm to help keep BARCode updated as we go along. Having only 1 member knowing anything about it makes me nervous, even when that 1 person is awesome. Our previous generation of DBTC tracker had 1 person who built it and was the only one in-the-know and when he became inactive in the club, it eventually stopped working.

 

[MolaMola]

I agree in keeping DBTC how it is for the purposes of "backing up" your coral, though I agree with @Coral reefer that perhaps there could be some way to organize parallel but distinct chains of the same coral type. I also agree that specific lineage is of some importance; I have a chain for a BTA that can be directly traced through reefers in the Bay Area since before 1998. It serves to document captive propagation as opposed to many BTA lines from specimens taken directly from the ocean.

 

[richiev]

So the DBTC version I was proposing was rooted in the way it currently is designed. The reef lines version was setup basically how @JVU suggested. Things generally were organized around the coral, with lineages as things tracked within it.

You could add additional metadata about corals to your copy of the coral, and then the main coral page would aggregate across all the entries and provide a summary. Eg if you entered in high light, and someone else did, and a 3rd person entered medium, it'd provide that summary. Similarly if one person provided a scientific name it'd show that, or show if there was a conflict in names. Also if you linked to a more info sight it'd have that.

The lineages were shown within the coral's page. You could navigate them, and see the progression of them over time. Eg if someone had 5 pics of a frag, it'd show a time cycle of them.

The other somewhat minor, but significant difference was it let the frag receiver say they got a frag from someone versus making the giver need to go into the tool. Both could do it, but that makes that receiver need to do the work versus the giver.

I definitely didn't have as robust a tracking setup, nor integration with a forum, nor the nagging to do updates.

I didn't want to get too deep into the details of that design in the start of this thread because I didn't want to confuse things too much.

The main points though that I was suggesting towards here:

• the switch to the emphasis being the coral with the lineage being additional data, and multiple lineages being nested within one
• there's more PIF and sale activity than DBTC, and with this orientation it can support both
• orienting around the coral, with lineage as extra, allows for gathering general info about the coral
• in theory a lot of that could all exist within barcode with just some minor tweaks, like creating generic threads if people don't care to track full details nor care about the idiosyncrasies of how people handle the frags they're given

 

[Coral reefer]

So the DBTC version I was proposing was rooted in the way it currently is designed. The reef lines version was setup basically how @JVU suggested. Things generally were organized around the coral, with lineages as things tracked within it.

You could add additional metadata about corals to your copy of the coral, and then the main coral page would aggregate across all the entries and provide a summary. Eg if you entered in high light, and someone else did, and a 3rd person entered medium, it'd provide that summary. Similarly if one person provided a scientific name it'd show that, or show if there was a conflict in names. Also if you linked to a more info sight it'd have that.

The lineages were shown within the coral's page. You could navigate them, and see the progression of them over time. Eg if someone had 5 pics of a frag, it'd show a time cycle of them.

The other somewhat minor, but significant difference was it let the frag receiver say they got a frag from someone versus making the giver need to go into the tool. Both could do it, but that makes that receiver need to do the work versus the giver.

I definitely didn't have as robust a tracking setup, nor integration with a forum, nor the nagging.

I didn't want to get too deep into the details of that design in the start of this thread because I didn't want to confuse things too much.

The main points though that I was suggesting towards here:

• the switch to the emphasis being the coral with the lineage being additional data, and multiple lineages being nested within one
• there's more PIF and sale activity than DBTC, and with this orientation it can support both
• orienting around the coral, with lineage as extra, allows for gathering general info about the coral
• in theory a lot of that could all exist within barcode with just some minor tweaks, like creating generic threads if people don't care to track full details nor care about the idiosyncrasies of how people handle the frags they're given

You sir are above my pay grade. I appreciate you for thinking about this!
I’d prefer to sit quietly and listen to the adults in the room talk and offer my opinion when I think it might be helpful on some details. I just don’t have the technical understanding to even imagine the best way to do all this stuff.

 

[richiev]

This got me reminiscing. By the power of the way back machine: https://web.archive.org/web/20120610181516/http://reeflines.com/users/richievos . This one the pics seem to be loading: https://web.archive.org/web/20120610202623/http://reeflines.com/users/Arcticreef

I think I'm going to restore this to a host this week and see if it'll still load. I'm pretty sure somewhere I have the database backed up and I think I kept all the images.

I also forgot about the logo my friend made for me: