W3C home > Mailing lists > Public > www-tag@w3.org > August 2006

Re: A precedent suggesting a compromise for the SWHCLS IG Best Practices (ARK)

From: Paul Prescod <paul@prescod.net>
Date: Fri, 11 Aug 2006 15:13:14 -0700
Message-ID: <1cb725390608111513g128bd47bua3349e2d36a3c367@mail.gmail.com>
To: "Alan Ruttenberg" <alanruttenberg@gmail.com>
Cc: www-tag@w3.org
On 7/28/06, Alan Ruttenberg <alanruttenberg@gmail.com> wrote:
> In looking at ARK and comparing to LSID, I see the following issues:
> 1. We need some mechanism to globally assert that things like
> http://foobar.zaf.org/ark:/12025/654xz321
> http://sneezy.dopey.com/ark:/12025/654xz321
> ark:/12025/654xz321
> are all the same thing. From an OWL DL perspective this is a bit
> tricky because we need to use sameAs, equivalentClass, or
> equivalentProperty depending on what the URI is used for.
> Or, we adopt a convention that within SW documents we always make the
> URI be ark:/12025/654xz321 (well, perhaps we need an extra slash - or
> convince the standard to make the ark look like a urn) and always
> have a property(e.g. resolvesTo) associated with it that adds the
> naming authority so we can resolve it. Outside SW documents, such as
> in publications, we always use the full URL.

Recognition of something like ark syntax could be baked into future Web and
semantic web standards. The key idea seems to me to be the embedding of a
globally unique identifier inside of an "actionable" address. I think that
it would help people get past the mental block that makes them think that if
an identifier is actionable then it must exist primarily to invoke an
action. Ark says: "Yes, there is an actionable part and it exists primarily
for its action. And there is an identifier part. It exists primarily for
identifying." Ark requires the identifier part to be opaque which is
stricter than is necessary on the web in general. I think it might be useful
to have a syntax like this baked into the Web.

2. To address the concern that http isn't necessarily a good
> transport layer for complex data, we allow that providers may opt to
> provide the metadata and policy, but return a machine and person
> understandable message that redirects to use the metadata instead,
> which is specified to include the sort of access service information
> that lsid provides for.

 I'm curious what you mean by "complex data". At the protocol level, isn't
it all just an array of bits? What's an example of complex data that cannot
be encoded as bits and sent over a socket wrapped in HTTP headers?

 Paul Prescod
Received on Friday, 11 August 2006 22:13:28 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:32:49 UTC