My name is Adriano De Iana and I've been living here for a long time. Before me, my father caught us, and also my grandfather. We all fish to earn money to eat. We can't not fish. Unfortunately, now we fish very little. Once we fished a lot. Adriano's family have been fishing for European eel in Sardinia since 1952. Adriano is only one of the few hundred fishes across the Mediterranean who rely on eel as a source of income and livelihood. He, along with many others, has witnessed the drastic decline that eel local stocks have undergone in all eel habitats. The situation is so dire that experts assessed the status of the species as critical and the International Union for Conservation of Nature listed European eel as critically endangered. European eel has a truly extraordinary life cycle. After hatching in the Sargasso Sea in the Caribbean, eel larvae cross the Atlantic, drifting in the Gulf Stream current for over a year. Once they reach the continental platform, they undergo a metamorphosis to transparent glass eels. At this stage, they enter estuaries, canals and lagoons, making their way to upper river stretches and lakes with a distribution range from the Mediterranean region to northern Europe. Across the Mediterranean Sea, eel habitat is predominantly coastal lagoons. Eels grow in freshwater for up to 20 years and when they reach sexual maturity, they descend to coastal waters, travel across the Mediterranean to the Strait of Gibraltar and back across the Atlantic to the Sargasso Sea where they spawn and die. All along their colossal migrations, eels face major threats, both environmental and human-induced. Global changes, habitat loss and degradation, pollution, overfishing, illegal trafficking are all major threats to the species. Eels are used to catch eels, for example, or with a battery. But fishing a lot and then bringing it to the market, the fish, to make it pay for a tenth of what it's worth, is not very smart. It's better to fish less and probably earn more. 90% of eels were sold out. I mean, about 10% of eels were sold out. There weren't many like the old ones. I don't know what kind of life they lived, but they changed their way of life. In the days, they changed their way of life and their ability to act. In the past, eels used to live in deeper waters. Because it was cold, eels used to live in deeper waters. But now, eels live in very shallow waters. Because they live in deeper waters, eels live in deeper waters, and they take more lives. These impacts have likely had a cumulative effect, driving the eel global stock towards critical status. It's crucial that all the stakeholders, all of them, fishermen, hydropower managers, the authorities, regulating both the quality and quantity, all the connectivity of coastal nagoons to the sea, it is important that they all work together with the ultimate goals, minimize the threats and remove the obstacle preventing a significant fraction of the reproductive stock to swim back to the oceans and reach the spawning areas in the sub-gank sources. The loss of resource and the consequent reduction in catches contribute to significant economic losses for fishers. This is coupled with important losses in the traditional knowledge, management traditions and environmental stewardship that fishers themselves provide and which have proven crucial to maintaining lagoon ecosystems over the years. The challenge, therefore, needs to be addressed both at the global level by identifying solutions towards the recovery of the eel population and at the local level by determining concrete actions required in each specific situation. In the Mediterranean, a period of productivity is produced because less and less anguishes come in and the quality of such lagoon is decreasing due to the presence of nutrients in excess, due to the presence of metals, due to the presence of pesticides. Consequently, we must work to maintain the quality of these habitats, reducing the entry of contaminants, reducing the fishing pressure, increasing connectivity and, above all, the quality of the water in these habitats. The critical situation calls for urgent protection and a coordinated management strategy for the recovery of the species. That's why the General Fisheries Commission for the Mediterranean ran a dedicated research program on European eel in nine Mediterranean countries. The program collected data on management and protection measures for stock recovery at the national and local levels, as well as information on eel habitats, on the biological features of local stocks and on eel fisheries and aquaculture. This provided the basis for a multi-annual management plan for European eel fisheries in Mediterranean Sea, recently adopted by the GFCM members. The results of the research program highlighted that, despite the impacts of fishing, fishers are the guardians of these habitats and can actively contribute to their conservation, benefiting eel and all other living resources. Collaboration between fishers and scientists could provide a winning strategy through exchanges of knowledge on the eel resource and its environment, as well as cooperation for long-term monitoring and joint implementation of measures for stock recovery. The original approach of the GFCM Commission is that we want to do it with fishers in the sense that we try to provide a resource but also to provide economic activities that, naturally, will have to be redimensioned, but this has already happened because if the resource is rare, the activity has already been redimensioned. I think that you never end up learning. So, when you work in contact with researchers, they teach you a lot of things and we see a lot of them in contact with nature. But we don't know many technical things. Contacting with these people teaches us a lot of things. As for the scientific research group, we have a group of scientists who are very close to the scientific research group. They come to the water, and the scientists are very close to them. As for the lake, the lake is very happy to be able to participate in this project. We want to take this opportunity. Going forward, the GFCM will expand on the research program through a second phase which will further explore the possibility of management models adapted to local realities. It will also undertake a socio-economic study on eel fisheries in the Mediterranean. Establishing a regional monitoring network and involving joint efforts of fishers and scientists could be a key tool to help assess the state of the eel stock and the impacts of current and future management measures. Adjustments may be required in the short term, but the ultimate ambitious goal is to ensure the conservation of this iconic species and the preservation of the heritage and artisanal fisheries of coastal communities all over the Mediterranean. Our interest is to look at these places. If we don't look at them, then we'll have to look for another job. If we like another job.


