Re: [O] Properties ID vs. CUSTOM_ID

[Christophe Schockaert]

Eric Abrahamsen writes:

> Carsten Dominik  writes:
>
>> Dear all,
>>
>> before continuing this discussion, and before reinventing, you might
>> want to take a look at how org-id.el currently does create unique IDs.
>> [...]
>> Hope this helps.
>
> Right, and we're not trying to reinvent any wheels, just get a
> user-readable string in there while still retaining uniqueness. Ie, it
> would probably be enough if org-id-prefix could be set to 'entry, and
> org then generated a prefix by munging the entry text:
>
> * My Great Header
>   :PROPERITIES:
>   :ID: my-great-header-44d1-b804-d11657131237
>   :END:
Sounds good to me.


I still like the idea to be able to use a plain date, but when I need
it, I would most than probably set it as an inactive timestamp in the
entry title in my case. It would thus be addressed if the "munging"
would also handle cleverly the timestamp in an entry title (which it
should do anyway I think).

So, from my perspective, this approach fully fulfill the needs in an
efficient way.


Christophe

-- 
--->  mailto:r3vli...@citadels.eu
Once it's perfectly aimed, the flying arrow goes straight to its target.
Thus, don't worry when things go right.
There will be enough time to worry about if they go wrong.
Then, it's time to fire a new arrow towards another direction.
Don't sink.  Adapt yourself !  The archer has to shoot accurately and quickly.
[Words of Erenthar, the bowman ranger] <---

Re: [O] Properties ID vs. CUSTOM_ID

[Eric Abrahamsen]

Carsten Dominik  writes:

