Hi Tony,

Yes, I understood this was a different question. My point is that your example of what output you need seems to be pretty close to the basic writer with no expansion of linked resources at all and the only obvious difference being the in-lining of types. Taking the basic writer and adding type in-lining would be a much easier job than extending the ABBREV writer.

For controlling the the ABBREV writer expansions I think there is only the blockRules (can't check, site is down for me from here) and it sounded like you had tried all of those already.

Understood that you have found some thrashing behaviour which may be a bug. It is certainly very possible to get exponential slow down when dealing with these very circular structures. I'm not aware of that being reported before for ABBREV but then I hardly ever come across RDF/XML these days :)

Dave

On 17/11/14 15:36, Hammond, Tony wrote:
Hi Dave:

Actually this is a different problem from my initial query (which was
indeed about multiple typed nodes and selecting a preferred form - we'll
take that one away).

This is a completely separate issue and relates to the way that the
RDF/XML-ABBREV serializer works.

As noted we have encountered a problem where because of the inline
expansion of object nodes on first sight then when we have both
skos:broader AND skos:narrower terms we seem to experience some kind of
thrashing behaviour. The serialization does not execute in any acceptable
time (with 90 mins being on the steep side).

So, it seems (to us, at least) that the serializer is broken.

Removing the skos:narrower terms we do have acceptable serialization times
- but we still don't know if it's possible to control the node expansions.
Am assuming not.

Cheers,

Tony




On 17/11/2014 15:21, "Dave Reynolds" <[email protected]> wrote:

Hi Tony,

If what you actually need is the basic writer plus in-lining of
(selected) RDF types then you could consider developing your own.
If I recall correctly the RDF/XML basic (non-ABBREV) writer is actually
very simple and easy to specialize by inheritance. Then you could
contribute your extended writer back to the project.

Dave


On 17/11/14 15:03, Hammond, Tony wrote:
Hi Martynas:

We want the RDF/XML-ABBREV format for RDF typed nodes.

We'd prefer not getting inline expansion as the XML is then more regular
and easier to query with XML tooling. (For the use case see our ISWC
2014
presentation here [1]. We're modelling in RDF and querying in XML. We're
chasing single-digit millisecond structured responses.)

As also noted in my post for *some* reason there we have a MAJOR problem
with the RDF/XML-ABBREV format when we have both skos:broader and
skos:narrower terms.

Yes, we could resort to XSLT afterwards but this means a lot of
additional
work which we would prefer to avoid. There would also be a maintenance
issue here.

The Jena RDF/XML-ABBREV output is good - but not good enough. We don't
know why we can't control it better.

Cheers,

Tony


[1]
http://www.slideshare.net/tonyh/iswc-2014hammondpasinpresentationfinal



On 17/11/2014 14:45, "Martynas Jusevičius" <[email protected]>
wrote:

So what is the difference between Jena's RDF/XML and Rapper's RDF/XML?
The only thing I can see that Rapper inlines RDF type and Jena uses
rdf:Description. That can be easily fixed using XML tools such as
XSLT.

The question is, why do you need such specific output?

On Mon, Nov 17, 2014 at 3:39 PM, Hammond, Tony
<[email protected]> wrote:
Hi Martynas:

As said:

The basic RDF/XML output from Jena is not what we need. We just need
a
better, more regular, RDF/XML-ABBREV such as the rapper output.


Cheers,

Tony



On 17/11/2014 14:35, "Martynas Jusevičius" <[email protected]>
wrote:

Tony,

have you tried dropping the -ABBREV and simply using RDF/XML?


Martynas
graphityhq.com

On Mon, Nov 17, 2014 at 3:26 PM, Hammond, Tony
<[email protected]> wrote:
Hi:

I've got another couple questions about RDF/XML-ABBREV format.

When using the RDF/XML-ABBREV serializer to output a pretty-printed
graph on our subject taxonomy but we get object nodes expanded
inline
on
their first mention. See example output below [1] where I've shown
only
the URI references for convenience and suppressed the literal
properties.

This makes for a very uneven XML. (I know that the RDF is fine
though.
But we want some regular XML.)

Also, and much more importantly, if we add in skos:narrower links
this
then creates some kind of pathological behaviour and the
serialization
then takes some **90 mins** or more instead of  seconds or less.
(The
graph size is about 90,000 triples with ~3,000 subjects.)

We wanted to know if there was any way to suppress node expansion in
the Jena RDF/XML-ABBREV output as we'd really like to use Java for
portability in our build workflows.

We tried various "blockRules" property combinations to control the
RDF/XML output but to no avail - see Scala code here.

==
      val out = new FileOutputStream(file)
      try {
        // model.write(out, format )

        val writer = model.getWriter(format);
        if (format.equals("RDF/XML-ABBREV")) {
           writer.setProperty("blockRules", "propertyAttr");
         }
        writer.write(model, out, null);
      } finally {
        out.close()
      }
==

However, if we output the same graph in TURTLE and then use an
external
tool - the Redland rapper utility which also supports
RDF/XML-ABBREV -
we get the very regular (and decidedly pretty) flat RDF/XML output
as
shown in [2].

Is there any way we can control this expansion better in Jena or do
we
need to use an external tool like rapper?

The basic RDF/XML output from Jena is not what we need. We just
need a
better, more regular, RDF/XML-ABBREV such as the rapper output.

Thanks,

Tony

[1]
   <npg:Subject
rdf:about="http://ns.nature.com/subjects/periodontitis";>
      <skos:broader>
        <npg:Subject
rdf:about="http://ns.nature.com/subjects/periodontics";>
          <skos:broader>
            <npg:Subject
rdf:about="http://ns.nature.com/subjects/dentistry";>
              <skos:broader>
                <npg:Subject
rdf:about="http://ns.nature.com/subjects/health-care";>
                  <skos:related>
                    <npg:Subject
rdf:about="http://ns.nature.com/subjects/health-services";>
                      <skos:broader
rdf:resource="http://ns.nature.com/subjects/health-care"/>
                    </npg:Subject>
                  </skos:related>
                  <skos:related>
                    </npg:Subject>
                  </skos:related>
                </npg:Subject>
              </skos:broader>
            </npg:Subject>
          </skos:broader>
        </npg:Subject>
      </skos:broader>
      <skos:broader>
        <npg:Subject
rdf:about="http://ns.nature.com/subjects/oral-diseases";>
          <skos:broader>
              <skos:broader
rdf:resource="http://ns.nature.com/subjects/health-sciences"/>
            </npg:Subject>
          </skos:broader>
        </npg:Subject>
      </skos:broader>
    </npg:Subject>

   [2]
    <npg:Subject
rdf:about="http://ns.nature.com/subjects/periodontitis";>
      <skos:broader
rdf:resource="http://ns.nature.com/subjects/oral-diseases"/>
      <skos:broader
rdf:resource="http://ns.nature.com/subjects/periodontics"/>
    </npg:Subject>
    <npg:Subject
rdf:about="http://ns.nature.com/subjects/oral-diseases";>
       ...
    </npg:Subject>
    <npg:Subject
rdf:about="http://ns.nature.com/subjects/periodontics";>
       ...
    </npg:Subject>



*********************************************************************
**
**
*******
DISCLAIMER: This e-mail is confidential and should not be used by
anyone who is
not the original intended recipient. If you have received this
e-mail
in error
please inform the sender and delete it from your mailbox or any
other
storage
mechanism. Neither Macmillan Publishers Limited nor any of its
agents
accept
liability for any statements made which are clearly the sender's own
and not
expressly made on behalf of Macmillan Publishers Limited or one of
its
agents.
Please note that neither Macmillan Publishers Limited nor any of its
agents
accept any responsibility for viruses that may be contained in this
e-mail or
its attachments and it is your responsibility to scan the e-mail and
attachments (if any). No contracts may be concluded on behalf of
Macmillan
Publishers Limited or its agents by means of e-mail communication.
Macmillan
Publishers Limited Registered in England and Wales with registered
number 785998
Registered Office Brunel Road, Houndmills, Basingstoke RG21 6XS


*********************************************************************
**
**
*******




***********************************************************************
**
*******
DISCLAIMER: This e-mail is confidential and should not be used by
anyone who is
not the original intended recipient. If you have received this e-mail
in error
please inform the sender and delete it from your mailbox or any other
storage
mechanism. Neither Macmillan Publishers Limited nor any of its agents
accept
liability for any statements made which are clearly the sender's own
and not
expressly made on behalf of Macmillan Publishers Limited or one of its
agents.
Please note that neither Macmillan Publishers Limited nor any of its
agents
accept any responsibility for viruses that may be contained in this
e-mail or
its attachments and it is your responsibility to scan the e-mail and
attachments (if any). No contracts may be concluded on behalf of
Macmillan
Publishers Limited or its agents by means of e-mail communication.
Macmillan
Publishers Limited Registered in England and Wales with registered
number 785998
Registered Office Brunel Road, Houndmills, Basingstoke RG21 6XS


***********************************************************************
**
*******




*************************************************************************
*******
DISCLAIMER: This e-mail is confidential and should not be used by
anyone who is
not the original intended recipient. If you have received this e-mail
in error
please inform the sender and delete it from your mailbox or any other
storage
mechanism. Neither Macmillan Publishers Limited nor any of its agents
accept
liability for any statements made which are clearly the sender's own
and not
expressly made on behalf of Macmillan Publishers Limited or one of its
agents.
Please note that neither Macmillan Publishers Limited nor any of its
agents
accept any responsibility for viruses that may be contained in this
e-mail or
its attachments and it is your responsibility to scan the e-mail and
attachments (if any). No contracts may be concluded on behalf of
Macmillan
Publishers Limited or its agents by means of e-mail communication.
Macmillan
Publishers Limited Registered in England and Wales with registered
number 785998
Registered Office Brunel Road, Houndmills, Basingstoke RG21 6XS

*************************************************************************
*******



********************************************************************************
DISCLAIMER: This e-mail is confidential and should not be used by anyone who is
not the original intended recipient. If you have received this e-mail in error
please inform the sender and delete it from your mailbox or any other storage
mechanism. Neither Macmillan Publishers Limited nor any of its agents accept
liability for any statements made which are clearly the sender's own and not
expressly made on behalf of Macmillan Publishers Limited or one of its agents.
Please note that neither Macmillan Publishers Limited nor any of its agents
accept any responsibility for viruses that may be contained in this e-mail or
its attachments and it is your responsibility to scan the e-mail and
attachments (if any). No contracts may be concluded on behalf of Macmillan
Publishers Limited or its agents by means of e-mail communication. Macmillan
Publishers Limited Registered in England and Wales with registered number 785998
Registered Office Brunel Road, Houndmills, Basingstoke RG21 6XS
********************************************************************************

Reply via email to