I present to you a project I've been working on, Expressions. So a little bit of history on this project. Back about a year ago, I was working at a company called White Pages, and I got the opportunity to work on the redesign of this framework we call the plan execution framework. Basically, we received a request and then we needed to send a whole bunch of requests to like back-end services in order to build a response for the user. And obviously, we do this sort of asynchronously. And this old framework, it had a bunch of problems with it, so I wasn't really maintainable, so I sort of jumped in to redesign it. The problem is it was untyped. The idea was to have just like a declarative way of specifying how to resolve a request. You just like tell it what needs to happen, and it sort of does it for you. But in practice, you'd give it like dependencies. So like in order for this activity to run, you need these activities. Basically, it was a little bit of a nightmare. And so when I came in, I really pushed hard to figure out, what is this framework doing for us? Why do we need this complicated thing to do asynchronous code? And so I pushed hard to say, in Scala we have this nice abstraction called Futures. They're easily composable. So let's try and use that. And I ended up being sort of right. We did end up being able to get rid of that framework and just use Futures. But there were a few things with Futures that we weren't able to get that the framework was sort of giving to us. And by far the biggest thing is Futures that fail fast. And what do I mean by Futures that fail fast? So if we look at the code here, we have three Futures. The first one is sleeping for one second and then returning a valid value. The second one is sleeping for five seconds, returning a valid value. And the third one is sleeping for three seconds and then failing. And so a typical way to use Futures is to use for comprehensions. And so if we do this for comprehension and you run this on your computer, you'll notice that this actually does not fail after three seconds. It's gonna fail after five seconds. And this was something that the framework we were using was doing for us, failing fast and it was an absolute requirement that Futures needed to fail fast. So I was sort of disappointed. I didn't expect this out of Scala at the time. And so basically spent a whole lot of time trying to figure out why it is that this is not failing fast. So by the way an interesting thing is that I'm gonna explain why fundamentally it's not possible to fail fast with for comprehensions but using vanilla Futures even without for comprehension sort of directly writing maps or flat maps, it actually doesn't fail fast either. But there's no fundamental reason why it can't fail fast. It's just the current implementation doesn't do it. And as an interesting note, Twitter Futures do fail fast when you're using map and join. So but why is it that I'm saying fundamentally in a for comprehension you cannot fail fast? So for those of you that are savvy Scala programmers you know that a for comprehension actually desugars to calls to flat map and map. So this is actually the resulting expression from the previous for comprehension. And so okay, why you said that for comprehensions couldn't fundamentally fail fast. What do you mean by that? So if we have a look at the signature to flat map we'll notice that flat map is you know you give a lambda to flat map, a lambda from A to future of B and it's gonna produce you a future of B. So if you're the person that's in charge of implementing flat map, you don't have access to future of B until future of A is completed and giving you the A. At that point you can call into the user function and get future of B. So fundamentally it's gonna be impossible for you to inspect future of B to see if it failed already before A completes. Is that clear, any questions on that? Okay, and so if we look at another function let's say zip. So zip takes a, well it's defined on future A. It also takes a future B produces a future of AB. In this case we have access to future B so it's possible for us to fail fast. So we could rewrite the code we saw previously with zip and now this behaves like we want it to behave. Well actually in vanilla Scala it doesn't but it could behave like we wanted it to behave. So as a side note some of you might be wondering well there's a pretty cool notation out there called asynchro weight that's based on this language features from C sharp that allow you to deal with futures. Does that fail fast? Does that give us the properties we're interested in? And it turns out it doesn't and the explanation for that I don't know. Async is a bit of a complicated beast and as far as I'm concerned a big black box but I've tested it out and it definitely doesn't work. So we had a fairly limited amount of time to solve this problem. We did end up solving it. It wasn't like the perfect solution. Well basically no, I mean it worked. We had futures that were failing fast. I give a talk at Pacific Northwest Scala on how we solved it making heavy use of shapeless and Scalasy. But I wasn't satisfied with our solution. It was the best solution we could come up with in the time we had but I wasn't satisfied. And the reason for that is I believe, I strongly believe that for conference is a nice syntax. It's like a higher level syntax that allows you to reason about asynchronous code almost as if it wasn't asynchronous. You sort of like extract it from the context and then you can deal with it as if it wasn't a future and then it's just magically as a future. Well it's not magic, it's very formal but you know it's a higher level abstraction. So it was annoying to me that I couldn't use for comprehension to do this. I needed to like directly use sequence and flat maps and all that. So at that point I started working on a project that I'm tentatively calling expressions and I'm now calling it an alternative to for comprehensions. So what's a high level view of the features for expressions? So the first thing is it uses the least powerful interface and I'm gonna go into more detail on that but that basically means that we can fail fast using this notation. Second of all it plays well with if and match statements. If you go on the Scala, Async, GitHub page you'll see that's one of the strong arguments is for comprehensions to sort of start to break down when you have a bunch of if and match statements they weren't really designed to interoperate with them. The third point is that it's a unified notation. So like for comprehensions, Async await only works with future. This notation that I'm doing, it works with Scala future, it works with Scala as a task, it works with option, it works with any monad basically. And finally it's customizable. So if you want it to fail fast, you can provide an instance of a type class to do that. If you don't want it to fail fast, you can provide an instance that doesn't fail fast. You can sort of customize it the way you want. So let's just dive into a few examples to see what it looks like. Oh, wait a minute. So failing fast. Here we have the same sort of situation we had before. We have three futures. I shortened the notation here. The first one's waiting for five seconds. The second one's failing after one second. And the third one's waiting for three seconds. And so we have our good old four comprehension as the first example. So this is gonna wait five, this is gonna wait five seconds. Actually it shouldn't fail there. There, that's a mistake. It's gonna fail after five seconds. Because it needs to wait after the first one. And then only after the first one is completed is it gonna know, oh, the second one failed. Whereas opposed to expression at the bottom, not only is it more succinct. Although, so it's configurable. You can either use implicit extraction here or explicit. You can make it, some people might be scared. Oh, A is sort of implicitly becoming, being extracted into what's inside the context. But you can use explicit extraction. I just wanted to keep the code succinct. But the important point is by using expression here, we're failing at one second. And it's possible to do that. And sorry, this slide's a little bit loaded, but it's not too complicated. We can go through it. So interacting with if, we have the same situation here again. Well, like a similar situation. Actually in this case, none of them are failing. They're all just waiting a second, five seconds, two seconds. And in the first case, we're using our four comprehension. Is that big enough? Yeah, okay. And what happens here is, let's say A is equal to something. Then we're calling this Polish function on B, or BB, which is B. And if it's not equal to something, we're calling Polish on C. And so what happens here is, if we're using a four comprehension, we need to wait after A, B, and C. That's just how it works. But to me, and I think to most people that are doing, just run of the mill, asynchronous code, if A completes before the two other ones and it ends up being either equal to something or not equal to something, at that point we can sort of just ignore B or ignore C, right? We don't really care about the result anymore. We're not gonna use it. And so unfortunately, if we're using vanilla four comprehensions, in both cases here, we need to wait five seconds. That's just how it works. So in the second case, we're still using vanilla four comprehensions, but what we're doing is that we're actually nesting the four comprehensions and this is gonna give us the behavior we want. And at the end, we need to flat map identity, which would be equivalent to flattened but I don't think they're defined on future, which is just to say, we end up with a future of a future of something because we nested them and we need to flatten that into a single future. But we can get rid of all this notation and still get the property we want by using expression here at the bottom, which is just gonna sort of automagically do the right thing. I say automagic because it looks automagic and you can use it like it's automagic, but it's actually quite formal what it does and it's easy to reason about why it behaves the way it does. Any questions up until now? Okay. And then another example is using another abstraction.  And so list is an interesting one because list is not typically considered like a monad. So it would be a little bit weird to use lists here as if it was a monad. However, you can use this notation as well for applicatives. So list can be considered an applicative and the intuition for that is that it's like an undeterministic computation. So basically, if you have three values and you're doing plus another list with three values, you end up with all the, well, depending on how you instantiate your type class, either the combination of all the pluses, of all the combinations, or just the zip list instantiation. But it can be useful if you're working with errors or stuff like that to just like write a computation as if it was like one value, but it's actually like lists of value and you end up with like a list at the end, which is the computation over the whole list. But the important point here is that no matter what the abstraction, you can use this notation to sort of like peel off the context, deal with the things inside as if they were just the things and then you get it in the context at the end. So how does it work? So it's based on Scalasy. So Scalasy defines a hierarchy of type classes. So there's functor, there's apply, applicative, monad, which are essentially based on the type classes you'd find in Haskell. So functor has a map. We don't really use functor all that much. Apply is what's really interesting here. So if you notice the signature apply to is actually very similar to zip. It's basically zip and apply to is going to enable us to fail fast. And then you can derive map from apply to applicative in this, in this, in Scalasy is just extending apply and adding point. Whereas in Haskell applicative is actually both point because like there's no apply in the anyway, not super important. And then monad extends applicative and provides bind and bind is basically our flat map, which cannot fail fast. And you can derive apply to from bind, but if you do that, then you won't be able to fail fast. You're losing flexibility in the implementation of your function. And so what's really cool with this notation is that it's implemented in pretty straightforward way. So here we have just like a basic code expression and we're calling foo. And then we're extracting A and C because A and C are futures. And we have this foo function that's defined over to strings. And what that actually just translates to, translates to is a call to applicative.apply to AC and then we stick in the foo and underscore underscore. So in this case, actually writing it out like manually actually seems to be simpler than using expression. You start getting gains when the expressions are longer. But what's really interesting is this is, there's no like magic going on. It's just rewriting things into stuff that you could write manually. And so here I just want to talk a little bit about the importance of using the least powerful interface. So in this case, we could have used bind or flat map in order to implement this because bind is a more powerful function than apply. You can express anything with bind. But like I said, bind, you can't fail fast. So it's a trade-off here. If you're using bind, there's more things you can express as a user but as the implementer of bind, you have less flexibility. When you're using apply, there's less things you can express on the user side to use apply but as an implementer of the apply function, you have more flexibility. And that's just like, that's a trade-off. So the idea of this notation is to use the least powerful interface that's necessary to translate the sugar code into de-sugar code, allowing maximum flexibility for people implementing the instances of your type classes to provide the glue code, the functionality that they want to provide. So here's another example. In this one, monad is required because we have this foo function operating over strings. We have a bar function that operates over a string and returns a future of string. So we end up having to extract a to pass it to bar and then we need to extract again the result of bar and foo. And so there's no way you can do this with apply. So in this case, the notation is smart enough to detect, if you will, that it needs to use monad and it's going to use bind in order to implement this. And then here's an example with the if statement just to show how simple the transformation is. So we have if extract A, extract B, else extract C. This is like super simple and it just translate to bind over A and then if A is equal to something, then produce B, LC. There's also the case of a match statement, sort of very similar to the if statement. The translation is pretty straightforward. It does get sort of interesting when match statements get a little bit more complicated. Here's an interesting case. So expression supports blocks. So here we have a block and then we're extracting foo, which is a future, assigning it to foo y. So now we can sort of imagine that foo y is an actual string. And we're extracting bar matching over that. And then I don't know how many of you are familiar with this notation. I actually think I learned it like not that long ago. I'm stable identifiers in pattern matches. So this foo y, instead of binding bar to foo y, we're actually checking if bar is equal to foo y. And you do that by putting back ticks. Because by default, if you just put an identifier there, it's going to bind to that value. It's not going to compare based on the value in scope. Even if foo y is defined up above. Anyway, so in this case, we want to check that they're the same. If they're the same, we extract b, else extract c. And here, we're assuming that it's either going to be foo y or two. And the translation there is a little bit small, and you probably can't read it all that much. But it's basically because it starts to get a little bit more hairy when you need to do these things. Yeah, anyway, I'm a little short on time, so I won't go too much in details. Feel free to ask questions later. And it can get really hairy in this case, where you have two of them. And here's where you start seeing the advantage of expression. Clearly, it's easy. Well, I believe it's easier to reason about the above code than the equivalent manual code that you'd have to write yourself in order to get the desired behavior. And as a side note, match statements are definitely, as the implementer of this expression macro, match statements are the hardest thing to reason about. They're definitely where all the complicated cases are. So there are some similar projects out there, which is comforting, because I'm not going down this rabbit hole, hopefully. So Effectful is a really interesting one. Its stated goal is to generalize Scala async await. So in a way, it's very similar to my project. Unfortunately, it does not use the least powerful interface. So basically, like for Comprehensions, it's always going to use bind or flat map, because you can't do that, but you can't fail fast. And that was my main motivation at the beginning. Possibly, if I knew about Effectful when I started working on my project, I would have just figured out if there was a way to do this in Effectful. But when I discovered Effectful, I was pretty far along, so I decided I had more facility working on my own code base. Scala Workflow is a really interesting one. It's been there for a while. It's unmaintained now. It's super featureful. It does all of this and a bunch more nested abstractions, like manipulating the context from within the notation, all this really cool stuff. But it's based on untyped macros, which are now sort of deprecated in Scala. And so it re-implements, because it's based on untyped macros and it receives an untyped AST, it actually has to do like a ton more work. And I'm not convinced that all that extra work is necessary. And because it has to do so much work to provide the same functionality, it actually supports a very limited subset of Scala, because it's so complicated. I was actually having a conversation with Eugene the other day, and he knows the guy behind the project. And he was saying that he ended up having to almost re-implement scoping in Scala within his macro, which is a little bit crazy. And then there's Async Await. Async Await seems to be, a lot of people know about it. Based on C-Sharp, so like C-Sharp has this cool thing, but it's sort of baked into language, which is unfortunate. So Async Await tries to provide that in Scala with macros. And there's actually a SIP to include it in the standard library or something. I'm actually a little bit scared of that, because I looked at the implementation and I don't know. It only works with Scala futures. It doesn't work with Scala Z futures. It doesn't work with Twitter futures. It doesn't work with any of the other abstractions. It doesn't fail fast like I don't really see what it's going, what it has going for it really. One could argue that because it's specialized for this one implementation of futures, it could exhibit superior runtime performance theoretically, but I don't know if that's actually the case. So in terms of my own projects, what are some of the known limitations and what are things that are known to work? So I have a pretty extensive test suite. This is like a really fun project to test actually. You can write specs that are super, I mean Scala check properties that are really generic. So function application is known to work pretty well. If else statements, function currying, surprisingly enough, I actually spent time on that string interpolation blocks and basic match statements. And where I know very well that starts to break down currently is in sort of, well pattern matching and value definitions because that's actually sugar and then the Scala compiler is going to transform into a match statement and complicated match statements tend to not work all the time because I just haven't had the time and also because Scala macros in their current form are a little bit hard to reason about and sometimes just really hard to work with. So when should you use expressions? By the way, any questions? Okay, so just to, yeah. So that's like a separate problem. It's a really interesting problem. So Twitter futures, you can cancel them. The problem is stopping a thread on the GVM is deprecated. It used to exist and they weren't able to get it right so they deprecated it. So the idea of stopping a thread is not really possible, although maybe, I think recently in Java 8, they might have started revisiting that. So what Twitter futures are gonna do is whenever you flat map, they're gonna insert their logic within the flat map to say, oh, okay, we flat mapped and this bullion flag was changed to true, so let's not execute the continuation. But if you're sticking a database access or some long computation within a future and you're never flat mapping over that, there's just no way you can be able to cancel it and that's like a GVM limitation. So unfortunately, this doesn't address that anymore then. It would be some possibility, but I mean, first we cancel it. Because you can't take out.  Oh yeah, sure, yeah, some other thing. This is just a GVM limitation. Yeah, some other thing, of course. If the runtime allows you to cancel a thread, then you could totally expose that through a future-esque API for sure, yeah. Okay, so just, I'm running out of time, but give an intuition on when you'd wanna use this project. So if you're writing, and this is a really strong use case, just a whole bunch of asynchronous code and you just have a whole bunch of futures and you just wanna compose them together in a sensible way and not have to be boggled down with the details of how you combine these things, then it's great. Like here in this case, we're calling these services lookup phone, lookup address, lookup reputation. We don't even need to think about the dependencies. In this case, lookup address depends on phone, so we need the result of phone obviously, but lookup reputation doesn't depend on address. It also depends on phone. So by using expression, it's sort of like, you can think of it as like it's gonna analyze your dependencies and use the right things and just gonna work in the most sensible way you'd want it to work. And another interesting use case is when you have like a large bunch of code, like here's using raptor JSON. And anytime you sort of like grab a JSON value using raptor JSON, it's returned as an option because it might not exist. So you have like all these options here, like so many options and you just like wrap the whole thing in expressions and you've got a match statement and if statements it just looks like normal code and in the end just returns you an option of the thing. Just quickly, I wanna mention it's not a replacement for four-compensions and I have a really good example here. So I work on remotely at Verizon, you should check it out, it's really cool RPC system in Scala. And in our code base, we have this function time which takes a task which is like the equivalent Scala is your future and it returns a task that has the same A, but now has the duration on how much time it actually took to execute the task. And in this case our implementation we use four-compensions, so we're calling test.delay, putting the current time, assign that to one and then task is assigning to A and then the current milliseconds. And because we're using four-compensions and four-compensions use flat map we can be assured that we're gonna check the time then we're gonna execute task and then when we're done we're gonna check the time again and two minus two one is actually gonna be the real time. But let's say you were to use expressions here, expressions even though it's a formalized thing you can think of it as it's gonna be like, oh man, you're not even using A in order to call task.delay so I can paralyze that, I can call task.delay right away and then you're not gonna get the desired result. So the way I think of it is like four-compensions is like more low level thing. If you actually need to sequence your things in a very precise way then you'd use four-compensions but if you just wanna stick together things in like the normal way then expressions is like a higher level abstraction. The future work is like to use Scalameta. There's a whole bunch of things, feel free to if you're interested come and see me. I think I'm going over time here.