> Dear all,
>
> before continuing this discussion, and before reinventing, you might
> want to take a look at how org-id.el currently does create unique IDs.
>  In particular, take a look at these variables:
>
> org-id-prefix
> org-id-method
> org-id-include-domain
>
> In particular, the docstring of the variable org-id-method is
>
>   "The method that should be used to create new IDs.
>
> An ID will consist of the optional prefix specified in
> `org-id-prefix',
> and a unique part created by the method this variable specifies.
>
> Allowed values are:
>
> orgOrg's own internal method, using an encoding of the current
> time to
>microsecond accuracy, and optionally the current domain of
> the
>computer.  See the variable `org-id-include-domain'.
>
> uuid   Create random (version 4) UUIDs.  If the program defined in
>`org-id-uuid-program' is available it is used to create the
> ID.
>Otherwise an internal functions is used."
>
> Hope this helps.

Right, and we're not trying to reinvent any wheels, just get a
user-readable string in there while still retaining uniqueness. Ie, it
would probably be enough if org-id-prefix could be set to 'entry, and
org then generated a prefix by munging the entry text:

* My Great Header
  :PROPERITIES:
  :ID: my-great-header-44d1-b804-d11657131237
  :END:

Re: [O] Properties ID vs. CUSTOM_ID

[Carsten Dominik]

And one more remark.

A main reason for the CUSTOM_ID (and my only use of it, really) it to make
HTML targets stable and meaningful.  In the following file


* 
* 
  :PROPERTIES:
  :CUSTOM_ID: Lotsofbshere
  :END:

you can have a stable link

to file.html#Lotsofbshere

Carsten

On Thu, Dec 22, 2016 at 10:31 PM, Carsten Dominik  wrote:

> Dear all,
>
> before continuing this discussion, and before reinventing, you might want
> to take a look at how org-id.el currently does create unique IDs.  In
> particular, take a look at these variables:
>
> org-id-prefix
> org-id-method
> org-id-include-domain
>
> In particular, the docstring of the variable org-id-method is
>
>   "The method that should be used to create new IDs.
>
> An ID will consist of the optional prefix specified in `org-id-prefix',
> and a unique part created by the method this variable specifies.
>
> Allowed values are:
>
> orgOrg's own internal method, using an encoding of the current
> time to
>microsecond accuracy, and optionally the current domain of the
>computer.  See the variable `org-id-include-domain'.
>
> uuid   Create random (version 4) UUIDs.  If the program defined in
>`org-id-uuid-program' is available it is used to create the ID.
>Otherwise an internal functions is used."
>
>
>
> Hope this helps.
>
> Carsten
>
>
> On Thu, Dec 22, 2016 at 10:02 PM, Eric Abrahamsen  > wrote:
>
>> Christophe Schockaert  writes:
>>
>> > Eric Abrahamsen writes:
>> >
>> >> Karl Voit  writes:
>> >>
>> >>> I'd prefer using manually written :ID: instead since migration would
>> >>> not be trivial to me.
>> >>
>> >> You could also use the `org-property-set-functions-alist' trick with
>> the
>> >> :ID: property. If you added an "ID" entry to that alist, Org's usual
>> >> automatic id creation would be unaffected, but if you set ID manually,
>> >> you could write a function that would first prompt for your
>> >> human-readable string, then check for ID uniqueness and append random
>> >> characters to your string until it was unique. I think that would be a
>> >> nice addition to org-id.el.
>> >>
>> >> Eric
>> > I thikn the tricky part would be that we can only ensure ID uniqueness
>> > for the current agenda at the time of the ID creation. What if we later
>> > merge another set of files where ID were created independantly to our
>> > acustomed agenda files ?
>> >
>> > I like the idea of assigning a date since we would reduce chances to
>> > define at the same time the same string and the same day. If meticulous,
>> > we could assign a date and a time or random string as you suggest, Eric
>> > (a tiny UUID :).
>> >
>> > I think I read somewhere the first inactive timestamp could be used to
>> > tag an entry with a date. At least, I do that frequently.
>> >
>> > Thus, if available, we could even use it as a date when creating the ID
>> > in order to have an indication of the creation time for the heading
>> > instead of creation time of the link.
>> >
>> > Here it is for my suggestions.
>> >
>> > Dates might not be appropriate for every situation, though...
>>
>> I think including some sort of timestamp in the id would likely solve
>> the problem of future conflicts. I don't think adding the actual date
>> into the ID string would be that useful (how often would you be
>> comparing dates from the ID property?), but the human-readable string
>> could have a hash of the string plus (current-time) appended to it. Or,
>> perhaps better, a hash of the outline path plus current-time.
>>
>> E
>>
>>
>>
>

Re: [O] Properties ID vs. CUSTOM_ID

[Carsten Dominik]

Dear all,

before continuing this discussion, and before reinventing, you might want
to take a look at how org-id.el currently does create unique IDs.  In
particular, take a look at these variables:

org-id-prefix
org-id-method
org-id-include-domain

In particular, the docstring of the variable org-id-method is

  "The method that should be used to create new IDs.

An ID will consist of the optional prefix specified in `org-id-prefix',
and a unique part created by the method this variable specifies.

Allowed values are:

orgOrg's own internal method, using an encoding of the current time
to
   microsecond accuracy, and optionally the current domain of the
   computer.  See the variable `org-id-include-domain'.

uuid   Create random (version 4) UUIDs.  If the program defined in
   `org-id-uuid-program' is available it is used to create the ID.
   Otherwise an internal functions is used."



Hope this helps.

Carsten


On Thu, Dec 22, 2016 at 10:02 PM, Eric Abrahamsen 
wrote:

