Subject: Re: Question on FHIR references - relative and absolute URIs
Hi Thomas,
Same digital signature means that - after cannonicalization - there are the
same bytes. That's key. Indenting the XML changes the raw bytes, but doesn't
change the bytes of the canonicalized form. On
t Hausam ;
> Grahame Grieve ; i...@lists.hl7.org;
> w3c semweb HCLS
> *Subject:* Re: Question on FHIR references - relative and absolute URIs
>
>
>
> Hi Thomas,
>
>
>
> Same digital signature means that - after cannonicalization - there are
> the same bytes.
mailto:grah...@healthintersections.com.au>>,
"i...@lists.hl7.org<mailto:i...@lists.hl7.org>"
mailto:i...@lists.hl7.org>>,
"public-semweb-lifesci@w3.org<mailto:public-semweb-lifesci@w3.org>"
mailto:public-semweb-lifesci@w3.org>>
Subject: Re: Questi
rieve
;
i...@lists.hl7.org; w3c semweb HCLS
Subject: Re: Question on FHIR references - relative and absolute URIs
Hi Thomas,
Same digital signature means that - after
cannonicalization - there are the same
bytes. That's key. Indenting the XML changes
the raw bytes, but doesn't c
different then it won't produce the
> same digital signature.
>
> So I don't agree that those are different "definitions" of "the same
> thing", or that the digital signature interpretation is "looser".
>
> TJL
>
>
>
or that the digital signature interpretation is "looser".
�
TJL
�
Original Message
Subject: Re: Question on FHIR references - relative and absolute URIs
From: "David Booth"
Date: Wed, April 27, 2016 9:48 am
To
ven
looser then we would have to clearly define it and describe the problem
that it is intended to solve. Such a definition could have some utility
but I am doubtful that it would be enough to justify the work and the
confusion that would be added by having one more notion of equivalence.
David
--- Original Message
Subject: Re: Question on FHIR references - relative and absolute URIs
From: "Lloyd McKenzie"
Date: Tue, April 26, 2016 3:00 pm
To: "Grahame Grieve"
Cc: "David Booth"
"i...@lists.hl7.org"
"w3c semweb HCL
ense that they're equivalent (meaning that
"they point to the same thing"), but it wouldn't be OK if they have to be "the
same thing" in the stricter sense of not altering the digital signature. �
�
TJL
�
Origi
at signing introduces in mind
when evaluating and testing the round tripping of our prototype RDF instances.
�
I think that if we *were* doing that, we would have been aware of what
Lloyd pointed out, and have been able to answer our own question RE the
preservation of absol
discussed aspects of round tripping.
�
TJL
�
Original Message
Subject: Re: Question on FHIR references - relative and absolute URIs
From: "Lloyd McKenzie"
Date: Tue, April 26, 2016 3:00 pm
To: "G
k that if we *were* doing that, we would have been aware of what
> Lloyd pointed out, and have been able to answer our own question RE the
> preservation of absolute and relative URIs.
>
> TJL
>
> Original Message
>
> Su
--- Original Message ----
Subject: Re: Question on FHIR references - relative and absolute URIs
From: "Lloyd McKenzie"
Date: Tue, April 26, 2016 3:00 pm
To: "Grahame Grieve"
Cc: "David Booth"
"i...@lists.hl7.org"
&
n Wed, Apr 27, 2016 at 3:01 AM, David Booth > wrote:
>
>> Grahame and/or Lloyd,
>>
>> In today's FHIR RDF teleconference, a question came up about relative and
>> absolute URIs in FHIR references.
>>
>> Must absolute and relative references be round tri
at 3:01 AM, David Booth wrote:
> Grahame and/or Lloyd,
>
> In today's FHIR RDF teleconference, a question came up about relative and
> absolute URIs in FHIR references.
>
> Must absolute and relative references be round tripped as is? I.e., do we
> need to maintain
Grahame and/or Lloyd,
In today's FHIR RDF teleconference, a question came up about relative
and absolute URIs in FHIR references.
Must absolute and relative references be round tripped as is? I.e., do
we need to maintain the distinction between relative and absolute
references when
r with an api key. Seems to me the
goals also have to do with tracking the usage of the URIs and the
users of the resource.
I have tried to advise the Bioportal team about the basic of linked
data norms and etiquette in the past, but they seem to be slow to
progress along the learning curve.
UMLS MeSH terminology that
does resolve after some forwarding. This behavior seems correct.
These URIs have nothing to do with our APIKEY business since neither
resolve to a REST call.
Ray
See:
http://bioportal.bioontology.org/ontologies/46836?p=terms&conceptid=C010843
And:
curl -IL
Our NCBO funders, our advisors, and ourselves require that we know who is
using our services and what they are doing. IP address is not enough. We
need the names of real people and we need their projects.
We aren't using APIKEYs to attempt to block bots or to do rate limiting -
though we may ev
Agreed. You do not. BioPortal requires an APIKEY for REST calls but not
for any UI display.
Ray
solve after some forwarding. This behavior seems correct.
These URIs have nothing to do with our APIKEY business since neither
resolve to a REST call.
Ray
at. No problem
if this information is in a triple-store, but if I want to use a linked data
frontend, I'm moreor less forced to have my URI for http://you/youknowwhat (In
sense, mine would be an access-uri, not really an identifier as all that is
returned could predicate on http://you/youknowwhat
vely not what you
> want in this area! (as reminder... many users of biportal may not be that
> tech-savy).
>
I know. More the reason to set a good example.
> Rewriting URIs...
> What if you want to expose as Linked-Data (RESTy) third party data ? You
> need at least to provide n
ithout thinking. More complex schemes
may push some people away: definitively not what you want in this area! (as
reminder... many users of biportal may not be that tech-savy).
Rewriting URIs...
What if you want to expose as Linked-Data (RESTy) third party data ? You need
at least to provid
also have to
do with tracking the usage of the URIs and the users of the resource.
I have tried to advise the Bioportal team about the basic of linked data norms
and etiquette in the past, but they seem to be slow to progress along the
learning curve. Kingsley, may I suggest that you give spe
The OBO library subset of bio-ontologies have URIs that conform to linked data
norms.
E.g.
http://purl.obolibrary.org/obo/GO_0006264 - mitochondrial DNA replication
http://purl.obolibrary.org/obo/CL_617 - GABAergic neuron
http://purl.obolibrary.org/obo/MP_0002766 - situs inversus
http
PM, Peter Ansell wrote:
>
>> Hi Kingsley,
>>
>> I think you may need an API key to work with them? [1]
>>
>> Cheers,
>>
>> Peter
>>
>> [1] http://www.bioontology.org/wiki/index.php/NCBO_REST_services
>>
>>
>> On 29
an API key to work with them? [1]
Cheers,
Peter
[1] http://www.bioontology.org/wiki/index.php/NCBO_REST_services
On 29 May 2013 05:55, Kingsley Idehen mailto:kide...@openlinksw.com>> wrote:
All,
Who are the folks responsible for URIs such a
Kingsley,
>
> I think you may need an API key to work with them? [1]
>
> Cheers,
>
> Peter
>
> [1] http://www.bioontology.org/wiki/index.php/NCBO_REST_services
>
>
> On 29 May 2013 05:55, Kingsley Idehen wrote:
>
>> All,
>>
>> Who
Hi Kingsley,
I think you may need an API key to work with them? [1]
Cheers,
Peter
[1] http://www.bioontology.org/wiki/index.php/NCBO_REST_services
On 29 May 2013 05:55, Kingsley Idehen wrote:
> All,
>
> Who are the folks responsible for URIs such as:
>
> 1.
> <http:/
All,
Who are the folks responsible for URIs such as:
1. <http://purl.bioontology.org/ontology/NCIM/C0144157> ?
2. <http://purl.bioontology.org/ontology/MSH/C010843> ?
I ask due to the following curl output:
HTTP/1.1 302 Moved Temporarily
Date: Tue, 28 May 2013 19:46:48 GMT
With regard to URIs for vocabulary entities, I have already completed this
task for the NLM MeSH 2010 thesaurus (see attached abstract for AMIA CRI
2010), and will be adding additional major vocabularies including UMLS in
the coming months.
For examples of URIs/URLs for MeSH2010 consider the
May be a related question, for gene information, should be use entrez
gene id or umls id (cui)?
Cheers,
-Kei
Matthias Samwald wrote:
Sorry for asking such a seemingly simple question. Establishing URIs
for UMLS entities has now been discussed for years. What is the
current status of this
Sorry for asking such a seemingly simple question. Establishing URIs for UMLS
entities has now been discussed for years. What is the current status of this
development? Do we have somehow useful, acccepted, possibly linked-data
friendly entities for UMLS IDs by now? I seem to be unable to find
is inconsistent, not because of this equivalence.
Is there a way to express this in RDF ? Don't think so...
I am not sure exactly what you intend. Do you mean that you want to
assert the equivalence of the URI as the symbols or you want to
assert that the referent of the two UR
so...
I am not sure exactly what you intend. Do you mean that you want to
assert the equivalence of the URI as the symbols or you want to
assert that the referent of the two URIs are the same? If your
intension is the latter, I don't think RDF offers this kind of
vocabulary. But you
mean that you want to
assert the equivalence of the URI as the symbols or you want to assert
that the referent of the two URIs are the same? If your intension is
the latter, I don't think RDF offers this kind of vocabulary. But you
can always mint your own terms just as with all other con
t; Is there a way to express this in RDF ? Don't think so...
No, there is not. However, Pat Hayes, at a semantic web interest group meeting
in Cambridge a few months ago, talked about drafting a spec for a new version
of RDF. And I think TimBL -- though I may be mistaken about who made the
sugge
sible solution. There
might be hope. :-)
-Kei
Alan Ruttenberg wrote:
So I count three different sets of URIs for NCBI taxonomy so far. :(
-Alan
On Fri, Feb 27, 2009 at 11:37 AM, Chris Mungall
wrote:
also..
part of the NCBI taxonomy is in NIF Organism:
http://ontology.neuinfo.or
On 22 Aug 2007, at 00:58, Chimezie Ogbuji wrote:
Since this dialog is playing out on several fronts and I would like
the dissenting view well-articulated, I've taken the liberty to flesh
out the (previously empty) "HTTP URIs are not Without Expense" Wiki
(http://esw.w3
Since this dialog is playing out on several fronts and I would like
the dissenting view well-articulated, I've taken the liberty to flesh
out the (previously empty) "HTTP URIs are not Without Expense" Wiki
(http://esw.w3.org/topic/HCLS/HCLS_URI_matrix/HttpUrisAreExpensive).
I'
Here are the details for the informal F2F meeting on July 16, where we will
be discussing URIs.
http://esw.w3.org/topic/HCLSIG_BioRDF_Subgroup/Meetings/2007/07-16_Conference_Call
Cheers,
Susie
using LSID resolution.
Of course, the proxy would not need to be hard-coded to recognize the
prefix. It could merely read some string pattern matching rules (or an
ontology) to map http://entrez.example/2007/lsid: URIs to urn:lsid:
URIs.
Furthermore, the resource metadata returned when the http
Message-
From: Kwan, Kathy (NIH/NLM/NCBI) [E] [mailto:[EMAIL PROTECTED]
Sent: Thu 2/22/2007 6:18 PM
To: Eric Neumann
Cc: Kwan, Kathy (NIH/NLM/NCBI) [E]
Subject: RE: URIs for NCBI data
Hi Eric,
We had some intial discussions and plan to work on a stable/usable URL
scheme for our resources
FYI...
-Original Message-
From: Kwan, Kathy (NIH/NLM/NCBI) [E] [mailto:[EMAIL PROTECTED]
Sent: Thu 2/22/2007 6:18 PM
To: Eric Neumann
Cc: Kwan, Kathy (NIH/NLM/NCBI) [E]
Subject: RE: URIs for NCBI data
Hi Eric,
We had some intial discussions and plan to work on a stable/usable URL
I would like to add that I happen to think that Barry Smith's work on
mereotopology [1], the information flow framework [2] based on the work
of Barwise et al., and even the obscure works of Zippie Gonczarowski [3]
all warrant consideration in light of interest in the category-theoretic
appro
Oops - I forgot to add...
Again - in this area, I think the TMRM work Jack Park has mentioned
may turn out to be extremely useful. Several folks have already
begun to look for ways to bridge that formalism with RDF. He makes
some mention of this in early posts and had some additional ins
Another fantastic citation worth it's weight in gold and definitely
relevant to the long-term goal here of creating an algorithmic means
to express - and then operate on - biomedical knowledge! Many
thanks, Bob. I've already passed on your "hedging" reference to
several other colleagues
ly pointing out that RDF and
OWL were deliberately trying to use URIs as pure names, and leave
the interaction with Web retrieval for additional work. Now all we
need to do is do it :-)
Thanks for the comments. From what you referenced, it seems clear
that RDF/OWL deliberately avoided "the pro
I would suggest that both natural language *and* ontologies are views
of (possibly shallow) underlying knowledge. This knowledge is
difficult to characterize. It is also difficult to achieve agreement
on it within or across communities.
I find the following study sobering. Don't be misled by t
Here is a link to the message I sent out last year regarding handling
URNs in concatenated URL forms:
http://lists.w3.org/Archives/Public/public-semweb-lifesci/2005Apr/0010
This approach only works if it is explicitly agreed that URN's need to
be accompanied by a handler URL. As stated by ot
Hi All,
First, I'd like to recommend two articles I believe are very relevant
to this discussion and may help provide us a clearer sense of how to
proceed here:
1) X. Wang, Robert Gorlitsky, and Jonas S Almeida, From XML to RDF:
how semantic web technologies will change the design of 'o
ting out that RDF and OWL were deliberately trying
> to use URIs as pure names, and leave the interaction with Web
> retrieval for additional work. Now all we need to do is do it :-)
Thanks for the comments. From what you referenced, it seems clear that
RDF/OWL deliberately avoided "t
A couple of comments:
1. The "processing model" of RDF isn't "ambiguous", it is
*unspecified*; that is, no processing model is specified, and that is
deliberate. RDF doesn't define if and when a URI should be
dereferenced from an RDF model because RDF doesn&
Alan,
> > URI http://www.example.com/gene;
> >
> > You need to dereference the "gene" variable in order to
> understand it
> > and do something meaningful about it.
>
> That's one way. You can also publish a paper that describes
> it, get a bunch of people agree to use it the same way,
> sup
On Jun 19, 2006, at 9:49 AM, Xiaoshu Wang wrote:
URI http://www.example.com/gene;
You need to dereference the "gene" variable in order to understand
it and do
something meaningful about it.
That's one way. You can also publish a paper that describes it, get a
bunch of people agree to u
half Of William Bug
> Sent: Monday, June 19, 2006 8:20 AM
> To: John Madden
> Cc: Alan Ruttenberg; w3c semweb hcls
> Subject: Re: [rdf] Re: URIs
>
>
>
> I think this is an excellent reference to work from, when dealing
> with the issue of URIs in RDF generation &
Alan,
> Dereference, in that context, means something different than
> what I was using the term for.
> They mean that there has to be a definition of the subject
> and object in the OWL file or one of the imports.
>
> I was using it to mean, go to the network and do a geturl of
> the uri and
I think this is an excellent reference to work from, when dealing
with the issue of URIs in RDF generation & processing.
As I have always seen it (this is admittedly a the view of an RDF
naif), DOIs and LSIDs both seek to fulfill the role one would expect
to be played by URIs in the
quantitative modelling, and
decided to use the same systems of unique URIs. See:
Yes, the problem pops up everywhere. See recent threads on public-
semweb-lifesci
http://lists.w3.org/Archives/Public/public-semweb-lifesci/2006May/
0042.html
http://lists.w3.org/Archives/Public/public-semweb
It's probably worth noting (for the purpose of this thread) that there is
a recently created ESW Wiki on the mechanics / best practices of Dereferencing URIs:
http://esw.w3.org/topic/DereferenceURI
Chimezie Ogbuji
Lead Systems Analyst
Thoracic and Cardiovascular Surgery
Cleveland C
RDF (and OWL, when appropriate) representation of their data (and/or
web-based APIs), but usually get stuck on two issues related to URIs:
1) how does one translate current references in XML docs (or
databases for that matter) to URIs;
2) once I've figured out '1', what can
Alan,
I find myself continually groping for the requirements. Could you
provide a specific example of what you want to do with the URI in RDF,
i.e. a specific piece of RDF with a specific gene? It might help us to
frame the discussion (if you still have time!).
It seems like what we'd all l
Dereference, in that context, means something different than what I
was using the term for.
They mean that there has to be a definition of the subject and object
in the OWL file or one of the imports.
I was using it to mean, go to the network and do a geturl of the uri
and do something wi
eem to be:
>
>a) The identifier is not intended to be dereferencable. In that
> case the info: scheme was suggested for the form of the uri,
> as that is explicitly not dereferenceable.
>
>b) The URI is used primarily as a name. Insofar as we want
> use names, it is impor
he RDF output means
changing some code. Developing the bridge ontology (or ontologies) will
likely be semi-automated - perhaps less easy to change, but not beyond our
means.
jb
- Original Message -
From: "Alan Ruttenberg" <[EMAIL PROTECTED]>
To:
Sent: Friday, June 16, 2
Alan et al,
Wow, great topic. I'll need to get my thoughts together on this.
Meanwhile, operationally what a uri "means" is clearly related to the
question of its (non)persistence. I recently found a wonderful
historical review of this topic from the point of view of a library
scientist.
[It was on this list: http://lists.w3.org/Archives/Public/public-
semweb-lifesci/2006Jun/0149]
-Alan'
On Jun 18, 2006, at 12:20 PM, John Madden wrote:
I can't locate the beginning of this thread. Did the discussion
start on another list?
Thanks.
John
On Jun 17, 2006, at 1708, Eric Neuman
I can't locate the beginning of this thread. Did the discussion start
on another list?
Thanks.
John
On Jun 17, 2006, at 1708, Eric Neumann wrote:
This is a very useful and important discussion thread, and I would
like to see others on the list to contribute their thoughts/
concerns as
Eric Neumann <[EMAIL PROTECTED]> wrote on
06/17/2006 12:33:25 PM:
> May I ask all the contributors to include HTML links to any acronyms
> they reference (e.g., NAPTR)? This will make it easier for the rest
of
> us to catch up quickly, and to eventually collect the approaches out
> there into
This is a very useful and important discussion thread, and I would like
to see others on the list to contribute their thoughts/concerns as
well.
May I ask all the contributors to include HTML links to any acronyms
they reference (e.g., NAPTR)? This will make it easier for the rest of
us to
MW>
MW> I believe this SRV-redirection behaviour is part of the LSID spec,
and
MW> we use it for all of the BioMOBY LSIDs...
MW>
It also uses NAPTR's as described in IETF RFC's 3401->3405
to traverse the URN namespace, allowing the dereferencing process to bridge
the gap that separates authorit
On Fri, 2006-06-16 at 10:41 -0400, Alan Ruttenberg wrote:
> something, but as far as I can see, the only authority related to
> namespaces in URLs is the DNS, and while there is the SRV field which
> might be used to direct someone to information about the namespace, I
> don't know whether
comparing URIs. info
has some basic rules for normalization, but then allows registered
public namespaces to add additional ones. Those normalization rules are
not encoded in a machine usable manner, meaning that applications that
are to use info uris reliably must, in order to be correct, have a
Hi Alan,
AR> b) The URI is used primarily as
a name. Insofar as we want use
AR> names, it is important there be some stable URIs. Of course it
AR> doesn't hurt if the URI becomes dereferenceable at some point, and
it
AR> would even be nice,
AR> d) Any URL we use
http://info-uri.info/registry/docs/misc/faq.html) - bar a couple of places
I still need to update - to bring this in line with the RFC.
To see an example of INFO URIs being dereferenced you might care to see this
blog post on inkdroid last month:
http://www.inkdroid.org/journal/2006/05/16/info-uris-and-o
There was an discussion a few weeks ago about URIs touch on various
issues. This message is an attempt to untangle them, something I said
I would write up as an action item in one of the HCLS conference
calls. We'll be discussing URIs at the monday BioRDF conference call.
As I rea
77 matches
Mail list logo