It's Predictathon, eight days of Kay's NFL season predictions. And here she is with her pick, Kay Adams. Seven shows left until the start of the NFL season, and I'm going to be giving away all of my favorite smart predictions leading up to kickoff. Yesterday, I decided to bolt up Predictathon as we kicked it off. I said my MVP pick is Justin Herbert. Herbert, Herbert, Herbert. Charged as a quarterback today. I'm going to go in a bit of a different direction. I was thinking to myself, self, which team is going to be the New York Giants of 2023? Who's going to be last year's Giants squad? What does that mean? It's a team that went from last place in the division to a playoff spot the following year. Now, this team's being talked about a lot more than the Giants were at this time last year, but that doesn't matter. This is all about a squad that really is going to turn it around quickly, nailing with your draft picks, the key free agent additions. Young players making huge leaps in the year before. It doesn't happen very often, but it has happened two years in a row, Jags in 2021 and in 2022. So with the Giants, and I'm smelling a three Pete with the situation, my prediction for that team, the team that will be this year's Giants. Last place to the playoffs is the Bears. That's true. I know. Woo, cue the music. Last year was a tough one, guys. We saw some serious signs of growth out of fields. But the record was not pretty, but it wasn't like the Bears were getting crushed out there. Riddle me this. They lost six games by five points or less. They were close calls. They were right there, baby. And with the way that Ryan Poles spent this offseason building up the roster around fields, I think we're going to see a lot of those close calls start turning into wins. The DJ more trade, a lot of pressure on him, but he is that dude. The upgrades to the O-line, you've got Darnell Wright, the first rounder, they overhauled the defense. I do want to see that O-line like really spend some time together, some really quality time over the next couple of weeks. But they added to the defense. They did the whole Tremade Edmonds, TJ Edwards, friend of the show. We love TJ Edwards, a Midwest guy getting back there. We love that. Aaron Rodgers is gone. The back half of the NFC Playoff picture is looking wide open. There are so many reasons to believe in what's happening in Chicago right now. And if you're a believer, take a look at this, guys. You can still get plus odds for the Bears to make the playoffs over on Fandall Sportsbook there, plus 172, what a random number right now. So there we have it. I have a lot more predictions to give out before the season kicks off. Subscribe, follow up in Adams for the end of summer. Mega event, Predictathon, da, da. There's the voice of Predictathon right over there. Eric, what a segment. Predictathon. Can we hear a live one? Predictathon. That's pretty good. You've got a future.