> Christophe Schockaert  writes:
>
> > Eric Abrahamsen writes:
> >
> >> Karl Voit  writes:
> >>
> >>> I'd prefer using manually written :ID: instead since migration would
> >>> not be trivial to me.
> >>
> >> You could also use the `org-property-set-functions-alist' trick with
> the
> >> :ID: property. If you added an "ID" entry to that alist, Org's usual
> >> automatic id creation would be unaffected, but if you set ID manually,
> >> you could write a function that would first prompt for your
> >> human-readable string, then check for ID uniqueness and append random
> >> characters to your string until it was unique. I think that would be a
> >> nice addition to org-id.el.
> >>
> >> Eric
> > I thikn the tricky part would be that we can only ensure ID uniqueness
> > for the current agenda at the time of the ID creation. What if we later
> > merge another set of files where ID were created independantly to our
> > acustomed agenda files ?
> >
> > I like the idea of assigning a date since we would reduce chances to
> > define at the same time the same string and the same day. If meticulous,
> > we could assign a date and a time or random string as you suggest, Eric
> > (a tiny UUID :).
> >
> > I think I read somewhere the first inactive timestamp could be used to
> > tag an entry with a date. At least, I do that frequently.
> >
> > Thus, if available, we could even use it as a date when creating the ID
> > in order to have an indication of the creation time for the heading
> > instead of creation time of the link.
> >
> > Here it is for my suggestions.
> >
> > Dates might not be appropriate for every situation, though...
>
> I think including some sort of timestamp in the id would likely solve
> the problem of future conflicts. I don't think adding the actual date
> into the ID string would be that useful (how often would you be
> comparing dates from the ID property?), but the human-readable string
> could have a hash of the string plus (current-time) appended to it. Or,
> perhaps better, a hash of the outline path plus current-time.
>
> E
>
>
>

Re: [O] Properties ID vs. CUSTOM_ID

[Eric Abrahamsen]

Christophe Schockaert  writes:

> Eric Abrahamsen writes:
>
>> Karl Voit  writes:
>>
>>> I'd prefer using manually written :ID: instead since migration would
>>> not be trivial to me.
>>
>> You could also use the `org-property-set-functions-alist' trick with the
>> :ID: property. If you added an "ID" entry to that alist, Org's usual
>> automatic id creation would be unaffected, but if you set ID manually,
>> you could write a function that would first prompt for your
>> human-readable string, then check for ID uniqueness and append random
>> characters to your string until it was unique. I think that would be a
>> nice addition to org-id.el.
>>
>> Eric
> I thikn the tricky part would be that we can only ensure ID uniqueness
> for the current agenda at the time of the ID creation. What if we later
> merge another set of files where ID were created independantly to our
> acustomed agenda files ?
>
> I like the idea of assigning a date since we would reduce chances to
> define at the same time the same string and the same day. If meticulous,
> we could assign a date and a time or random string as you suggest, Eric
> (a tiny UUID :).
>
> I think I read somewhere the first inactive timestamp could be used to
> tag an entry with a date. At least, I do that frequently.
>
> Thus, if available, we could even use it as a date when creating the ID
> in order to have an indication of the creation time for the heading
> instead of creation time of the link.
>
> Here it is for my suggestions.
>
> Dates might not be appropriate for every situation, though...

I think including some sort of timestamp in the id would likely solve
the problem of future conflicts. I don't think adding the actual date
into the ID string would be that useful (how often would you be
comparing dates from the ID property?), but the human-readable string
could have a hash of the string plus (current-time) appended to it. Or,
perhaps better, a hash of the outline path plus current-time.

E

Re: [O] Properties ID vs. CUSTOM_ID

[Christophe Schockaert]

Eric Abrahamsen writes:

