Re: RDF for molecules, using InChI

Summary: Recapping some issues for Chimezie  - may not be of interest  
to those who have been following the discussion already.
Bottom line: If you are interested in URI issues, please talk to  
Jonathan Rees who is responsible for editing the recommendations  
documents that we (HCLS) have agreed to produce. (he tries to keep up  
with the list, but doesn't always manage to)

On Aug 6, 2007, at 9:08 AM, Chimezie Ogbuji wrote:

> On Sun, 2007-08-05 at 01:25 -0400, Alan Ruttenberg wrote:
>> I don't think it is likely that the HCLS recommendations will suggest
>> using INFO uri's.
>
> Is the 'recommendation' of a particular URI scheme over others on  
> the agenda? I would hope not.  I've yet to understand the  
> motivation for considering the use of a particular URI scheme over  
> another as a 'best practice' (the most common such suggestion being  
> HTTP).

First, I should correct an error that Jonathan pointed out to me -  
that an info: scheme URI is not a URN. I don't think that changes the  
message though.

Second, the view offered was my own and was perhaps too strongly  
stated. But I made it because I saw that recommendations were being  
made about decisions related to URIs and because I felt that given  
that we have an ongoing activity to work together to come up with  
some recommendations, that although we haven't come to a decision  
about exactly what the recommendations will say, it certainly is the  
case that URI schemes have been part of the discussion. I felt Egon  
needed to know about this - I don't know how long he has been  
following the list.

I'm quite happy that, as a result of that, you've chimed in,  
Chimezie. I'd say that the starting point for the recommendations  
will be a set of principles that we agree are important for our  
domain (they may be important for other domains, but our scope is  
deliberately the hcls community). It may or may not turn out that as  
a consequence of these principles we may recommend that certain  
schemes not be used, and recommend that others better serve those  
principles. Please connect with Jonathan to make sure that he has a  
good idea of what you think is important so that the recommendations  
can reflect your views.

> Note that the recent TAG finding [1] in this regard made a  
> (guarded) argument for how HTTP schemes can facilitate location  
> independence, persistence, etc..  This should not be confused for a  
> recommendation *for* HTTP as the a preferred URI scheme.  I would  
> consider such recommendations as dangerous and perhaps a  
> misunderstanding of AWWW and the URI mechanism: the fact that the  
> URI syntax allows for the use of arbitrary URI schemes is a feature  
> not a bug.

It would be surprising if we misunderstand the AWWW. We've said  
before that we think it doesn't do well on a number of issues. That  
the possibility that there be other URI schemes, I consider a  
feature. However we are talking about a specific use - HCLS/Semantic  
Web, and I don't conclude from anything that I've seen that this  
makes it obligatory that we are neutral wrt/ schemes. We want to find  
something that works well for this community.

>> They haven't been championed by anyone, urn schemes  are generally  
>> discouraged by the W3C TAG,
>
> Where exactly?

I can't find you references right now, as I'm on a plane, but I'll  
try to get to get some for you. Certainly in discussions I've had  
with them they  have discouraged the use of new URN schemes for the  
reason I mentioned.

>
>> and in our discussions  thus far haven't seen any advantages to  
>> using them while noting difficulties.
>
> I don't think URI schemes were meant to be thought of that way (as  
> mutually exclusive)

Perhaps URI schemes in general were not, but we aren't talking about  
URI schemes in general.

>> Too many URN schemes lead to difficulties on the part  of clients,
>
> Not true, especially if the intent of a particular scheme has more  
> to do with identity management than network resolution (LSIDs are  
> still useful even without a resolution mechanism, mostly because it  
> has a very precise identification scheme - non-collidable UUIDs,  
> etc.).

If you consider LSIDs without resolution then I don't think they have  
any value over any other URI scheme. They are simply strings and any  
old scheme will do. As an aside, I don't know what you mean about  
them having a precise identification scheme (any more so than any  
URI) or what you mean by "non-collidable UUIDs". Could you say a bit  
more?