All right. Well, welcome to another episode of the ADHC talks, which is a podcast where we interview digital humanities scholars about their work and their projects. I'm Sarah Whitver and I'm the Digital Humanities Librarian at the University of Alabama Libraries, and today I'm joined by Rebecca Salser, who is Associate Professor of Dance and the Director of the Collaborative Arts Research Initiative at the University of Alabama, which is an intermediate, Rebecca is an intermediate dance artist and educator, and she creates dance films and co-directs the Dancing Digital No Boundaries Archive Project, which is supported by the National Endowment for Humanities. So welcome, Rebecca. I am I am deeply intimate with your project. I love your project and I can't wait to share it with some other folks through this talk. So my first question is, can you tell me a little bit about your research? And what I'm particularly interested in is, when speaking of research, what makes you feel nerdy and excited? That's always my most favorite part of the conversation. Well, thanks so much, Sarah, for having me on the podcast and thanks also for your involvement with and advice on the Dancing Digital Project. You're really an integral part of it and I'm grateful for that. So I wanted to be sure to say that. I don't know if this qualifies as nerdy, but what gets me excited is dance and the body and what what the body can teach us about ourselves in the world, what kinds of knowledge are stored in the body. And then on a secondary level, because I work with dance film and and now dance archiving, how in this in this new new-ish time we're in, when we go to screens to find knowledge, we go to screens to experience art a lot of the time, what are the ways that embodied practice can be transmitted successfully by screens. There's some paradox to it for me, because when I started making dance films, one of the things that really entranced me about it was that a certain amount of intimacy is more possible when you are recording in some cases. I mean, you can get up close to a live dance performance too, but a lot of us experience dance performance distanced and there are ways that the paradox is that you're no longer sharing space and time necessarily with the performer, but you can feel more included and closer to what's happening. And so that's been a real interest of mine in terms of making dance films. And now with this digital humanities component of what I'm doing, that kind of grows out of that desire to share dance art and to share it in ways that people are accessing it now. Yeah, I love the through line of what is going on with your project, because it starts with this deeply artistic performance based mode and it moves through formats and it sort of transcends, I guess, categorization in a way all the way through to you know what we're going to be talking more about linked open data and metadata in a little while, but the fact that it takes this intimate performance based art form and moves all the way through into a highly computational project is deeply satisfying for me. So tell me about your history with digital humanities and sort of how you arrived at this project. I think you've sort of foreshadowed that a little bit, but how did you arrive at doing a digital humanities project? I know that you have a collaborator for the No Boundaries Archive. Yeah, Giselle Mason. And sort of what were those conversations like early when you started that project and that collaboration and how did it get to where it's at now? Yeah, so I, before I became an academic, I was an independent choreographer and performer and I came to academia pretty late in life and I started making dance films while I was performing and making work in San Francisco. So I was already a filmmaker when I joined academia. And then when I got my first teaching jobs, they were not in urban centers. I had been living and making work in urban parts of the world where it's really easy to see performance. And that wasn't true of the locations I found myself in once I started teaching. So what became really clear to me quickly was how little access we all have to dance recordings, especially high quality recordings and full length recordings. If you do a lot of searching, you know, you can see a lot of dance, but oftentimes what you're seeing is, you know, a minute and a half of a 20 minute piece. There are a lot of reasons for that that I've spent a lot of years thinking about. But it's still true, even post pandemic, even with a lot of new digital projects coming online, which is all good and positive and wonderful. It's still really hard to access high quality, full length recordings of things that I want to teach. So that was kind of my entry point. And as I learned about the challenges and some of the reasons why, you know, for 30 plus years, since the advent of video, there's been, you know, more of a push to have the access component and dance keep up with the technology. And it's, it hasn't. It hasn't for a lot of reasons. But one of the biggest ones is intellectual property and dances. Dance can often be very collaborative with, you know, designers of costumes, lights, sets, composer, stage manager, dramaturge. There are a lot of people that can contribute to a dance piece that all hold rights to the piece. Choreographer obviously is somebody who holds rights. And so that makes it hard to disseminate work, and especially hard to disseminate work that was made before the internet was a thing. A lot of the contracts that people signed when they gave their work, for example, when they gave their old beta tapes to the New York Public Library did not include sharing on the level that we look for now. So it's hard when recordings exist, it's hard to access them. I've kind of gotten off my train of thought here. Anyway, so I was mostly concerned with sharing full length video and how to get that into the hands of audiences, but also educators and scholars. If you imagine trying to teach choreography or if you imagine trying to teach painting, where in a situation where you can only show like the bottom corner of the painting you're trying to teach, like that's an analogy for what it's like to try to teach form in dance when you can just see excerpts and snippets. And I started off just reaching out to people who especially were connected with the Dance Heritage Coalition. They have spearheaded a lot of dance preservation and access projects and then the former director of that organization, Libby Schmigel, is now the archivist and librarian for Dance for the Library of Congress. And she had led a lot of this sort of, she had led one really important previous effort to think about how to share recordings in a secure way that couldn't just be copied and disseminated. And also she did a lot of work trying to call some of those VHS tapes that were under choreographers' beds and help digitize things and pull things into a format that could be shared. She's been really helpful and a great mentor and friend and cheerleader. And also Sally Ann Kriegsman who was the director of the Dance Area for the NEA for several years and ran Jacob's Pillow Dance Festival for a little bit. She was the executive director there and also was, I think she was the president of the Dance Heritage Coalition as well. They've both been really helpful in telling me, you know, this is what's been tried before, this is what's worked before, this is what we can build on. So the first, this is going to be a long answer, Sarah. It already has a long answer. The first thing that I was able to do is pull a lot of experts together onto the University of Alabama campus to spend three days kind of discussing what's happened, what can we build on, what's needed now. And that was really great. That was in 2019. And that group of 19 scholars, educators, notation specialists, legal specialists kind of ended up pointing towards we need to try to build something in a different way. Like there are things that exist now that serve as models and stepping stones that are important, but they're fundamentally built in a way that doesn't feel sustainable enough for us, doesn't feel like it can encompass some of the needs that we have right now. So let's build something new. So that's kind of where that group landed after three days of discussions. And then the question was what does this need to be? What does this new thing need to be? Some of our priorities were a resource that shows full length videos of dance, a resource that can be more than one freestanding proprietary thing, but can connect outward. That was really, really important. In part because contemporary dance, especially modern and contemporary dance, have tended to like dance companies are often named after the choreographer. And so that person's work kind of ends up in an archive sometimes. There are a lot of archives that are named for the choreographer that don't talk to each other. And there are a lot of connections between choreographers, but it's when everything is built on a different platform and everybody is underfunded and scrounging just to get the thing out into the world, it's hard to get to that next place where you can look across the internet and find resources. So those were a couple of the priorities. We also wanted to find material that represented BIPOC and women artists specifically because those artists are less represented online than men and European, men of European background for sure. So we kind of started to brainstorm and look and think and Sally Ann, who I mentioned earlier, knew Giselle Mason and knew her work and connected me to Giselle. And after several conversations and one presentation on a panel together, it started to occur to us that we had pretty symbiotic projects. So, you know, mine was dancing digital kind of like a group of experts and specialists looking for material. And Giselle was and is a 20 year performance project that she did commissioning and performing solo work by African American contemporary choreographers that she had really comprehensively documented in beautiful ways. She documented rehearsals. She documented performances. She documented interviews with the with the choreographers. She had kind of b-roll footage of her in the garden of a choreographer or on a subway going to rehearsal. She had all the performances documented. I think I might have said that already, but she she had been thinking archivally really early in the process in a really beautiful way. And she also had and I'm just another thing that made me really fall in love with her project, which is called No Boundaries. It's called No Boundaries colon, Dancing the Visions of Contemporary Black Choreographers was the extended time period. You know, she's learned she and her younger body are learning work in the early 2000s and then performing the same like going back to check in and rehearse with the choreographers over the years and performing again the same work in 2018. And it I felt like the collection really showed a lot like leaned into the strengths that digital collections can surface. So we began to collaborate in I think it was January of 2020 right before the pandemic. We met in New York right before the pandemic and but we realized that she had the perfect kind of seed for not only beautiful content but something that could become an outgrowth of more content. So then we were able to get funding from the NEH to build her a digital archive for the No Boundaries project. And then there's another chapter. Should I stop for a minute and take a breath or should I just go right to this next chapter? Well, I mean, I think the next thing we're going to do is talk about your current project. Oh, okay. So, you know, as far as you want to go and then we will start talking about your current project, which is very exciting to me. It's all very exciting to me. I can't express I sound like I'm just, you know, spouting hyperbole about my excitement, but I'm your project thrills me in so many ways. You go as long as you want. As far as that goes, I think, you know, as you're talking through this, I really, you know, I love what you did with your symposium. And like, I think if we have a moment to sort of revisit what happened there, you said it was 19 scholars. I believe that you had, did you have a little bit of grant funding for that? Yeah, we did. We had a planning grant from the NEH for that. And how did you select people to come? And what were those conversations like? How did you sort of plan that out? You've talked a little bit about the outcome with, you know, some values in place and sort of a project more defined and more scoped. But, you know, you put that together, how did you choose to, did your mentors help you select people to invite? Yes, my mentors were fabulous connectors, both of them. They both know everybody and because they've been working, working towards better access, they kind of know what's new and coming and they work great connectors. I also spent a few years before the symposium proposing panels at conferences and speaking at conferences, you know, doing presentations. And so those those conference moments allowed me to also create a network that I could draw and to pull these people together. Yeah, so it really was people from, most of the people were from the US. We had Eugenia Kim from Hong Kong was here, but she was the only non-US person. And a lot of them had a connection to an existing digital project or a previous one. There are several really beautiful digital dance projects that have become obsolete because the software has been retired or the, you know, like something that runs on Flash Player, for example, or just it's hard to find the continuous funding to sort of feed these projects. One of the people I met, Sybil Husky, from a university of North Carolina, she had a project called a video collaboratory and she was part of the advisory committee and came to that symposium.  And that's just really stuck with me because it's kind of, it's proven to be true in so many ways. Yeah. You know, like you're going to build a thing, but then the thing is going to need care and it's going to need feeding always as long as it's going to exist. It's always going to need that. When you stop doing that, it will go away and not be accessible again. So that was an important revelation for me. Yeah. I'm interested in some of these conversations because I often am working with folks who are at the very beginning of their careers and perhaps even graduate students and the notion of this network building and this collaboration, the spirit of collaboration, I think is very, you know, it can be very intimidating and people don't know where to start with it. And I think, you know, being able to talk to someone who has taken advantage of mentorship and has built a strong network of peers and colleagues to lean on as you're working through a project like this and having people tell you things like, you know, sustainability and preservation are big question marks when you go into a digital project and there are things that you probably should think about, you know, at the beginning and not at the end because if you spend 10 years building something, some of the technology might be obsolete by the time you're finished building it and then that's 10 years of your life. Yeah.  One of them is built on FileMaker Pro. Oh, yes. One of them is built with Salesforce. And just because the people doing these, you know, heroic acts of preservation, that's what is available to them. That's what, you know, a board member has access to Salesforce, for example, and can give you that for free. But it's not, it does not set you up to connect to anybody else. Yeah. Yeah. So I'm just, I'm underlining what you just said in terms of how, you know, thinking about the longevity of what you're building on and what its possibilities might be long term is really important. Yeah. There was a special issue several issues ago in digital humanities quarterly where scholars were discussing minimal computing and I found it so very eye-opening. They challenged, I think the editors of the special issue challenged us as practitioners to consider the possibility that our project could be carried somewhere that doesn't have internet and accessed on a flash drive. Like, what does that look like? And how do you build that out? And how do you take advantage of some of the very sophisticated technologies that allow for these very complicated projects, but also think about like how minimal access could happen with our projects and also as a measure of preservation. What are the archival standards for file preservation so that if the project that we've built out disintegrates through attrition, we still have the original raw files of data that we could build out another project for. So things like metadata and WAV files and TIFFs and JPEGs, like making sure that we have access to the archival standards so that the data is preserved even when the project dies. And that's, I think, a very interesting sort of spectrum to think about when you're, when you're building a project out because your heart is going into this, like, you think about that final polished project, but really, all of the labor is going into collecting and organizing and preserving the data. Sometimes people forget about the preservation portion of it. Yeah. And now I'm going to step into an area I don't know enough to talk about intelligent things, so please consider this thoroughly rough draft, but you know, in terms of video and sharing video, there is the TIFF format and, you know, universal viewers as an opportunity, like there are some opportunities for ways to be creative about who's holding the actual files and the ramifications of that. If that makes sense. I can't say much more and be intelligent about it, but just... Yeah. Where do you deposit your data files? Do you put them into an archive, you know, into an archive, or do you put them into an institutional repository? Do you want them to be democratically accessible? Is it who has the rights to them? If they have super, you know, clear rights and it's not open access or creative comments, content, what is the best place to put it so that it's being preserved and continually maintained? Yeah. With this project with Dazelle, we're very lucky that she's at UT Austin and they have the ransom center there who has agreed to serve as the archive of record for her collection, so they have the archival grade and size recordings, but the digital archive we're building has lower resolution, smaller, easier to stream versions of the video. Yeah. So that was... I mean, and while we're talking about, let me try to finish that sentence, that is a privilege. That is a privilege that we as tenured faculty in big public institutions have access to that most artists and collection holders and arts organizations do not have. So that's been very present for us thinking through what we make and how it can help other people. Yeah. I have heard stories of people saving it on single hard drive, like external hard drives, and I've heard stories of saving them on hard drives on desktops and then the desktop ages out and it's difficult to get that or the person who has the external drive passes away or becomes not accessible and then that data sort of passes into a place where nobody can get to it until perhaps it is found and then even then is it in a format that can still be accessed and there's so many, there's so many little considerations that I know are overwhelming to think about as you're moving through a project like this and you're right, the privilege of having places to store materials and have them preserved and cared for, right? It's not even just stored but if you are able to place it into an archive that has policies about digital content then you have caretakers and that's really incredible. Yeah. Yeah, it has been. I should probably tell you about what we're doing. So the grant that we got from the NEH was to build a digital archive for this collection of multiple performances and rehearsals of these 10 solos and which is you know a pretty, it's pretty self-contained little logical collection which is lovely. At the same time, we're trying to build it in such a way that it can be generalized and shared as a template for other artists. Yeah, it's had sort of a split brain as we've been thinking about what kinds of fields are necessary, what kind of information we want to capture. We are finishing that end of this year, December 31st. That is when it's going to be done and ready. We're going to share it with the world. So we're definitely in the kind of push to get that up and running. We have been trying really hard to both Giselle and I are dancers and dance makers and we have been trying to allow that methodology and knowledge and ethics to lead the project to lead what we build. And that's interesting and challenging. So an example of that is it's just punishingly hard to tag videos where it's just movement and maybe the choreographer is giving information just by making sounds. Like it's not so much a it's more of a something like that and you're like, okay, great. How do I translate that into a word that allows somebody to find that? Right. So that's not a new problem that we've discovered, but it's something that we're trying to figure out how we want to negotiate. And one of the ways that we're trying to do that is to create features that allow the user to compose themselves. So you, you know, hopefully if all goes according to plan, this is what is being made now and so far so good. You will be able to see a video and clip, create a clip for yourself, annotate that clip and either put it in a playlist that you can save and come back to. So if you're teaching from this collection, you can have a playlist that you can show the class without having to go back in and scrub through each video and find each section. You can also take those clips and compare them side by side on the screen. Maybe you want to see BV Miller performing her work Rain in, I'm guessing it's like 1984 or something when it's made. I could be wrong about the exact date. And then you want to see Giselle Mason performing the same thing in 2018 side by side. You can play the same moment of the same dance and see or you could see Giselle performing it in 03 and then performing it again in 18 and see what's evolved, how she's changed, how her interpretation has changed. So those are a couple of ways that we want to allow the viewer to choreograph the material. Yeah. Essentially, we also hope you can find things with, you know, searching and tags and all of that. But yeah. Yeah, so that's that's what we're doing right now. It reminds me of the kind of work that linguists do when they're trying to like annotate and take notation of a new language that is not a written language and how to express sort of the sounds. It's been it's been a little while since I've, you know, refreshed myself with linguistic terminology, but, you know, you make a phonetic sound with your mouth, and there's a way to phonetically write that out. But then it also has so much freighted meaning with it, right? And you're trying to not only capture the phonetic communication that is happening. Yeah. But also like all of the the connotation and the denotation that is happening with those very simple sounds that allow a dancer to make a movement or alter an asset, right? Yeah. I mean, what you're what you're saying connects to the just really wicked problem of dance notation. Yeah. You know, there are some wonderful dance notation forms and some people who are very good at notating and translating reading scores. But a lot of us don't know how to do that because it's tricky enough that it's not taught in a dance studio, for example, if you're going to attend a dance studio. I mean, a lot of universities teach it. But, you know, if you think about music and how many variables are recorded in a music score, I'm not quite sure how many, but I'm thinking, you know, pitch, time, dynamics, instrumentation, loudness, I don't know, I've reached the end of my knowledge there. Yeah. But think about dance and, you know, you have a whole lot of joints and you need to notate down to this one, because it's really different to do, you know, this than it is to do this and then that is that needs to be notated in in time, in space, in relation to other bodies in space. Right. And it's it's a big job. So yeah, yeah, it's it's one of the reasons why video is so important in dance and sharing video and creating access to video is so important in dance. Video isn't notation of dance. But it is. It's a very useful record. Yeah. Yeah. Well, let's talk about the wiki based project, because I, I'm excited to hear how this is translating into metadata that is universal enough, the establishment of an ontology or a vocabulary that is flexible enough to apply to multiple projects with this, you know, ethic or this ethos of of dance and choreography as the forefront that you guys are building. So how is that going? Yeah. So we're at the beginning of that chapter of what we're doing. And I have to say that kind of hard kind of reaching back to what you were saying about starting with the embodied and getting to data, like, I would never have imagined this is where I would be working. And this is what I would be thinking about like this is exciting. And the learning curve is steep. And that makes it kind of fun and exciting. But also, I think it's just really improbable that I'm deeply in this sort of library science and information science world now. But so what, so we knew that what we wanted to build, we wanted it to be more than just a free standing proprietary website that didn't that didn't connect out. And so we started to look at linked data as a way to connect out to other resources. But we also honestly started to look at linked data as a way to reduce our labor. And thinking about if we if we create something that can be generalized and shared as a template, we know that other dance artists really are going to need a way to reduce the labor of data entry. Right. So what we imagine doing initially with linked data was to ingest kind of existing subject authorities. Looking at the Library of Congress subject authorities looking at V off, what does V off stand for? I'm not okay. This is all this is a little new to me as well, you know, reaching out to my network of people to help me know what's going on. I understand on a high concept level, what is happening. But when it comes to this, I've, I spent my summer reading a book on linked open data. I'm still getting there. Yeah, well, I'm with you, Sarah. I am certainly not an expert. I am I'm with you. And I've also been really gratified to find like Stephen McCall, who you have two people on this campus who know a lot more than I do who are really useful advisors. But so there are a variety of subject authorities. One of the ones is, I think it's V off is run by the getting museum and it's very heavily around visual arts. I could have that wrong. It could be a different one that I'm forgetting. And also we looked at wiki data. Right. Because wiki data has authority records on a lot of artists. Yeah. And we actually found that wiki data.  So that was our initial. How can we how can we reduce our labor. But then what we encountered was that none of them had a lot of information about dance artists. A lot of what we found was wrong. And especially there was especially scant information about women, BIPOC artists. They just they were not in the record. And that that caused us to think. And by us, I want to include Worley gig. They are the developers we've been working on working with. We've also been kind of working on them. They would probably the first to say we're building on a system that they developed called collective access, which is an open source cataloging software. And they have been really good collaborators with us. They have been willing to think about how the software that they developed can shift and change and accommodate our needs. And I credit them with this realization that what if we could not only ingest this information from existing subject authorities, but also push archival information back to to a data commons to help enrich the record to help populate the record with some of these missing voices. So they began. Meanwhile, back at the ranch, we were also realizing that wiki data had more information. They didn't have a lot, but it had more information on the dance artists we were working with versus L's no boundaries collection than any of the other subject authorities. And because it's crowdsourced, it also then opens a lot of doors in terms of opportunities for this kind of for conceiving of the idea of pushing data back to it. So that's become a focus of ours now. We are thinking about this kind of multi-part system right now. I'll draw with my hands like here down here. This is wiki data. It has like a hundred million pieces of linked open data crowdsourced right here in the middle is something that we're calling the dancing digital commons, which is a data commons of dance that we imagine we can. We're going to have to find a balance between democratizing and curating that is going to be a big part of this next step of research. This piece here, this dancing digital commons can periodically push data to wiki data and it can also ingest data from wiki data. And then there's a constellation of other archives and eventually hopefully other individuals who can push data to the commons. And so the dancing digital sorry the no boundaries archive that we're building that is one that's going to be able to both ingest from and push data back to the dancing digital commons. But now it's really exciting for us that other performing arts organizations have expressed real interest in working with us and letting us try using their data to populate this commons. So we have two really great big partners right now Brooklyn Academy of Music and Jacob's Pillow Dance Festival. Both old storied presenters of performing arts that have done a great job in terms of like they are the leaders within performing arts preservation and access. And so we're really excited to be working with them. And I can show you a thing if you want me to share my screen and show you a thing.  I meant to do that earlier. I'd love to see. Okay, so this is a very early demo of what we're working on. Worley Gig has and specifically I'm going to credit why Ian Kwan is one of the developers at Worley Gig. She's been working really hard on this to use Wikibase and the wiki data integration model to create this digital data commons that's based on our collection, which is the no boundaries collection. I'll show you what that looks like. That's got it's actually bigger than this. This needs to be updated. You can get a sense of, you know, here are the solos. Actually, you might not actually be able to see this all that well. Let me drive this a little bit to make it bigger. Come on, baby. And somewhere in between. Okay, having trouble with my mouse. But like here's a solo no less black rain. Rain is choreographed by B.B. Miller. Costume designed by Muriel Stockdale. We have a little duplicate here. Maybe B.B. did some of the costumes and Muriel did some. I'm not sure. The composer was Herne Gagbois. Lighting designer Jezelle Mason is sort of the she's dancing all of these in our projects. So she's kind of becomes the center. So this is the no boundaries collection or most of it uploaded to wiki data structured as linked open data. Yeah. I don't know. I don't know if we're running out of time if it's helpful to talk about the triples you can see here or what do you think Sarah? I think we have about 10 more minutes. It's 11 43 right now. And we have the full hour. Okay. Well, if you like me are are new to linked open data, what I'll say is according to my understanding of it, it's a way of structuring data to give a piece to give each piece of data a stable address on the internet kind of like a URL, but it's called a URI. And the way that it's structured is in triples. It's two entities with a property that that connects them. So in this case, it's going to be the piece jumping the broom. Jumping the broom is one entity. David Rousseff is another entity. And the property that connects them is that David Rousseff choreographed jumping the broom. So this one triple here, this is one chunk of linked open data. Yeah. For linked data. And it's, it's open because it's not proprietary that his name and the name of the piece are not proprietary. Yes. So that's the no boundaries collection. We can look at it in this nodal graph on wiki data. This is what wiki data has, this might take a minute, has that is pertinent to the artists in the no boundaries collection. They obviously have more information about dance artists. But this is what wiki data has for the dance artists in the no boundaries collection. They have 51 records. Right. And it's interesting, like pick one. If you can see. Yeah. Like Jaula will it Joe Zoller is a very prolific choreographer. But clearly what's happened is that the places that have the that have the resources to contribute to wiki data are the universities she's taught at. The awards she's gotten that Bessie and you'll see a lot of these folks won Guggenheim fellowships. Her work is not her work is not represented on wiki data hardly at all. Like these are where she's taught where she's performed. She was a MacArthur fellow like. Yes. These are the places that like so we're missing the work. That's what wiki data is missing largely. Then if we add I'm just going to add all of them together in the interest of time but BAM has thousands of records. Jacob's fellow has thousands of records. This again this little compare demo is just pulling records that are relevant to the artists in the no boundaries collection to those 10 choreographers. So you can see immediately it's going to take a minute to load. I'm riffing. I'm riffing. I'm vamping. Dancing here while we're loading. But you can already see that it's loading a lot more records by our relationships. Yeah. I think it's fascinating when we're looking at this kind of graphic. So my area of scholarship is is digital rhetoric. And from a rhetorical standpoint you can really assess audience of each of these entities wiki data and BAM and Jacob's pillow and no boundaries by seeing the type of data that they value and include. I think that's that's a really interesting you can you can you can make some basic assumptions about the organization when you look at the data that they are able to provide that they contain. I think that's a really important point. One thing that we've learned by this visualization and I don't know how much I need to zoom in here because you can kind of get the idea that there's a lot of artists and a lot of or these are the 10 artists again but so much more work. Yeah. This is actually the work being represented not just where they thought. But a couple of things ripping off of what you said one is when we there was another demo that allowed us to search for a particular artist and I don't need to share that right now but it was a oops did I stop sharing I tried to stop. You're still on. Oh just moved it and moved to stop sharing. Okay. So we would put in the name of an artist and it was such a clear visual representation of who's missing because George Balanchine was a name we put in a European male choreographer. And you know I think it was 380 or something like that records came up his work his relationships his students. He is in the record people have taken the time to put him in the record of Wikipedia as well because wiki data also includes the data from Wikipedia. Then we put in Martha Graham who's a white who was a white female choreographer and we just saw it shrink. Some of her work was represented but she maybe had had 60 records as opposed to 300 and something. Then we put in Alvin Ailey who is a was an incredibly prolific African American contemporary choreographer and initially it's it's more now but we got 10 records for him and they were all awards he won. I mean this is a person who whose work has reached you know he's made 80 he made 80 plus important works seminal works of dance that reached I want to say and I've read this so I don't think I'm making this up 25 million audience members yeah live audience you know like really important artists in this country and there's no he has no digital footprint yeah harder to study he's harder to find so that was one thing that this visualization helped us understand but the other thing is as we've been working on the archive being able to come back to this visualization has been really instructive because it's like oh Robert Battle is floating over here in a little cloud by himself there's actually no connection to the rest of the archive yet we have to illustrate that relationship right so that's also been really interesting um but we're hoping to build this for real this is a this is um one of the for real things that will happen with this is um clear attribution so if you were to click on a work or an artist you would you would get sent to the archive that links to the archive that provided the information um it might even have been with this um you know universal viewer and I have stuff I'm talking about it might even be that you could watch a you could watch a video by clicking on the link that's that's a dream for me I'm not sure how close we are to that and obviously that's going to depend on um it's going to be on a case by case basis in terms of who grants the rights for that to happen but what we want is this kind of um universal finding aid where um archives connects together you can find those materials you can use those materials um and you can visualize the connections that happen across the field that's what we want that's what we're hoping to build well well you're taking you know pragmatic steps towards that and have like that long term goal and short term goals and mid term goals and they're all connected in a way that makes sense I can see the through line um I I just I love hearing every single time you talk about this project because I learned so much and I just uh it makes it easier for me when I talk to other people about their projects because everything in your project always seems to me like it's so well thought out and um planned and I like that about your project you might not feel like that I don't I mean I'll just let that sit there then if that's what it feels like to you it has been um research in the best way though that you know I think one of the things that makes me love being an academic is that you can follow a thread and and you don't necessarily know where it's gonna take you yeah and I really did not know where this was gonna take me but it's exciting and um yeah it's fun yeah I've been doing a lot of uh sort of familiarizing myself with ontologies and vocabularies and how those get incorporated into projects um I I don't work in collective access but I work in OMECA S which is a similar platform um and it has a lot of the same you know qualities and values for linked open data and organization of of items and assets and the ability to associate things with each other um in the way that you're describing and the the idea of because we have so many different OMECA projects happening at the Alabama Digital Humanities Center the the balance that I see people constantly having to find between um their desire to describe something rhetorically specifically and accurately and their need to be able to describe it in universal terms it's always such there's such a there's such a um a pull with that right and I think that um the incorporation of the wiki-based commons for your project is really pulling that into focus in a way that is translatable outside of dance um into other projects that that I'm seeing happening um just as sort of a a framework for finding what's really truly necessary in your descriptive metadata that can transcend the particulars of your individual projects right like yeah there are some data that's going to be in no boundaries that is not going to be in the dancing digital commons right because it's going to be very very specific to the vision and the mission of no boundaries and may not may not be universalized yeah well thank you for bringing this up because I'm just like hey we made a thing and look here are the properties but there is so much conversation and consideration around what are those properties and um an example is that a property used in dance on wiki data a lot is ballet master now that is not a term that we want to perpetuate it doesn't work with the no boundaries project at all um and um but since it's so present in the in the data using it would allow the data would would allow our project to be found more readily yeah yeah so so it's that question of like how can we push can we push dance studies here how much pushing can we do how much of new world-making can we make here in terms of how we describe things and how much will how much do we need to be discovered in a in a in a in a way that conforms to existing structures and standards yeah this is the eternal yeah like metadata yet question right there's metadata data librarians across the world having these very conversations about you know um terms that are no longer appropriate and even organized in a fashion that is no longer appropriate to the society that we live in but like it is so embedded that it's impossible to weed out so how do you find ways to um create relationships with terms so so you have the term ballet map master and perhaps you know within within your ontology you have relational synonyms built in so that it's you know these are the terms that we use now and when somebody types in ballet master you get a uh instead see this list right right or if you hit ballet master in you know another project it will take you to these these these newer terms right a note in it right and it's it's fascinating how a project like this can also move forward the language and the values of the field i i might have this wrong but i think it was in an article by maria patchouelli at prat um i think that's where i'm getting this information but that you know a wiki data system like this has a lot more flexibility though too it's because um because it's fungible because it's possible to find things in multiple ways um maybe as opposed to sort of an older archive structure an older catalog structure there's some opportunity yes yeah so that's also exciting yeah i i'm excited about it i'm excited because you have the opportunity to do so many so many things and make decisions about some of these things in a way that is thoughtful and progressive but still connected to the history and the legacy of your topic so i think we're about out of time and i could just talk about this forever and i'm so grateful for you joining me um and i hope that whoever you know accesses the podcast will come all the way to the end because i think a lot of the really good stuff has come in the last you know 20 minutes or 15 minutes here but um thank you so much for joining me today for this conversation thank you so much for having me it's always um both fun and instructive to talk to you so i really appreciate it yeah yeah i have um i i'm probably going to need to chat with you about a couple of things sometime in the future but um it's it's kind of in the pipeline so but good luck on your project i know that we're waiting to hear about um some future funding uh my fingers are crossed i have a you know a great deal of confidence in this project and i'm so grateful that i'm able to to interact with it thank you so much yeah all right bye


