[DAS] Re: Our identifier doc and proposal
Brian King
kingb@doubletwist.com
Tue, 27 Nov 2001 19:44:46 -0800
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------_=_NextPart_001_01C177BF.05BAED80
Content-Type: text/plain;
charset="iso-8859-1"
> urn:lsid:informatics.mpi.com:plate/glycerol/freeze:12345
>
> I think the top level namespace, e.g. "plate" should be hard-and-fast
> data types. Is this envisioned by the I3C?
>
> Lincoln
Lincoln,
I'm one of the authors of the I3C ID proposal. We've just started
discussing the ontology-in-ID issue, so take my answer as only my own point
of view. I believe we should not encode information such as object type in
the I3C IDs. An ID should just be a unique string, and nothing more. Since
ID creation is decentralized in the I3C interoperability architecture we
need to encode an authority and namespace to ensure uniqueness, but that's
the only purpose of that information. The problem with having information
encoded into IDs is that developers immediately start parsing this
information to speed queries or map data to physical locations, or worse,
create their IDs based on such assumptions. Such schemes are unreliable and
unstable. They're unreliable because different paths in the ID imply
different processing, and since IDs are passed everywhere, the logic for
this processing gets scattered all across the system. They are unstable
because the information that seemed relevant in the last system becomes
obsolete. I have been a software contractor on several projects, and often
the first task on entering a project is untangling the IDs. We should avoid
turning the ID into a query language in itself.
Regards,
Brian King
DoubleTwist, Inc
------_=_NextPart_001_01C177BF.05BAED80
Content-Type: text/html;
charset="iso-8859-1"
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META content="MSHTML 5.00.2314.1000" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT face=Arial size=2><BR> >
urn:lsid:informatics.mpi.com:plate/glycerol/freeze:12345<BR>> <BR> >
I think the top level namespace, e.g. "plate" should be hard-and-fast<BR>>
data types. Is this envisioned by the I3C?<BR>> <BR> >
Lincoln<BR></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN
class=080191403-28112001>Lincoln,</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN
class=080191403-28112001></SPAN></FONT> </DIV>
<DIV><SPAN class=080191403-28112001><FONT face=Arial size=2>I'm one of the
authors of the I3C ID proposal. We've just started discussing the
ontology-in-ID issue, so take my answer as only my own point of view.
I believe we should not encode information such as object type in the I3C
IDs. An ID should just be a unique string, and nothing more.
Since ID creation is decentralized in the I3C interoperability
architecture we need to encode an authority and namespace to ensure
uniqueness, but that's the only purpose of that information. The problem
with having information encoded into IDs is that developers immediately
start parsing this information to speed queries or map data to physical
locations, or worse, create their IDs based on such assumptions. Such
schemes are unreliable and unstable. They're unreliable because different
paths in the ID imply different processing, and since IDs are passed
everywhere, the logic for this processing gets scattered all across the
system. They are unstable because the information that seemed
relevant in the last system becomes obsolete. I have been a software
contractor on several projects, and often the first task on entering a project
is untangling the IDs. We should avoid turning the ID into a query
language in itself.</FONT></SPAN></DIV>
<DIV><SPAN class=080191403-28112001><FONT face=Arial
size=2></FONT></SPAN> </DIV>
<DIV><FONT face=Arial size=2><SPAN
class=080191403-28112001>Regards,</SPAN></FONT></DIV>
<DIV><SPAN class=080191403-28112001><FONT face=Arial size=2>
<DIV><FONT face=Arial size=2>Brian King</FONT></DIV>
<DIV><FONT face=Arial size=2>DoubleTwist,
Inc</FONT></FONT></SPAN></DIV></DIV></BODY></HTML>
------_=_NextPart_001_01C177BF.05BAED80--