> Consider that you can perform inference over an RDF graph which  
> consists of a merge of *both* ABox assertions (and other instance- 
> level data) and TBox assertions (ontology assertions) without the  
> need of a resolution mechanism.  Being able to build such a merged  
> graph "on-the-fly" (i.e., "Follow-your-nose") makes such an RDF  
> Graph Hypertext-Web friendly but this is not a necessary criteria.

I think follow-your-nose is unworkable for the sort of work we mostly  
do, but because of the rest of web usage, we have thus far considered  
it a goal to enable the sort of discovery that it commonly expected.  
Personally, I consider it a matter of courtesy to give people a way  
to find out more.

If one is only interested in doing local computation with RDF/OWL,  
then the URI scheme doesn't matter - the reasoners don't typically  
dereference anything. But we have been assuming that the usage we are  
targeting is sharing names of resources and facts about those  
resources with a wider community. For this purpose more is required.

> The HTTP scheme (as I understand it) is made for the Hypertext-Web,

That is a misunderstanding. The HTTP scheme is explicitly (e.g.  
httpRange-14) being recommended for purposes other than for hypertext  
- range-14 talks about the fact that some things identified by HTTP  
URIs are not information resources.

> not every information space maps well to the Hypertext-Web

We're looking for concrete examples of this. If you have any it would  
be very helpful if you could share the information.

> and for those where resolution is not a necessary component, it is  
> (a bit) redundant.

I agree that in cases it may be redundant. But it doesn't need to be  
expensive and I take the word of web types outside of HCLS that it  
would considered quite helpful if it did. Not to mention that if we  
expect to do scholarly work in which we use URIs it would be helpful  
to be able to publish them and have people find out a little more  
about them in the usual way.

>> which is why there is still a lot of discord about LSIDs,
>
> Most of which seems to follow the tone of the URN Registries finding

Indeed.

>  (i.e., some of the problems solved by URN schemes can be solved  
> with the HTTP scheme - once again this should not be confused as  
> recommendation for a URI scheme monopoly)

I'm still waiting for an example that *can't* be solved using a HTTP  
scheme. Do you have any? So far the best I have is that LSIDS point  
to two "forks", the data and the metadata (meaning of these not  
clear, btw). However I've already given an existence proof, in the  
way of a proposed implementation (in another thread on this list)  
that can accomplish the same thing.

Hope this commentary is considered helpful. In any case, please do  
contact Jonathan so that he can make sure your views are represented.

Regards,
Alan


>
>> which are certainly in line before INFOs. Finally, there are  
>> better  alternatives.
>>
>> Just a heads up.
>>
>> -Alan
>
> [1] http://www.w3.org/2001/tag/doc/URNsAndRegistries-50.html
>
> -- 
> Chimezie Ogbuji
> Lead Systems Analyst
> Thoracic and Cardiovascular Surgery
> Cleveland Clinic Foundation
> 9500 Euclid Avenue/ W26
> Cleveland, Ohio 44195
> Office: (216)444-8593
> ogbujic@ccf.org
>
>
> ===================================
>
> Cleveland Clinic is ranked one of the top hospitals
> in America by U.S. News & World Report (2007).
> Visit us online at http://www.clevelandclinic.org for
> a complete listing of our services, staff and
> locations.
>
>
> Confidentiality Note:  This message is intended for use
> only by the individual or entity to which it is addressed
> and may contain information that is privileged,
> confidential, and exempt from disclosure under applicable
> law.  If the reader of this message is not the intended
> recipient or the employee or agent responsible for
> delivering the message to the intended recipient, you are
> hereby notified that any dissemination, distribution or
> copying of this communication is strictly prohibited.  If
> you have received this communication in error,  please
> contact the sender immediately and destroy the material in
> its entirety, whether electronic or hard copy.  Thank you.
>
>
>

Received on Monday, 6 August 2007 21:21:30 UTC