Given this (very contrived) code snippet:
System.out.println(VCARD.uri);
System.out.println(SKOS.uri);
Resource johnSmith = model.createResource("http://somewhere/js")
.addProperty(VCARD.FN, "John Smith")
.addProperty(SKOS.notation, "John Smith");
model.write(System.out);
we get
http://www.w3.org/2001/vcard-rdf/3.0#
http://www.w3.org/2004/02/skos/core#
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:vcard="http://www.w3.org/2001/vcard-rdf/3.0#"
xmlns:j.0="http://www.w3.org/2004/02/skos/core#">
<rdf:Description rdf:about="http://somewhere/js">
<j.0:notation>John Smith</j.0:notation>
<vcard:FN>John Smith</vcard:FN>
</rdf:RDF>
Given that SKOS is represented internally in Jena, why is it still returning the j.0 notation (yet not for the vcard property)? I've read similar questions (e.g. this one and this one and this one) but they seem to refer to people referring to their own ontology. Given that the uri constant is correct for SKOS, why does it change in the RDF representation?
The code has used URIs from SKOS but not set the prefix on the model. See setNsPrefix.
You may wish to use the pretty printing form of output, the default is only basic RDF/XML. Set the syntax name in the model.write call (see javadoc for details).
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.
Im trying to create some custom blocks for a CMS interface based on the symfony-cmf. In order for these blocks to be edited inline with createphp/hallo i need to create RDFa mappings for them.
The basic example for an included block is something like the following:
<type
xmlns:sioc="http://rdfs.org/sioc/ns#"
xmlns:dcterms="http://purl.org/dc/terms/"
xmlns:skos="http://www.w3.org/2004/02/skos/core#"
typeof="sioc:Post"
>
<attribute key="class" value="articleContainer span3"/>
<children>
<property property="dcterms:title" identifier="title" tag-name="h2"/>
<property property="sioc:content" identifier="content" />
</children>
</type>
Which would yield something like this:
<h2>The title input</h2>
<p>the content, however i beleive the actual <p> tag is applied by the editor</p>
Thats all well and good... What Im having a hard time figuring out how to define this mapping for a resource that will be something like this:
<h1>Text string with <strong>emphasized phrase</strong> in the middle</h1>
I could probably just use the sioc:content type and then rely on the user to "bold" the emphasized phrase in the editor but i would rather have it be edited explicitly.
Is there a way to do this? Also if anyone could point me towards solid RDFa tutorials that would be great. My google-fu is usually strong but all i can seem to find are the actual spec, and a bunch of posts about seemingly unrelated usages.
The idea of the RDFa mapping is to specify which properties of the document you want to render with which tags. Actual content typically is WYSIWYG. I guess RDFa being quite complex it would support inline-nested information like what you are asking for. But the midgard/createphp component which reads this XML configuration to generate the right data does not support nested content. I am not sure if create.js would support it, but i think not.
Note that you can map children and output whole content hierarchies. But that would not handle your emphasised fragment.
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.
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.
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