URNs

4 views
Skip to first unread message

Dominic König

unread,
Oct 21, 2010, 6:58:38 AM10/21/10
to PFIF
Ping---

Thank you for inviting to this discussion group.

One suggestion I had in mind (probably been discussed elsewhere
before):
Record IDs in PFIF currently use a general schema of <domain>/
<identifier>, and I wonder if it wouldn't be a good idea to move on to
URNs instead, in order to also support domain-independent universal
unique identifiers (namespace uuid:) as of RFC4122
http://www.ietf.org/mail-archive/web/ietf-announce/current/msg01385.html

Sahana-Eden uses UUID-URNs.

Best regards,
Dominic

Ka-Ping Yee

unread,
Oct 21, 2010, 12:42:12 PM10/21/10
to pf...@googlegroups.com
Hi Dominic,

Thanks for your suggestion.

Record IDs in PFIF currently use a general schema of <domain>/
<identifier>, and I wonder if it wouldn't be a good idea to move on to
URNs instead, in order to also support domain-independent universal
unique identifiers (namespace uuid:) as of RFC4122
http://www.ietf.org/mail-archive/web/ietf-announce/current/msg01385.html

UUIDs are a good identifier to use within a PFIF record ID.  However, it is pretty fundamental to PFIF that each record belongs to a home domain that can be determined from the record ID.  Would it serve your needs to use identifiers of the form <domain>/<uuid>?


—Ping

Dominic König

unread,
Oct 21, 2010, 5:38:32 PM10/21/10
to pf...@googlegroups.com

Sure, Eden can handle that schema, no problem at all.

I though wonder what the domain part of the identifier is useful for.

If it is meant as namespace, i.e. in order to avoid collisions between
different ID schemes of different services, then the namespace identifier of
URNs would serve the same purpose (while at the same time URNs are a more
general standard to identify resources on the web, and especially RFC4122 is
implemented in most of the frameworks and therefore easy to generate).

On the other hand, if the domain identifier is meant for verification
purposes, then I wonder how this would work - i.e. how would the domain
identifier be mapped back to the source of information?

Or was it meant to allow a domain service identify their own records, in order
to avoid duplication at import?

Can you clarify?

Thanks a lot,
best regards,
Dominic

signature.asc

Ka-Ping Yee

unread,
Oct 21, 2010, 8:10:02 PM10/21/10
to pf...@googlegroups.com
I though wonder what the domain part of the identifier is useful for.

The domain part prevents ID collisions between repositories (as you mentioned), and also identifies the authoritative owner of the record.  See the "Design Principles" and "Data Life Cycle" sections at http://zesty.ca/pfif/1.1/.  To federate data, we have to be able to identify which repository a record came from, and being able to do so directly from the ID makes many operations much simpler.


—Ping

Dominic König

unread,
Oct 22, 2010, 7:42:52 PM10/22/10
to pf...@googlegroups.com
Thank you for the clarifications.

Regards,
Dominic

signature.asc
Reply all
Reply to author
Forward
0 new messages