I started re-remembering my own fic (although I don't know if there's really much point, since it's all tagged anyway), but I can't do that with stuff from other people's journals. *woe*
I gotta do something I'm just not sure what. What if an import-memories function gets added? How much work do I really want to do? And yet, not being able to find my stuff drives me NUTS.
Part of the problem with Memories in general is that they are site-specific, not content-specific. Posts by other people become completely different URLs when they transition from one journaling service to another. Posts by other people vanish when the journals vanish. Posts by you that you've memoried can't (at this point) be auto-memoried when you transition your posts from one journaling service to another.
The only way I've come up with to possibly mitigate even some portion of the misery the idea of going through my LJ and IJ memories of my own posts and tagging those posts, because then the tags travel with the content when I transition via the Dreamwidth importer. But that doesn't mitigate the problems of my memories of other people's posts...
Even using something like del.icio.us rather than the memories function only gets us so far... when the content is replicated to another journaling service, the new link doesn't show up in my del.icio.us, and none of the import tools include a "originally posted at site/12345.html" link that might be back-trackable by a scraper program. When the original post of the content is removed? The connection between my memory keywords and the original post's content is gone, gone, gone.
yeah, it's a bummer (she said, ignoring the appalling number of memories you quote below, that take us well out of bummer-ville), though I can think of a couple ways to code xfering memories you've made on an LJ instance of your own entries and import them at the same time as importing entries from that LJ, or if the importer tool does some history tracking you could have it be a separate tool. (You need to be able to link the old entry to the new, so either that gets done at the time of import by the entry importer, or, if the entry importer provides the right kind of historical information, in a separate and distinct import that refers back to the same linkage between old and new.) That only addresses importing memories of your own entries (which are easy to identify because they've got your username at the start of the URL), of course. Which was what I was thinking of at the time I bitched. However...
Importing your memories of other peoples entries is easy unless they are also moving their journals, because the URL that was memorized on your old journal is still good. If the URL being memorized is about to be bad, that opens up another kettle of fish.
One *could* look through each memory link, and then search via a couple different approaches, depending on how clever you need to be. And then it depends on how data is stored internally and whether we're talking about a standalone external tool or a DW application. Like, if you're trying to check "has X been imported as an entry into someone's DW account", you need an importer history, assuming the importer keeps some kind of history, to check the originating URL. Easy if you have database access. That's the easiest approach, and your tool wouldn't even need to keep tabs on things like "has the privacy setting changed on the imported entry" because you'll find out the hard way if you click on the link to it, which is normal (meaning, unsurprising to the average LJ user). I'm going to pretend I have access to DW's innards at this point, because the thought of spidering the whole system and then comparing content via a regex would make me cry, but could be done. You could even get clever based on some social engineering (most of us have the same username across multiple LJ instances, narrowing the scope of a search considerably). If that level of data (original URL | imported entry's URL) is not tracked by the entry importer, it should be, IMO. But I see a way or two around it, they're just very brute-force-y. (I'd be tempted as part of the final release rollout to force everyone to re-import their journals if this kind of data isn't being tracked already and the entry importer needs to be run again to capture it. This is what beta-testing is FOR.)
The problem's inherent to bookmarking in general, as you pointed out - you don't control the content's location so you can't stop linkrot if the content disappears.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
ninetydegrees
no subject
on 2009-05-03 02:00 pm (UTC)I started re-remembering my own fic (although I don't know if there's really much point, since it's all tagged anyway), but I can't do that with stuff from other people's journals. *woe*
Yeah,
on 2009-05-03 05:04 pm (UTC)Re: Yeah,
on 2009-05-03 06:22 pm (UTC)The only way I've come up with to possibly mitigate even some portion of the misery the idea of going through my LJ and IJ memories of my own posts and tagging those posts, because then the tags travel with the content when I transition via the Dreamwidth importer. But that doesn't mitigate the problems of my memories of other people's posts...
Even using something like del.icio.us rather than the memories function only gets us so far... when the content is replicated to another journaling service, the new link doesn't show up in my del.icio.us, and none of the import tools include a "originally posted at site/12345.html" link that might be back-trackable by a scraper program. When the original post of the content is removed? The connection between my memory keywords and the original post's content is gone, gone, gone.
:-(
Re: Yeah,
on 2009-05-03 06:24 pm (UTC)My elke_tanzer journals have 16,916 Memories on LJ, 232 on IJ, and 5 on DW.
Re: Yeah,
on 2009-05-06 04:32 am (UTC)Importing your memories of other peoples entries is easy unless they are also moving their journals, because the URL that was memorized on your old journal is still good. If the URL being memorized is about to be bad, that opens up another kettle of fish.
One *could* look through each memory link, and then search via a couple different approaches, depending on how clever you need to be. And then it depends on how data is stored internally and whether we're talking about a standalone external tool or a DW application. Like, if you're trying to check "has X been imported as an entry into someone's DW account", you need an importer history, assuming the importer keeps some kind of history, to check the originating URL. Easy if you have database access. That's the easiest approach, and your tool wouldn't even need to keep tabs on things like "has the privacy setting changed on the imported entry" because you'll find out the hard way if you click on the link to it, which is normal (meaning, unsurprising to the average LJ user). I'm going to pretend I have access to DW's innards at this point, because the thought of spidering the whole system and then comparing content via a regex would make me cry, but could be done. You could even get clever based on some social engineering (most of us have the same username across multiple LJ instances, narrowing the scope of a search considerably). If that level of data (original URL | imported entry's URL) is not tracked by the entry importer, it should be, IMO. But I see a way or two around it, they're just very brute-force-y. (I'd be tempted as part of the final release rollout to force everyone to re-import their journals if this kind of data isn't being tracked already and the entry importer needs to be run again to capture it. This is what beta-testing is FOR.)
The problem's inherent to bookmarking in general, as you pointed out - you don't control the content's location so you can't stop linkrot if the content disappears.