Thanks, Holger.
Whatever we want to call the problem, your email recounts and confirms
the issue I was having. Great to see it will work in 3.6.1.
Cordially,
Kevin
On 05/01/2012 09:11 PM, Holger Knublauch wrote:
Hi Kevin,
small correction: the content negotiation is already implemented fine.
The issue though is that the current algorithm removes the part after
the / or #, i.e. it was expecting cases such as
http://id.loc.gov/authorities/names/no2011075212/
or
http://id.loc.gov/authorities/names/no2011075212#
but it converts
http://id.loc.gov/authorities/names/no2011075212
to
http://id.loc.gov/authorities/names/
I think this is what you have observed as well. I have just changed this
so that if the URI does not contain a # it will not remove the local
name part, i.e. leave the request as you need it. For your example URIs
this works fine, and at this stage I cannot think of a counter example,
so it will likely make it into 3.6.1. Your patience is appreciated and
thanks for your report.
Holger
On 5/2/2012 3:46, Kevin Ford wrote:
Yep. That's it.
For whatever it is worth, or whatever my vote is worth, I think it
would make for a fine enhancement. Clearly, I've already tried to do
this, but I can't see how this might not be a good thing. Such an
enhancement would allow anyone to enter a URI of a resource and TBC
could retrieve information about that resource. It's a piecemeal way
to add information to a graph, but...
I don't know how your other users feel about such a feature, of course.
Thanks for looking into this and your response!
Cordially,
Kevin
On 05/01/2012 01:33 PM, Scott Henninger wrote:
Ah, you're looking for content negotiation. We simply don't do this
in TBC. We can add it as an enhancement request.
-- Scott
On May 1, 11:40 am, Kevin Ford<[email protected]> wrote:
Dear Scott,
Thanks for the reply, but I'm still confused.
The URI I want in my data is:
<http://id.loc.gov/authorities/names/no2011075212><http://id.loc.gov/authorities/names/no2011075212>
You'll see that by following the above URI, it does not return a 404
(you
can also perform content-negotation on the URI and get the triples).
Naturally, I can input this URI into TopBraid Composer (yes, that is
the
product) easy enough, but TopBraid does not appear to dereference
the URI
properly, or at least in such a way as to retrieve the triples when
I try
to "import triples for this resource."
You seemed to be testing it out in TopBraid (thanks for the additional
effort) - try using the above URI as the object of a triple and then
"import triples for this resource."
Cordially,
Kevin
On Tuesday, May 1, 2012 12:00:39 PM UTC-4, Scott Henninger wrote:
Kevin; I believe this is how that Web page is set up. Note that
<http://id.loc.gov/authorities/names#no2011075212> will work as you
say - you will be prompted to import the triples.
But try these addresses in a browser:
-http://id.loc.gov/authorities/names.html#no2011075212
successfully gets a page
-http://id.loc.gov/authorities/names.html/no2011075212results in
a 404.
I believe TopBraid Composer (I assume this is the product you are
using) is getting the same responses. Note that the error message you
get states "Caused by: org.topbraid.core.io.HttpException:
http://id.loc.gov/authorities/names/:Not Found (404)"
-- Scott
On May 1, 8:40 am, Kevin Ford<[email protected]> wrote:
Dear All,
I'm having problems importing triples for a resource.
If I make this URI<http://id.loc.gov/authorities/names/no2011075212>,
for example, the object of a triple, I get the option to "import
triples
for this resource." But, when I try to do that, I get a message that
the operation failed, "Reason: java.io.IOException: Failed to load:
http://id.loc.gov/authorities/names/ at ...". Although
"http://id.loc.gov/authorities/names/"; is, or certainly can be viewed
as, the namespace for this resource, the URI is individually
dereferenceable.
I can trick TopBraid by adding a hash symbol to the end of the
URI, (and
thereby manufacturing a URI that didn't exist before). Once I do
that,
and I choose to import the triples, I get a message that "the
namespacehttp://id.loc.gov/authorities/names/no2011075212#hasbeen
successfully
loaded and could be imported into this project."
"http://id.loc.gov/authorities/names/no2011075212#"; is not the
namespace
and I've only succeeded here, by my accounting, via trickery.
Am I missing something obvious? Am I misunderstanding how this
*should* work?
Cordially,
Kevin
--
You received this message because you are subscribed to the Google
Group "TopBraid Suite Users", the topics of which include Enterprise Vocabulary
Network (EVN), TopBraid Composer,
TopBraid Live, TopBraid Ensemble, SPARQLMotion and SPIN.
To post to this group, send email to
[email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/topbraid-users?hl=en
