24 Matching Annotations
  1. Feb 2023
    1. Some systems require a unique identifier, but the people who are using a datetime stamp or random number anywhere in their (Luhmann-esque) zettelkasten title (here's a good example) are leading you astray. Doubly so if it occurs at the beginning of the title. There are no affordances in this practice and it's more likely to cause problems at scale. Just say no! (Note this is not the same as using a Luhmann-esque identifier at the start of a title as a means of providing a sort order of one's notes held in an individual folder.)

      Are there any reasons for someone to do this?! - perhaps for file name conflicts when digitally inserting notes into a system using third party clients with titles which may cause conflicts (though these could/should be removed later for easier reading); - counterexample: https://hypothes.is/a/Jux0pq7yEe2Uqj9mFXS3nQ - Another potential issue is in shared or collaborative note taking spaces where collision is more likely because others don't have the shared context. - perhaps for forcing sort orders on daily notes or recurring meetings MeetingA YYYY-MM-DD, etc., though these are probably in a separate area of one's box and not in their zettelkasten section.

      The point of a zettelkasten is to provide one help in ordering and building their knowledge, not in ordering their notes by time created. This will rarely (sans database-related use cases perhaps) provide any insight and digital systems have other easier and better ways of doing this if you need it.

      Worse, some systems may not do autocompletion on words in the middle of titles, so starting a card with a datetime can hamper this functionality. One should check this against their particular system.

    1. The ID suffix was added because I use external tools to add notes to my vault so I needed a means to ensure there would never be a collision. For example, Alfred. If I accidentally typed the name of a note that already exists into it I didn’t want it to accidentally overwrite an existing note,

      Example of someone ("davecan") with a specific reason for using unique identifiers in the titles for their digital note taking.

  2. Nov 2021
    1. Challenges There was little success in attracting dues-based members. There was some interest in using the BRIDGE ID and its associated data as an open data resource, by not for pay. Beyond the original partners, we found few organizations and companies that wanted to use the BRIDGE ID for data interoperability to keep databases synchronized and current. It was hard to penetrate the market for unique organizational identifiers among established and well-funded vendors such as LEI, DUNNS, and a large number of country-based identification systems world-wide. The level of manual effort necessary to curate and deduplicate country-based organizational data internationally far exceed our funding expectations and challenged our sustainability.
  3. Sep 2021
  4. Aug 2021
    1. Th part of an URI after the # is called "fragment" and is by definition only available/processed on client side (see https://en.wikipedia.org/wiki/Fragment_identifier).
    2. The main problem is that the browser won't even send a request with a fragment part. The fragment part is resolved right there in the browser. So it's reachable through JavaScript.
  5. May 2021
    1. The simple problem that I see with fragment identifiers is that their existence and functionality relies completely on the developer rather than the browser. Yes, the browser needs to read and interpret the identifier and identify the matching fragment. But if the developer doesn’t include any id attributes in the HTML of the page, then there will be no identifiable fragments. Do you see why this is a problem? Whether the developer has coded identifiers into the HTML has nothing to do with whether or not the page actually has fragments. Virtually every web page has fragments. In fact, sectioning content as defined in the HTML5 spec implies as much. Every element on the page that can contain content can theoretically be categorized as a “fragment”.

      at the mercy of author

    2. This means that, regardless of what the developer has done behind the scenes in the HTML, all HTML fragments on that page should be identifiable by external referrers.
    1. There is a fundamental weakness in the name attribute, which the id attribute addresses: the name attribute is not required to be unique. This is OK for forms where you can have multiple elements with the same name, but unsuitable for the rest of the document where you are trying to uniquely identify an element.
    1. HTML fragment identifiers, as defined in the registration for the text/html media type [RFC2854] operate on id attributes and (now less frequently) the name attribute of the a, applet, frame, iframe, img and map elements.
  6. Apr 2020
  7. Dec 2019
    1. Available at: https://cioms.ch/wp-content/uploads/2017/01/WEB-CIOMS-EthicalGuidelines.pdf.

      This URL seems very unstable, so I archived the file at http://web.archive.org/web/20191223233751/https://cioms.ch/wp-content/uploads/2017/01/WEB-CIOMS-EthicalGuidelines.pdf .

      In general, it is good practice to provide not just links but also an archived version when citing a URL.

      Of course, it would be even better if policies themselves were FAIR (Findable, Accessible, Interoperable and Reusable), as discussed, for instance, in https://github.com/Daniel-Mietchen/events/blob/master/PIDapalooza-2018.md .

    2. OPP1151904

      Would be nice if that identifier would lead somewhere useful. A web search for it yielded https://doi.org/10.12688/wellcomeopenres.15442.1 , which is also included in the collection "GFBR: The ethics of data sharing and biobanking in health research" available via https://wellcomeopenresearch.org/collections/gfbr18 .

  8. Oct 2019
  9. Sep 2019
  10. May 2019