- What are the functional/operational differences between the following attributes: URL, SourceURL, ReferenceURL?
- How does one manage the visible attributes table for a note when there are, say, three different URL referenced sources?
The are described here: URL, SourceURL, ReferenceURL.
But if you want to use 3 URL-type attributes per note, why not simply add two (or 3 URL-type user attributes? Need more per note, add mote attributes.
To control what you see in the selected note Displayed Attributes see here (and linked notes).
Thanks Mark. Life would, no doubt, be easier if I did not ignore the bleeding obvious.
2 Likes
No worries. Many things are only obvious after the fact.
I might add that while $URL is a general attribute you can use for any URL, the other two URL attributes mentioned have specific purposes and ideally should not be re-purposed for a different task.
The ReferenceURL definition is a bit anemic.
Well, there’s not much to say! It maps the the RIS ‘UR’ code.
The rise in popularity of app ‘pseudo-protocols’ (i.e. url that open a data from within a local app) mean the ‘references’ imported from such apps can have two URLs: the pseudo-protocol URL of the item in the linked app, and the source URL of the object (paper, book, etc.) described in that item. It seems there has been some looseness in the past over what maps to what (and in the context of what external manager app). I do see an open issue (Backstage) to try and resolve this for v9.0.
As some users have taken it upon themselves to make arbitrary use of some system attributes, some tidy-up may be required, e.g. shifting existing values to a different system or user attribute to align with new usage.
Also as from v8.9.1:
The built-in Reference prototype now includes $URL as a displayed attribute as well as $ReferenceURL. $URL holds a the URL to the references in the reference manager, $ReferenceURL holds the URL of the source if it has one.
That is consistent with the current aTbRef documentation. I’ll look into perhaps adding a link from the $ReferenceURL note to the article on the Reference prototype.
For example, I always create $LinkedInURL for my new files and add it to the Person $Prototype. This way I can easily click through to a user’s LinkedIn account.
The moral of the story, don’t be afraid to create user-generated attributes. You can always delete them if you find you don’t need them, use actions to merge them with others, update their contents, rename them, etc. In fact, @Bernard-0 and I on one call, and @mwra on another, yesterday discussed the power of meta-cognition (e.g. thinking through the lens of attributes). Once you realize that the $Name and $Text of a note, for instance, are just attributes too you realize that everything is made up of attributes, that an individual note, like a person, is nothing more than a unique assembly of attributes. You can then use this insight to unleash the power of tinderbox for collection, curation, creation, and contribution. Our use of prototypes can be used to group associated notes (i.e. notes with the same $Prototype attributes), but with inheritance properties, notes can even (thankfully) diverge as they evolve from their genilogical source. Anyway, more on the philosophy of meta-cognation later.
2 Likes