Re: Immunity of SW statements to changes in location - data integration use case

Khalid Belhajjame wrote:
> I am not sure whether the following issue has already
been discussed.
> By using the identifiers to also locate where the RDFs
statements describing
> the resource in question are, don’t we somehow dictate
where the document(s)
> containing the RDFs statements describing a given
resource are to be
> located?

Not dictating anything, just providing some useful default
behavior. If you 
prefer to resolve http://purl.un
iprot.org/uniprot/P12345 to let's say 
http://www.eb
i.uniprot.org/entry/P12345, you can do so in your
application.

Eric Jain wrote:
> Khalid Belhajjame wrote:
>> I am not sure whether the following issue has
already been discussed.
>> By using the identifiers to also locate where the
RDFs statements 
>> describing
>> the resource in question are, don’t we somehow
dictate where the 
>> document(s)
>> containing the RDFs statements describing a given
resource are to be
>> located?
> 
> Not dictating anything, just providing some useful
default behavior. If 
> you prefer to resolve http://purl.un
iprot.org/uniprot/P12345 to let's 
> say http://www.eb
i.uniprot.org/entry/P12345, you can do so in your 
> application.

 From the recent threads, I get the impression that we are
trying to do 
combine two functions into the URI:

1) the unambiguous *identification* of a given concept in
our own RDF
2) retrieve associated data records from the same URI

Although 2) seems like a nice convenience feature, we have
the problem 
of ambiguity that Alan pointed out: It should be possible to
distinguish 
statements about a particular data record associated with a
concept from 
statements about the concept.

See, for example, http://beta.uniprot.org/uniprot/?query=p53&sort=sco
re 
. "Which data record for P53 did you mean?"

-scott

-- 
M. Scott Marshall
http://staff.sc
ience.uva.nl/~marshall
http://adaptivedisclosu
re.org