W3C home > Mailing lists > Public > public-semweb-lifesci@w3.org > February 2007

RE: RE: [BioRDF] URI Resolution

From: Booth, David (HP Software - Boston) <dbooth@hp.com>
Date: Fri, 9 Feb 2007 10:08:29 -0500
Message-ID: <EBBD956B8A9002479B0C9CE9FE14A6C2020B6AA2@tayexc19.americas.cpqcorp.net>
To: <samwald@gmx.at>
Cc: <public-semweb-lifesci@w3.org>

> From: samwald@gmx.at
> >> In your view, how would one find
> >> information (or represent the information needed to find
> >> information) about a non-informationresource 
> I think parallel querying of Sparql endpoints could be an 
> interesting solution. . . . .

I'm curious why you are treating this case so differently from the case
of finding information about an information resource.  I assume it is
because with information resources you are only interested in
information from that information resource and not from third parties.
Is that correct?

> > I'm not sure what you are asking. [...] you
> > should be able to follow-your-nose by deferencing the namespace.
> This would probably only lead to the information that was 
> available when the URI for the gene was minted. The more 
> interesting information will probably be found elsewhere, 
> e.g. in an interactome database that describes interactions 
> of the gene that was previously described in the genome 
> database. How should these be found with the follow-your-nose 
> approach when there are no 'trackback' relations in the 
> genome database?

Ah!  Thanks for the clarification.  That is a very different use case
than the case where resources have simply moved or you wish to use a
different protocol than HTTP for retrieving resources.  I suggest we
distinguish between two kinds of information about resources:

 - Primary Authoritative Information: information that is provided by
the resource owner.  In this case, the big issue is how to establish and
maintain efficient ways to retrieve such information while supprting the
WebArch follow-your-nose principle of having a clear, deterministic
chain of authority from the URI to the information.  Incidentally, when
we speak of a resource having "moved" we mean that primary authoritive
information now resides at a different location from the one originally
associated with the URI.

 - Third Party Information: information that is provided by parties
other than the resource owner or the information requestor.  In this
case the issues seem to me to be trust (how do you decide which
information to trust?) and the lack of a deterministic way to find such
information (it could be anywhere).

I think the problems involved in these two cases are very different and
a solution that addresses the problem of retrieving Primary
Authoritative Information is much simpler than the problem of finding
and deciding to trust Third Party Information.    Of course, once Third
Party Information is found, and there is a decision to use it, then the
problem becomes the same as that for retrieving Primary Authoritative

I had previously thought that the proposed effort was only intended to
address the problem of retrieving Primary Authoritative Information.
Are you proposing that it should address both of these problems?  If so,
then I think the part that addresses only the need to retrieve Primary
Authoritative Information should be cleanly separable from the rest, so
that its implementation does not require all of the machinery needed for
addressing the (much larger) Third Party Information problem.  Are there
reasons why you think these problems should not be separated?  

David Booth
Received on Friday, 9 February 2007 15:08:40 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:52:29 UTC