> Karl Voit  writes:
>
>> I'd prefer using manually written :ID: instead since migration would
>> not be trivial to me.
>
> You could also use the `org-property-set-functions-alist' trick with the
> :ID: property. If you added an "ID" entry to that alist, Org's usual
> automatic id creation would be unaffected, but if you set ID manually,
> you could write a function that would first prompt for your
> human-readable string, then check for ID uniqueness and append random
> characters to your string until it was unique. I think that would be a
> nice addition to org-id.el.
>
> Eric
I thikn the tricky part would be that we can only ensure ID uniqueness
for the current agenda at the time of the ID creation. What if we later
merge another set of files where ID were created independantly to our
acustomed agenda files ?

I like the idea of assigning a date since we would reduce chances to
define at the same time the same string and the same day. If meticulous,
we could assign a date and a time or random string as you suggest, Eric
(a tiny UUID :).

I think I read somewhere the first inactive timestamp could be used to
tag an entry with a date. At least, I do that frequently.

Thus, if available, we could even use it as a date when creating the ID
in order to have an indication of the creation time for the heading
instead of creation time of the link.

Here it is for my suggestions.

Dates might not be appropriate for every situation, though...


Christophe
-- 
--->  mailto:r3vli...@citadels.eu
Once it's perfectly aimed, the flying arrow goes straight to its target.
Thus, don't worry when things go right.
There will be enough time to worry about if they go wrong.
Then, it's time to fire a new arrow towards another direction.
Don't sink.  Adapt yourself !  The archer has to shoot accurately and quickly.
[Words of Erenthar, the bowman ranger] <---

Re: [O] Properties ID vs. CUSTOM_ID

[Christophe Schockaert]

John Kitchin writes:
> On Thu, Dec 22, 2016 at 10:30 AM, Karl Voit  wrote:
>
>> * John Kitchin  wrote:
>> >
>> > There is not an issue using a human-readable id in :ID: as long as it is
>> > unique. It will store fine, link fine, etc...
>>
>> I also think so because I am only using human-readable :ID: without
>> any issue so far.
>>
>> However, the argument was that no human should set :ID: but use
>> :CUSTOM_ID: *instead*. See also the old thread I linked before.
>>
> That is just be a convention though, and as long as the IDs are unique, it
> does not matter who sets them.
>
> John
That's how I ended up understanding their use.

When I read the manual (http://orgmode.org/manual/Handling-links.html),
it's actually possible to define both IDs for the same entry:

:  So using this command (added: org-store-link) in Org buffers will
:  potentially create two links: a human-readable from the custom ID, and
:  one that is globally unique and works even if the entry is moved from
:  file to file. Later, when inserting the link, you need to decide which
:  one to use.

Indeed, if both IDs are available, when inserting the link, we can
choose which ID will be used as target.

Also, we should note that the scope for CUSTOM_ID is the current file
only. That's what prevented me to migrate human readable IDs to
CUSTOM_IDs, and led me to consider the choice between the two as a
convention.

And I guess, that you would need ID available between different files
too, Karl, as you expect org-depend to be usable accross different files
:o)

Christophe

-- 
--->  mailto:r3vli...@citadels.eu
Once it's perfectly aimed, the flying arrow goes straight to its target.
Thus, don't worry when things go right.
There will be enough time to worry about if they go wrong.
Then, it's time to fire a new arrow towards another direction.
Don't sink.  Adapt yourself !  The archer has to shoot accurately and quickly.
[Words of Erenthar, the bowman ranger] <---

Re: [O] Properties ID vs. CUSTOM_ID

[Samuel Wales]

an example of a custom id feature might be for export.  sounds like
you might not need it.

Re: [O] Properties ID vs. CUSTOM_ID

[Samuel Wales]

On 12/22/16, Karl Voit  wrote:
> However, the argument was that no human should set :ID: but use
> :CUSTOM_ID: *instead*. See also the old thread I linked before.

i don't recall anybody arguing, claiming, or implying specifically that.

if you're careful, and do not need custom id features, then you're
probably ok ignoring custom id.  sounds like you want reassurance that
you're ok?

Re: [O] Properties ID vs. CUSTOM_ID

[Eric Abrahamsen]

Karl Voit  writes:

> * John Kitchin  wrote:
>>
>> There is not an issue using a human-readable id in :ID: as long as it is
>> unique. It will store fine, link fine, etc...
>
> I also think so because I am only using human-readable :ID: without
> any issue so far.
>
> However, the argument was that no human should set :ID: but use
> :CUSTOM_ID: *instead*. See also the old thread I linked before.
>
> I'd prefer using manually written :ID: instead since migration would
> not be trivial to me.

You could also use the `org-property-set-functions-alist' trick with the
:ID: property. If you added an "ID" entry to that alist, Org's usual
automatic id creation would be unaffected, but if you set ID manually,
you could write a function that would first prompt for your
human-readable string, then check for ID uniqueness and append random
characters to your string until it was unique. I think that would be a
nice addition to org-id.el.

Eric

Re: [O] Properties ID vs. CUSTOM_ID

[John Kitchin]

That is just be a convention though, and as long as the IDs are unique, it
does not matter who sets them.

John

---
Professor John Kitchin
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
http://kitchingroup.cheme.cmu.edu


On Thu, Dec 22, 2016 at 10:30 AM, Karl Voit  wrote:

> * John Kitchin  wrote:
> >
> > There is not an issue using a human-readable id in :ID: as long as it is
> > unique. It will store fine, link fine, etc...
>
> I also think so because I am only using human-readable :ID: without
> any issue so far.
>
> However, the argument was that no human should set :ID: but use
> :CUSTOM_ID: *instead*. See also the old thread I linked before.
>
> I'd prefer using manually written :ID: instead since migration would
> not be trivial to me.
>
> --
> mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML to Org-mode:
>> get Memacs from https://github.com/novoid/Memacs <
>
> https://github.com/novoid/extract_pdf_annotations_to_orgmode + more on
> github
>
>
>

Re: [O] Properties ID vs. CUSTOM_ID

[Karl Voit]

* John Kitchin  wrote:
>
> There is not an issue using a human-readable id in :ID: as long as it is
> unique. It will store fine, link fine, etc...

I also think so because I am only using human-readable :ID: without
any issue so far.

However, the argument was that no human should set :ID: but use
:CUSTOM_ID: *instead*. See also the old thread I linked before.

I'd prefer using manually written :ID: instead since migration would
not be trivial to me.

-- 
mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML to Org-mode:
   > get Memacs from https://github.com/novoid/Memacs <

https://github.com/novoid/extract_pdf_annotations_to_orgmode + more on github

Re: [O] Properties ID vs. CUSTOM_ID (was: Automatically Generating IDs From Title and Date)

[John Kitchin]

There is not an issue using a human-readable id in :ID: as long as it is
unique. It will store fine, link fine, etc...

John

---
Professor John Kitchin
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
http://kitchingroup.cheme.cmu.edu


On Thu, Dec 22, 2016 at 5:03 AM, Karl Voit  wrote:

> * Karl Voit  wrote:
> > * Samuel Wales  wrote:
> >> On 12/18/16, Karl Voit  wrote:
> >>>   Usually, my IDs start with the current ISO day to enforce uniqueness
> >>>   and look like this:
> >>
> >> my understanding, which might be incorrect, is that custom id is for
> >> human-readable purposes, while id is for uuid.  although you could
> >> prepend to uuid.
> >
> > To me, using :ID: was straight forward since I never read about any
> > other ID when I began with Org-mode in 2011.
>
> Another argument:
>
> According to
> http://orgmode.org/worg/org-contrib/org-depend.html
> I have to use :ID: properties and not :CUSTOM_ID: properties.
>
> ,[ task with dependency to a generated ID ]
> | ** TODO a task
> | :PROPERTIES:
> | :BLOCKER: 6347hsfdl387ns43
> | :ID:
> `
>
> ... in comparison to:
>
> ,[ task with dependency to a manually written ID ]
> | ** TODO a task
> | :PROPERTIES:
> | :BLOCKER: contacting-customer-XY
> | :ID:
> `
>
> I prefer the example with the manually written ID since it is human
> readable.
>
> --
> mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML to Org-mode:
>> get Memacs from https://github.com/novoid/Memacs <
>
> https://github.com/novoid/extract_pdf_annotations_to_orgmode + more on
> github
>
>
>

Re: [O] Properties ID vs. CUSTOM_ID (was: Automatically Generating IDs From Title and Date)

[Karl Voit]

* Karl Voit  wrote:
> * Samuel Wales  wrote:
>> On 12/18/16, Karl Voit  wrote:
>>>   Usually, my IDs start with the current ISO day to enforce uniqueness
>>>   and look like this:
>>
>> my understanding, which might be incorrect, is that custom id is for
>> human-readable purposes, while id is for uuid.  although you could
>> prepend to uuid.
>
> To me, using :ID: was straight forward since I never read about any
> other ID when I began with Org-mode in 2011.

Another argument:

According to 
http://orgmode.org/worg/org-contrib/org-depend.html
I have to use :ID: properties and not :CUSTOM_ID: properties.

,[ task with dependency to a generated ID ]
| ** TODO a task
| :PROPERTIES:
| :BLOCKER: 6347hsfdl387ns43
| :ID:
`

... in comparison to:

,[ task with dependency to a manually written ID ]
| ** TODO a task
| :PROPERTIES:
| :BLOCKER: contacting-customer-XY
| :ID:
`

I prefer the example with the manually written ID since it is human
readable.

-- 
mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML to Org-mode:
   > get Memacs from https://github.com/novoid/Memacs <

https://github.com/novoid/extract_pdf_annotations_to_orgmode + more on github