Re: [Lsid-developer] (no subject)

[Sean M. <sj...@us...>]

>Is there any reason, apart from backwards compatability, that we can't 
push for LSIDs to be     
> LSID ::= <AuthorityID> ":" <NamespaceID> ":" <ObjectID> 
(":"<RevisionID>) 

Stefan, would the URN spec's allow this ?

>Regarding the getKnownURIs issue I agree with Stefan that we have to have 
some sort of limits on what getKnownURIs returns.   If some authority has 
LSIDs for every range of data it can return, the getKnownURIs >call would 
basically be returning an LSID for every crosssection of its RDF web and 
could be virtually infinite.

Dont forget that this is 1] and optional call and may not be implemented 
at all 2] we were talking about modifying it to allow an optional 
namespace parameter that would limit it a bit, not sure if this happened 
yet  3] the data provider can decide just how much/how little they want to 
return.. this means it need not return a complete exhaustive list.

S.






Alyssa Wolf/Cambridge/IBM@IBMUS
Sent by: lsi...@ww...
03/21/2003 11:34 AM

To
lsi...@os...
cc

bcc

Subject
Re: [Lsid-developer] (no subject)




Hello All,  
I want to bring up a couple more things consider as  well as suggest 
another idea for one of the issues Stefan raised. 

We started out having LSID as  
        LSID ::= <AuthorityID> ":" <NamespaceID> ":" <ObjectID> ":" 
(<RevisionID>) 
We at IBM have working code which makes the trailing colon optional if 
there were no revisionID listed, as RDF can not handle trailing :s. 
Is there any reason, apart from backwards compatability, that we can't 
push for LSIDs to be  
        LSID ::= <AuthorityID> ":" <NamespaceID> ":" <ObjectID> 
(":"<RevisionID>) 
The removes the ambiguity of the trailing colon as well as simplifying 
canonicalization of LSIDs (which often have to remove the trailing : so 
that LSID equivalence holds outside of programs that understand LSIDs).   
 There is still the issue of backwards compatibility but that would be a 
problem in either case as any authorities which require a trailing : would 
have to be rewritten anyway (or would fail if they got an lsid with the 
optional : removed).   

Regarding the getKnownURIs issue I agree with Stefan that we have to have 
some sort of limits on what getKnownURIs returns.   If some authority has 
LSIDs for every range of data it can return, the getKnownURIs call would 
basically be returning an LSID for every crosssection of its RDF web and 
could be virtually infinite.  I'm wondering, though,  if we can 
consolidate that call with the rest of the meta-data calls somehow.  If we 
want a list of all LSIDs or all LSIDs in a given namespace we're asking 
for a list of nodes/edges in the RDF graph.  Should there be a seperate 
call for that?   Also, do we want to have some known error return code if 
someone asks a query with a scope that's too large?   

My last thought was that our meta-data queries are getting sufficiently 
complex that they're not always meta-data about a specific LSID - if one 
does a query for all abstract lsids (?x<isAbstractOf>?y) what LSID is that 
meta-data for?  Maybe we should have the meta-data accessible as an 
authority call as well as a per-lsid operation (unless we're assuming the 
authority may not know the location of the meta-data store(s)) 

-Alyssa 



More things to think about:

                One of the criticisms of our current scheme is that there 
is no way of
                asking for all versions of an LSID without a call to 
getKnownURIs -
                that is, given the LSID
                                
 "urn:lsid:AUTHORITY:NAMESPACE:OBJECT_ID:something",
                we should be able to get a list containing
                                
 "urn:lsid:AUTHORITY:NAMESPACE:OBJECT_ID:*"

                I think we should be able to ask for all LSIDs with a 
given prefix:

                getKnownURIs for the ibm.com authority will be the same as 
asking
                the authority for all LSIDs with prefix 
"urn:lsid:ibm.com".
                To get all supported predicates, we can ask for all LSIDs 
with
                prefix "urn:lsid:ibm.com:predicates". Lastly, to ask about 
all versions
                of "urn:lsid:ibm.com:releases:resolver-perl:v0.03" we will 
ask for
                all LSIDs with prefix 
"urn:lsid:ibm.com:releases:resolver-perl".




_______________________________________________
Lsid-developer mailing list
Lsi...@ww...
http://www-124.ibm.com/developerworks/oss/mailman/listinfo/lsid-developer