So it seems in life we get busier and busier, busier with work, busy with school, busy with kids. But does all that business really make us happy? Research would say no. There's a story I want to share with you that maybe will help focus a little bit on what's really important in life. And the story goes like this. It was once a very strong woodcutter and he asked for a job cutting down trees. The pay was really good and the benefits were not too bad. So he determined that he was going to do a great job. So he went to his boss, his boss gave him the axe, showed him where to chop down the trees and he went at it. The first day he fell to 18 trees. Felt pretty good, pretty proud of himself. Told the boss, boss was happy. The next day the woodcutter went out and he chopped down 15 trees. Not bad, not as good as the first day, still pretty well accomplished day. The next day the woodcutter went out and he was only able to chop down 10 trees. He started to think to himself, maybe there's something wrong with me. Maybe I'm losing some of my strength. Not sure what's going on. So he went to the boss, the boss said to the woodcutter, well when's the last time you sharpen your axe? Woodcutter said sharpen my axe. I haven't had time to sharpen my axe, I've been too busy cutting down trees. Abraham Lincoln once said, give me six hours to chop down a tree and I'll spend the first four sharpening the axe. We get so busy sometimes that we forget to slow down, we forget to sharpen our axe. Being busy doesn't necessarily make us happier. Why is that? Could it be that we've forgotten how to stay sharp? There's nothing wrong with activity, there's nothing wrong with hard work, there's nothing wrong with being busy, but we should never get so busy that we neglect the truly important things in life, in our personal life, by taking time to get close to our creator, giving more time to our family, taking time to read, learn a new skill. We all need time to relax, to think and to meditate if we're going to learn and grow. If we don't take the time to sharpen our axe, we'll become dull and we'll lose our effectiveness.


