I have to parse through xml which contain URI links to dbpedia.org. I have to extract rdf triples from those URI based on a given Ontology using Jena library. How do I resolve the Prefix programmatically in Java based on the ontology given.
The given ontology says that triples can be extracted by querying dbpedia.org. For all such triples the corresponding dbpedia resource is available to start writing the query. But the problem is how do I write the query with only its resource available. I have the properties to query. But I don't have the PREFIX for those properties
Although this may not answer the question directly, I had a whole load of URIs, some prefixed some not and I wanted them all unprefixed (i.e. written out in full with their prefixes resolved). Searching Google the most useful thing I came across was this question (first) and the JavaDoc so I thought I'd add my experience to this question to help anyone else who might be searching for the same thing.
Jena's PrefixMap interface (which Model implements) has expandPrefix and qnameFor methods. The expandPrefix method is the one which helped me (qnameFor does the reverse i.e. it applies a prefix from a PrefixMap to a string and returns null if no such mapping can be found).
Hence for any resource, to ensure that you have a fully expanded URI you can do
myRes.getModel().expandPrefix(myRes.getURI());
Hope this helps someone.
Your question is not very clear, so if this answer doesn't address your issue please edit your question to say more clearly what your problem is. However, based on what you've asked, once you've read an RDF file into a Jena model, in XML or any other encoding, the prefixes used are available through the methods in the interface com.hp.hpl.jena.shared.PrefixMapping (see javadoc). A Model object implements that interface. To automatically expand prefix "foo", use the method getNsPrefixURI().
Edit
OK, given your revised question, there's a number of things you can do to turn a simple property name into a property URI that you can use in a SPARQL query:
use the prefix.cc service to look at possible expansions of prefixes and prefix names (e.g. if you are given dbpedia:elevation, you can look it up on prefix.cc (i.e: http://prefix.cc/dbpedia:elevation) to see that one of the possible expansions is http://dbpedia.org/ontology/elevation
issue a SPARQL describe query on the resource URI to see which properties are returned in the RDF description, then match those to the un-prefixed property names you've been given
ask your data provider to give you full property names, or otherwise provide the prefix expansions, in order to save you from having to reverse engineer which properties he or she meant in the first place.
Personally I'd advocate the third option if that's at all possible.
Related
I have spent a lot of time trying to figure out what OpenAPI Links can be used for and how they relate to hypermedia links in the body of a response & it's doing my head in!
Lets say the simple class model below represents the business domain for which we have defined an OpenAPI spec that provides paths to navigate the instances of the various classes.
For example, if I perform a get of /borrowers/{id}, I would expect the response to contain both the properties of Borrower and a means to follow R1 or R2 to get the relevant set of Book instances.
Before OpenAPI 3 I would have constructed links to the relevant paths e.g.
/borrowers/{id}/loaned-books or /borrowers/{id}/reserved-books and included those as properties (hyperlinks) in the definition of the response body.
At runtime, if I followed those hyperlinks I would get an array of the relevant Books each of which had other hyperlinks.
So the OpenAPI Link questions are:
Are they a replacement for the need to generate hyperlinks in the response? I don't think so but in which case
What is the Runtime Expression Language (REL) for?
Are they just a means of defining hyperlinks in the API spec? Possibly but in which case does the response body definition still need to include properties for those links? Presumably their values still need to have the actual hyperlinks created on the server?
Given that the REL doesn't allow wildcards how do you define links when the response is an array of resources, each of which has an id to be used by the next operation?
Any help explaining links would be gratefully received.
We can use
'PATCH /companies/:id' : 'CompanyController.find'
to update data.
One suggested me that I can use the alternative way:
'PATCH /companies/find?key=Value'
But I do not know what it works. Please explain me why we prefer ? mark than : mark in search path.
You can use either or. The biggest reason most people chose one or the other is just how they want to present the URL to the user.
Using a path variable (:) can symbolize you're accessing a defined resource, like a user ID, where as an argument (?) can symbolize you're are dynamically changing/searching something within a defined resource, like a token or search term.
From what I can tell that's the general practice I see:
example.com/user/:username
versus
example.com/user/?search="foo"
http://en.wikipedia.org/wiki/URL
If we are firing GET request, ? symbol is used to let the server know the url parameter variables starts from there. And this is commonly used. I didn't used : symbol instead of ?
You are probably messing the things up:
According to your example, :id indicates a variable that must me replaced by an actual value in some frameworks such as Express. See the documentation for details.
And ? indicates the beginning of the query string component according to the RFC 3986.
It's a rule to design rest api
you can find 'how to design a rest api'
Assuming below code is Sails.js
'PATCH /companies/:id' : 'CompanyController.find'
It will makes REST API that be mapped onto 'CompanyController.find' by using PathParam. Like this
www.example.com/companies/100
Second one will makes REST API by using QueryParam.
It also be mapped onto 'CompanyController.find'
/companies/find?key=Value
But the API format is different. Like this
www.example.com/companies/find?key=100
PathParam or QueryParam is fine to make REST API.
If the Key is primary for company entity,
I think PathParam is more proper than QueryParam.
I download an N-Triple file from dbpedia,but when I wanted to read it in to Jena model,some exceptions throw out.Below is a part of this file:
<http://dbpedia.org/resource/Jacky_Cheung>
<http://dbpedia.org/resource/Template:%E8%97%9D%E4%BA%BA> "\u9AD4\u91CD"#zh .
<http://dbpedia.org/resource/Jacky_Cheung> <http://dbpedia.org/resource/Template:%E8%97%9D%E4%BA%BA> "\u8EAB\u9AD8"#zh .
<http://dbpedia.org/resource/Jacky_Cheung> <http://dbpedia.org/resource/Template:%E8%97%9D%E4%BA%BA> "\u8840\u578B"#zh .
<http://dbpedia.org/resource/Jacky_Cheung> <http://dbpedia.org/resource/Template:%E8%97%9D%E4%BA%BA> "\u8A9E\u8A00"#zh .
The exception throws out is:
Exception in thread "main" com.hp.hpl.jena.shared.InvalidPropertyURIException: http://dbpedia.org/resource/Template:%E8%97%9D%E4%BA%BA
at com.hp.hpl.jena.xmloutput.impl.BaseXMLWriter.splitTag(BaseXMLWriter.java:393)
at com.hp.hpl.jena.xmloutput.impl.BaseXMLWriter.startElementTag(BaseXMLWriter.java:368)
at com.hp.hpl.jena.xmloutput.impl.Unparser$3.wTypeStart(Unparser.java:671)
at com.hp.hpl.jena.xmloutput.impl.Unparser.wPropertyEltValueString(Unparser.java:488)
at com.hp.hpl.jena.xmloutput.impl.Unparser.wPropertyEltValue(Unparser.java:473)
at com.hp.hpl.jena.xmloutput.impl.Unparser.wPropertyElt(Unparser.java:339)
at com.hp.hpl.jena.xmloutput.impl.Unparser.wPropertyEltStar(Unparser.java:811)
at com.hp.hpl.jena.xmloutput.impl.Unparser.wTypedNodeOrDescriptionLong(Unparser.java:797)
at com.hp.hpl.jena.xmloutput.impl.Unparser.wTypedNodeOrDescription(Unparser.java:727)
at com.hp.hpl.jena.xmloutput.impl.Unparser.wDescription(Unparser.java:686)
at com.hp.hpl.jena.xmloutput.impl.Unparser.wObj(Unparser.java:642)
at com.hp.hpl.jena.xmloutput.impl.Unparser.wObjStar(Unparser.java:317)
at com.hp.hpl.jena.xmloutput.impl.Unparser.wRDF(Unparser.java:298)
at com.hp.hpl.jena.xmloutput.impl.Unparser.write(Unparser.java:200)
at com.hp.hpl.jena.xmloutput.impl.Abbreviated.writeBody(Abbreviated.java:143)
at com.hp.hpl.jena.xmloutput.impl.BaseXMLWriter.writeXMLBody(BaseXMLWriter.java:500)
at com.hp.hpl.jena.xmloutput.impl.BaseXMLWriter.write(BaseXMLWriter.java:472)
at com.hp.hpl.jena.xmloutput.impl.Abbreviated.write(Abbreviated.java:128)
at com.hp.hpl.jena.xmloutput.impl.BaseXMLWriter.write(BaseXMLWriter.java:458)
at com.hp.hpl.jena.rdf.model.impl.ModelCom.write(ModelCom.java:277)
at jena.ReadRDF.main(ReadRDF.java:45)
Java Result: 1
The problem is caused by "%E8%97%9D%E4%BA%BA",when use URIref.decode() to decode URI with this string,"%E8%97%9D%E4%BA%BA" represents tow Chinese characters.
But when I use Sesame to read this N-Triple file,it is OK without any problem.
My questions are that whether any way to solve this problem in Jena,and why dbpedia choose N-Triple to be the default RDF syntax?.It works bad with Non-ASCII languages.
Also ,I want to know that,if I want to publish my RDF data as Linked data,but the URIs of resources come with some Chinese and Japanese,should I decode the URIs at first?
Well, your question isn't completely clear because you asked about "reading in a Jena model" but the stacktrace you quoted actually starts with a call to the writer.
Jena, in general, tries very hard to conform to the relevant RDF recommendations from W3C and IETF. In particular, it tries to not generate any URI's which do not conform to the rules for valid URI's. This is compounded in the case of writing XML, because most RDF identifiers are not legal XML element ID's, meaning that you have to split the URI somewhere and use XML namespaces to make the full identifier. Not all RDF toolkits are as particular as Jena is about conforming to some of the rules in the standards.
Things you can try:
do you need to call Model.write() as part of your loading process? You should be able to load and process a model, without the check for legal URI's being invoked.
try writing the output using Turtle format, rather than XML. Turtle doesn't have the same restrictions as XML, and it's a heck of a lot easier for humans to read as well.
if there are particular ill-formed URI's in the data you are loading, look to see if there is a newer version of the data. Illegal URI's in dbpedia has been an issue in the past. If the illegal URI's are still there in the latest version, notify the dbpedia team about them.
try pre-processing your data to remove triples containing illegal URI's before they enter your processing chain.
As for URI's containing Chinese and Japanese characters, Jena conforms to the IRI spec, so as long as your URI's conform to that you should be OK.
Suppose you are working on an API, and you want nice URLs. For example, you want to provide the ability to query articles based on author, perhaps with sorting.
Standard:
GET http://example.com/articles.php?author=5&sort=desc
I imagine a RESTful way of doing this might be:
GET http://example.com/articles/all/author/5/sort/desc
Am I correct? Or have I got this REST thing all wrong?
I'm afraid your question really misses the point of REST. From a purely theoretical perspective there is absolutely no advantage or disadvantage to either of those urls from a REST perspective. In practice, those urls may behave differently with different caches, and certainly server frameworks are going to parse them differently. Despite what you hear from the framework developers, there is no such thing as a RESTful URL.
From the perspective of REST those two URLs are simply identifiers that can be dereferenced. If you want to start building REST apis that will benefit from the characteristics described in the dissertation, you need to start thinking in terms of content that is returned when you dereference the URL and how that content is linked together using URLs embedded in the content.
I realize this does not help you much in trying to resolve what you consider to be your problem. What I can tell you is that one of the major intents of REST is to allow your URLs to be completely under the control of the server and can change without impacting your client applications. Therefore, my recommendation is to pick whatever url structure works most easily with the framework you are using to serve the resource representations. Certainly do not look to the REST dissertation to tell you what is the right and wrong way of formatting your URLs and anyone who tells you that your URLs are not RESTful is confused. Probably what they are telling you is the server framework, they are used to using for creating RESTful interfaces, requires URLs to be structured this way.
It's not what your URI looks like that matters, it is what you do with it that matters.
Using a query string is not more or less RESTful than using path components. The URI Generic Syntax (RFC 3986, January 2005) defines that they're just as important in identifying the resource. So yes, as others point out, it's not important to REST. (Note that in the obsoleted-by-RFC-3986 RFC 2396, the query string was not defined to be identifying the resource, but rather a string of information to be interpreted by the resource.)
However, URI design is important, because as an owner of a URI namespace (i.e. the holder of the domain name where the URIs will live) you want the URIs to be long lived. As wise men have stated earlier: Cool URIs don't change!
The choice of using query strings vs path components depends on how your resources are identified, and how they will be identified in years to come. If there's a hierarchy that stands out, then it might be that this should be reflected in the URI, at least if that hierarchy is relatively permanent, and that things don't move around all the time.
It's also important to note that the actual URIs are only meaningful to two parties:
Servers, who need to forge and parse URIs
Human beings who might see a URI in passing might learn things from the URI.
By contrast, client applications are usually not allowed to do URI introspection. So your choice of query strings vs path components boils down to what you think you can live with ten (or 100) years from now.
You are mostly right. The thing with REST api's is to focus on the nouns.
What does the noun all do in this case? Wouldn't you expect your API to always return all articles, unless you filter it?
I would make sort a query string parameters, further, I would make any and all filtering query string parameters. If you look at how Stack is implemented when you click on the "Newest" questions link, you get a query string to filter the questions.
So perhaps something like:
GET http://example.com/aritcles/authors/5?sort=desc
But also think about what happens with each URL:
GET http://example.com/aritcles/ might return all current articles
GET http://example.com/aritcles/authors/ What does this url do? does it return all authors of all articles, or does it return all the articles for all authors (which is essentially the same functionality of the URL above.)
GET http://example.com/aritcles/authors/5/ might return all articles by author 5, or does it return author 5's information?
I would maybe change it to:
http://example.com/aritcles returns all articles
http://example.com/aritcles/5 returns all articles from author 5
http://example.com/authors returns all authors
http://example.com/authors/5 returns information for author 5
Alan is mostly right but his URLs are misleading. I believe the correct routes / urls should reflect the following behavior:
[GET] http://domain.com/articles #=> returns all articles (index action)
[GET] http://domain.com/articles/5 #=> returns article ID 5 (show action)
[GET] http://domain.com/authors/#=> returns all authors (index action)
[GET] http://domain.com/authors/5 #=> returns author ID 5 (show action)
[GET] http://domain.com/authors/5/articles OR http://domain.com/articles/authors/5 #=> depending on the hierarchy of your routes (both belong to the index action)
Best regards,
DBA
I have a Rails app that needs to expose values from a database as a web service - since I'm using Rails 2.x, I'm going with REST (or at least try). Assuming my resource is Bananas, for which I want to expose several sub-characteristics, consider this:
- /banana -> give a summary of the first 10 bananas, in full (all characteristics)
- /banana/?name=<name> -> give all characteristics for banana named <name>
- /banana/?number=<number> -> give all characteristics for banana number <number>
- /banana/?name=<name>/peel -> give peel data for banana named <name>
- /banana/?number=<number>/length -> give length data for banana number <number>
I don't want to search for ID, only name or number. And I have about 7 sub-characteristics to expose. Is this RESTful?
Thanks for any feedback!
What Wahnfrieden is talking about is something called Hypermedia as the Engine of Application State (HATEOAS) - a central constraint of REST as defined by Fielding.
In a nutshell, REST application clients never construct URIs themselves. Instead, they follow URIs provided by the application. So, URI templates such as the ones you're asking about are irrelevent at best. You can make them conform to a system if you'd like, but REST says nothing about how your URIs need to look. You could, if you wanted to, arrange it so that every resource in your system was available from http://example.com/{hash}.
Publishing URI templates, such as the ones you're talking about in your question, introduces tight coupling between your application and clients - something REST is trying to prevent.
The problem with understanding hypermedia-driven applications is that almost nobody implements or documents their "RESTful" systems this way.
It might help to think about the interaction between a human and server via a browser. The human only knows about content and links that the server provides through the browser. This is how a RESTful system should be built. If your resources aren't exposing links, they're probably not RESTful.
The advantage is that if you want to change your URI system, for example, to expose the Banana "Peel" attribute through a query parameter instead of a nested URL, you can do it anytime you'd like and no client code needs to be changed because they're not constructing links for themselves.
For an example of a system that embraces the hypertext-driven constraint in REST, check out the Sun Cloud API.
I would use these:
/banana
/banana/blah
/banana/123
/banana/blah/peel (and /banana/123/peel)
/banana/blah/length (and /banana/123/length)
First, common practice for ReSTful URIs is /object_name/id/verb, with some of those absent (but in that order). Of course, this is neither required nor expected.
If all your names aren't made of digits, you don't have to explicitly have name in /banana/name/blah. In fact, if anything, it would be better to have id as identifier: /banana/id/123/peel. Hope this helps.
Parameters should only be used for form submission.
Also, URI naming schemas is totally unrelated to REST. The point of REST is to make related resources discoverable via hypertext, not out-of-band conventions, and only from a limit number of entry points. So your /bananas/ entry point might provide the summary info for 10 bananas, but it must also provide the URI for each of those bananas' details resources, as well as the URI to get the summary for the next 10 bananas. Anything else is just RPC.
It is good practice in REST to not use query parameters because query parameters don´t belong to a URL and in REST all resources should be addressable through a URL.
In your example /banana/?name=name should be /banana/name because you are referring a concrete resource.
Even I think /banana/?number=number/length is not good REST style, because you are selecting an attribute through a URL when you should retrieve the whole state with /banana/name . A difference could be /customers/1024/address to get the Customer 1024 address record.
HTH.
A more opt form for the route in url having query string is the plural form, as it is possible that multiple items are returned in the result. In this case, bananas, like bananas?color=yellow, sounds more appropriate.
On the other hand, the singular form banana, like banana/123, is good when fetching a specific resource's representation when its identifier is known and query string is not required.