"uid" microformats? (was Re: [uf-discuss] ISBN mark-up)

[Tantek Ç elik]

On 4/25/06 1:35 PM, "Scott Reynen" <scott at randomchaos.com> wrote:

> On Apr 25, 2006, Tantek Çelik wrote:
> 
>> We *want*
>> resources that can be identified by network location and thus a
>> system that
>> shows a bias *for* that is a *good* thing.
> 
> Is the proposal that UIDs SHOULD be URLs or UIDs MUST be URLs?

SHOULD.

> If  
> it's MUST, that would seem to discourage use of microformats to
> markup content that doesn't exist at a canonical URL.

Agreed, MUST is problematic there.


>>> many well-established identifiers are not based on URL. e.g. In a
>>> typical library application, we really want to identify the books in
>>> Amazon and local catalog are referencing same thing,
>> 
>> Ah, you just introduced a new requirement, and perhaps that is
>> where the disconnect is.
> 
> I assumed the same use case.  This is all I've ever seen UIDs used
> for.  What is the other use case?

Two different problems here:

1. Uniqueness of UID. How to make sure two events don't use the same UID -
uniqueness - that's the point of UID.

2. Reuse of UID. How to make sure two instances of the same event use the
same UID - that's the scenario you outlined (identify the books in Amazon
and local catalog are referencing the same thing), and that's the one
implementations can solve without asserting requirements on the format.



>> The requirement that we are looking at is: globally unique, that
>> is, two
>> *different* events/contacts don't end up using the same UID.
>> That's it.
> 
> Couldn't we more simply give each event an ID attribute and
> accomplish that?

That's *one* possible way a publisher might choose to deal with it.  No need
to prescribe that.




>> URLs are by design global.  The opposite of your
>> concern is actually true: URLs will tend to make UID *more* globally
>> identifiable.
> 
> URLs are inherently globally unique, but URLs are only globally
> identifiable if people use them like that, and I doubt people will.

Seeing blogs and posts, and post permalinks emerge and be broadly supported
over the past 5 years, I find that doubt not only unsupported, but contrary
to where things are naturally heading.


>>> When Eventful is adding an event already found on Upcoming, I
>>> would expect Eventful to be more likely to assign a UID of
>>> 123872138623 than http://upcoming.org/event/123872138623/
>> 
>> In speaking with both the Upcoming developers and the Eventful
>> developers
>> this is not the case.
>> 
>> It is *much* easier and more natural to publish and convey a notion
>> of a
>> "permalink" for an event or venue, and then mark that up as its
>> UID, than to
>> expose random gibberish UIDs to the user (whether numbers or some
>> other
>> opaque sequence).
> 
> Right, but one involves pointing to a competitor and the other
> doesn't, and I think that difference has a real-world effect on
> people's behavior.

Not at all, they can both point to their own domains with their UIDs.
Others could point to both, using either UID.


>>> Both Upcoming and Eventful have event IDs that are part of event
>>> URLs, but don't associate the events with a particular domain.  The
>>> domain association ensures the IDs are unique, but it seems to do so
>>> at the expense of identifying multiple copies of the same event,
>> 
>> Not a requirement.  Identifying multiple copies of the same event
>> can easily
>> be done by implementations.  E.g. event aggregators can keep track
>> of *all*
>> the URLs that an event has when it is found across different sources.
> 
> RFC 2445 says UID "MUST NOT occur more than once."  Are we changing
> this in hcalendar?

Right the UID must not occur more than once.  That's the "uniqueness"
problem that is all I'm saying we are doing with UID.

Your point about "identifying multiple copies of the same event" is the
"reuse" problem (see above), and that's the one we don't need to solve in
the format.

Thanks,

Tantek