I wouldn't be so categorical :) We generate all the UI layouts straight from RDF/XML using XSLT 2.0: https://github.com/AtomGraph/Web-Client/blob/master/src/main/webapp/static/com/atomgraph/client/xsl/bootstrap/2.3.2/layout.xsl
The prerequisite is that RDF/XML structure is predictable like Jena's output, not any RDF/XML that is possible in the wild. We have actually proposed to standardise this in some form: https://www.w3.org/community/rax/wiki/Draft_Material#RDF.2FXML_.22plain.22_profile_suitable_for_XSLT_transformations On Wed, Oct 11, 2017 at 9:16 AM, Olivier Rossel <olivier.ros...@gmail.com> wrote: > I don't see any practical usage of managing RDF data via its XML > serialization through XML tools. > In my town, a huge project tried to store graph data in a XML > database. And querying all that with XQuery. > It was probably the most expensive failure I have seen in my career. > (performances were awful). > > I think it is and always has been a HUGE error to maintain this > ambiguity that RDF/XML is XML. No no and no, it is RDF. > May be you can generate RDF/XML via XML tools. Sure. > But consuming RDF/XML with XML tools is a BAD idea. > > > > On Sat, Oct 7, 2017 at 6:14 PM, <aj...@apache.org> wrote: > > Simply because it is both XML and RDF. > > > > There is an enormous installed base of expertise and tooling for XML. > It's > > often worth taking advantage of, even if it is technically unperformant > on a > > case-by-case basis. If you have to process RDF and you already know a > great > > deal about XML and use languages like XSLT or XQuery, reusing them for > RDF > > is very attractive. > > > > Historically, there was an idea of a unified layered architecture to the > > semantic web activity. I think this Wikipedia page: > > https://en.wikipedia.org/wiki/Semantic_Web_Stack is old enough to > portray > > that idea. I'm not sure anyone now would be willing to argue that XML > sits > > under RDF as a syntax layer. (Think about the evolution of JSON and > JSON-LD, > > not shown at all on that picture.) > > > > > > ajs6f > > > > Andrew U. Frank wrote on 10/7/17 12:06 PM: > >> > >> thank you - your link indicates why the solution with calling s-put for > >> each individual file is so slow. > >> > >> practically - i will just wait the 10 hours and then extract the triples > >> from the store. > >> > >> can you understand, why somebody would select this format? what is the > >> advantage? > >> > >> andrew > >> > >> > >> > >> On 10/07/2017 10:52 AM, zPlus wrote: > >>> > >>> Hello Andrew, > >>> > >>> if I understand this correctly, I think I stumbled on the same problem > >>> before. Concatenating XML files will not work indeed. My solution was > >>> to convert all XML files to N-Triples, then concatenate all those > >>> triples into a single file, and finally load only this file. > >>> Ultimately, what I ended up with is this loop [1]. The idea is to call > >>> RIOT with a list of files as input, instead of calling RIOT on every > >>> file. > >>> > >>> I hope this helps. > >>> > >>> ---- > >>> [1] https://notabug.org/metadb/pipeline/src/master/build.sh#L54 > >>> > >>> ----- Original Message ----- > >>> From: users@jena.apache.org > >>> To:"users@jena.apache.org" <users@jena.apache.org> > >>> Cc: > >>> Sent:Sat, 7 Oct 2017 10:17:18 -0400 > >>> Subject:loading many small rdf/xml files > >>> > >>> i have to load the Gutenberg projects catalog in rdf/xml format. this > >>> is > >>> a collection of about 50,000 files, each containing a single record > >>> as > >>> attached. > >>> > >>> if i try to concatenate these files into a single one the result is > >>> not > >>> legal rdf/xml - there are xml doc headers: > >>> > >>> <rdf:RDF xml:base="http://www.gutenberg.org/"> > >>> > >>> and similar, which can only occur once per file. > >>> > >>> i found a way to load each file individually with s-put and a loop, > >>> but > >>> this runs extremely slowly - it is alrady running for more than 10 > >>> hours; each file takes half a second to load (fuseki running as > >>> localhost). > >>> > >>> i am sure there is a better way? > >>> > >>> thank you for the help! > >>> > >>> andrew > >>> > >>> -- > >>> em.o.Univ.Prof. Dr. sc.techn. Dr. h.c. Andrew U. Frank > >>> +43 1 58801 12710 direct > >>> Geoinformation, TU Wien +43 1 58801 12700 office > >>> Gusshausstr. 27-29 +43 1 55801 12799 fax > >>> 1040 Wien Austria +43 676 419 25 72 mobil > >>> > >>> > >>> > >> > > >