Many horror stories exist out there that stem from one common cause, manipulation. Even the word has a scary, slimy tone to it. But have no fear, Psych2Goer. There are measures you can take to protect yourself. Here are 10 signs you're being manipulated. Number 1. They constantly make you prove yourself. They never respect your boundaries and always ask for your love and attention. They are usually impatient, demanding, and selfish. You often overextend yourself because you fear upsetting or letting them down. They never let you off the hook and guilt-trip you into doing things for them, even if it's inconvenient for your schedule. Two. They communicate passive-aggressively. Manipulators are rarely ever direct with their sly and cunning behavior. They prefer to communicate passive-aggressively and won't hesitate to talk about you behind your back. This protects their good guy or good girl image. If they also turn to a middleman to communicate for them, this shows they are afraid to confront you personally. Manipulators desire control, which means they have a hard time facing their fears because it means letting go. Three. They gaslight you. Gaslighting is a manipulative technique that makes you feel like you can't rely on your own memory anymore.  They will often twist the truth and reinvent it, which makes you question your sanity. Gaslighting isn't just manipulative, it's a form of serious abuse that is dangerous. To learn more about it, check out our video Ten Gaslighting Signs in an Abusive Relationship. Four. They're always just joking. It might seem harmless at first, but manipulators can take their jokes too far that end up hurting you.  Manipulators won't mind embarrassing you in public either.   Five. They play the victim card. When the two of you fight, manipulators will always make you feel like it's your fault. They try to play the innocent victim who is badly hurt by your words and actions. Manipulators are experts at looking like helpless small creatures. They never believe they've done anything wrong. As a result, you find yourself apologizing all the time because they avoid taking responsibility for their own mistakes. Six.  Manipulators will try to be the nice guy or nice girl and do favors for you that make you feel pressured to return them. On the surface, they will buy you gifts or give you compliments. But then, the next time you guys hang out, they might hint at wanting an expensive watch that's out of their budget. In reality, they were only kind to you because they had other motives. Seven. They make your problems feel small. Manipulators always want the spotlight. If you ever complain about a bad day you're having or all the difficult situations you're going through, they will play the comparison game and minimize them by talking about their problems. For instance, if you complain about a sunburn you got, they might talk about the aches and pains they got from exercising. Manipulators do everything they can to get the attention they want, even if it means buying your pity. Eight. They emphasize their calm, cool, and collected side.   They will be dismissive of your emotions and often refuse to talk to you until you've sorted your feelings out. Nine. They use emotional blackmail. If they tell you that they will die or harm themselves if you leave or break up with them, then they are trying to gain control by threatening to hurt themselves. This leaves you in a highly uncomfortable and unfair position where you feel obligated to stay against your own will. Not only is this toxic, but it risks their own health on the line. It's best to contact the police before things get out of hand. Ten. They take advantage of your trusting and sensitive nature. Manipulators often target insecure, sensitive, and overly trusting individuals. If you're usually told by others that you're too nice or tend to wear your heart on your sleeve, take precaution and keep your vulnerability at bay. Manipulators are skillful at spotting people pleasers who often put their needs on hold to take care of others first.  It's their subtle way of luring you into their trap, so watch out. Do you think you're being manipulated? Please share your thoughts with us below. Also, don't forget to subscribe for more content from Psych2Go and check out our Patreon. Thanks for watching!