Re: RDF Patch - experiences suggesting changes

orms without "R" was negligible (~ 0.1%, a bit higher with no prefixes). It also means you can't process the RDF Patch in a parallel way without preprocessing. (Same for prefixes). Using "R" could also restrict possible compression pattern, for instance in : A &l

Re: RDF Patch - experiences suggesting changes

s without "R" was negligible (~ 0.1%, a bit higher with no prefixes). It also means you can't process the RDF Patch in a parallel way without preprocessing. (Same for prefixes). Using "R" could also restrict possible compression pattern, for instance in :

Re: RDF Patch - experiences suggesting changes

I had a quick go, and the penalty from gzip with using expanded forms without "R" was negligible (~ 0.1%, a bit higher with no prefixes). It also means you can't process the RDF Patch in a parallel way without preprocessing. (Same for prefixes). Using "R" could also restrict

Re: RDF Patch - experiences suggesting changes

Yes but ANY is a form of lossy compression. You lost the actual details of what was removed. Also it can only be used for removals and yields no benefit for additions. On the other hand REPEAT is lossless compression. However if you apply a general-purpose compression like gzip on top of the

Re: RDF Patch - experiences suggesting changes

On 14/10/2016 17:09, "Andy Seaborne" wrote: I don't understand what capabilities are enabled by transaction granularity if there are multiple transactions in a single patch. Concrete examples of where it helps? However, I've normally been working with one

Re: RDF Patch - experiences suggesting changes

On 14/10/16 11:59, A. Soroka wrote: ... 6/ Packets of change. To have 4 (label a patch with reversible) and 5 (the version details), there needs to be somewhere to put the information. Having it in the patch itself means that the whole unit can be stored in a file. If it is in the

Re: CMS diff: Writing RDF in Apache Jena

Checked http://jena.staging.apache.org/documentation/io/rdf-output#json-ld, and the tables look all right to me. Could you confirm what is wrong in the formatting? Was it supposed to be a striped table perhaps? Not a CSS experct but happy to try to help :) B

Re: CMS diff: Writing RDF in Apache Jena

, fpservant wrote: Clone URL (Committers only): https://cms.apache.org/redirect?new=anonymous;action=diff;uri=http://jena.apache.org/documentation%2Fio%2Frdf-output.mdtext fpservant Index: trunk/content/documentation/io/rdf-output.mdtext

CMS diff: Writing RDF in Apache Jena

Clone URL (Committers only): https://cms.apache.org/redirect?new=anonymous;action=diff;uri=http://jena.apache.org/documentation%2Fio%2Frdf-output.mdtext fpservant Index: trunk/content/documentation/io/rdf-output.mdtext === --- trunk

Re: RDF Patch - experiences suggesting changes

..@seaborne.org> wrote: I've been using modified RDF Patch for the data exchanged to keep multiple datasets synchronized. My primary use case is having multiple copies of the datasets for a high availability solution. It has to be a general solution for any data. There are some changes

Re: RDF Patch - experiences suggesting changes

Rob On 13/10/2016 16:32, "Andy Seaborne" <andy.seabo...@gmail.com on behalf of a...@seaborne.org> wrote: I've been using modified RDF Patch for the data exchanged to keep multiple datasets synchronized. My primary use case is having multiple copies of the dat

Re: RDF Patch - experiences suggesting changes

On 14/10/16 12:09, A. Soroka wrote: +1 to ANY, because it offers the potential to actually remove lines from a patch. For example, removing a whole graph could shrink pretty rapidly. But just to be clear, ANY would seem to be illegal inside a reversible patch, right? Yes. --- A. Soroka

Re: RDF Patch - experiences suggesting changes

14, 2016, at 5:34 AM, Andy Seaborne <a...@apache.org> wrote: > > Hi Paul, > > The general goal of RDF Patch is to be "assembler" for changes, or "N-Triples > for changes" - and there is no pattern matching capability. > > In your example yo

Re: RDF Patch - experiences suggesting changes

Thoughts in-line. (Incidentally, my immediate interest in RDF Patch is pretty similar; robustness via distribution, but there's also a smaller, more theoretical interest for me in automatically "shredding" or "sharding" datasets across networks for higher persistence

Re: RDF Patch - experiences suggesting changes

Hi Paul, The general goal of RDF Patch is to be "assembler" for changes, or "N-Triples for changes" - and there is no pattern matching capability. In your example you'd have to know the old value: TB QD <http://rdf.ontology2.com/henson/aws/Server> <http:/

Re: RDF Patch - experiences suggesting changes

There is another use case for an "RDF Patch" which applies to hand-written models. For instance I have a model which describes a job that is run in AWS that looks like @prefix : <http://rdf.ontology2.com/henson/aws/> @prefix parameter: <http://rdf.ontology2.com/henson/aws/p

RDF Patch - experiences suggesting changes

I've been using modified RDF Patch for the data exchanged to keep multiple datasets synchronized. My primary use case is having multiple copies of the datasets for a high availability solution. It has to be a general solution for any data. There are some changes to the format that this work

Re: CMS diff: An Introduction to RDF and the Jena RDF API

ontent/tutorials/rdf_api.mdtext === --- trunk/content/tutorials/rdf_api.mdtext (revision 1655891) +++ trunk/content/tutorials/rdf_api.mdtext (working copy) @@ -318,7 +318,7 @@ at how to interpret the above.

CMS diff: An Introduction to RDF and the Jena RDF API

/rdf_api.mdtext (revision 1655891) +++ trunk/content/tutorials/rdf_api.mdtext (working copy) @@ -318,7 +318,7 @@ at how to interpret the above. RDF is usually embedded in an rdf:RDF element. The element is -optional if there are other ways of know that some XML is RDF, but it is +optional

Re: Jena integration for Commons RDF (JENA-1015, COMMONSRDF-35)

Thanks! Here are some of the other Commons RDF topics that would be good to get feedback on: https://lists.apache.org/list.html?d...@commons.apache.org:lte=1M:%5BRDF%5D Some of these are design questions that would be good to clarify before we release API changes. On 29 September 2016 at 14

Re: Jena integration for Commons RDF (JENA-1015, COMMONSRDF-35)

Stian-- I will look at this today, but even beforehand, I want to volunteer to help in whatever way is useful to move this effort forward. I filed JENA-1015 because downstream projects on which I work would very much like to shift to Commons as their RDF underpinning. --- A. Soroka

Jena integration for Commons RDF (JENA-1015, COMMONSRDF-35)

I've proposed a "jena" integration module to Commons RDF, which I think we should try to release as part of Commons RDF 0.3.0 It's based on Andy's earlier integration on GitHub[1] (JENA-1015), but adds support for Dataset, Quad (and generalized quad!), RDFParser. The entry p

[jira] [Commented] (JENA-1233) Make RDF primitives Serializable

[ https://issues.apache.org/jira/browse/JENA-1233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15475305#comment-15475305 ] Itsuki Toyota commented on JENA-1233: - Thanks a lot! I'll try it later. > Make RDF primiti

[jira] [Commented] (JENA-1233) Make RDF primitives Serializable

. You can use wrapper objects - they would be nicer in scala. To make sure I understood serialization in detail I put together: https://gist.github.com/afs/01568ed6286eb0f6d4ac35e84fbcdbd6 which encodes, using RDF Thrift, for Node and Triple. Uses the machinery already in Jena. Includes example

[jira] [Commented] (JENA-1233) Make RDF primitives Serializable

rdd/RDD.scala#L1469 https://github.com/apache/spark/blob/v1.6.0/core/src/main/scala/org/apache/spark/util/Utils.scala#L79-L86 > Make RDF primitives Serializable > > > Key: JENA-1233 > URL: https://issues.apache.org/jir

[jira] [Commented] (JENA-1233) Make RDF primitives Serializable

serves because I don't think {{Writable}} extends {{Serializable}} I experimented a bit with RDF and spark using Elephas and ended up creating some Scala wrapper classes around the Elephas {{Writable}} implementations to make Spark happy. This is however all internal prototype code and not open

[jira] [Commented] (JENA-1233) Make RDF primitives Serializable

[ https://issues.apache.org/jira/browse/JENA-1233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15474241#comment-15474241 ] Andy Seaborne commented on JENA-1233: - If serializable is provided, then it could use RDF Thrift

[jira] [Commented] (JENA-1233) Make RDF primitives Serializable

[ https://issues.apache.org/jira/browse/JENA-1233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15474225#comment-15474225 ] Itsuki Toyota commented on JENA-1233: - > Triple, Node, Quad? Yes, I mean the these three. > Ma

[jira] [Commented] (JENA-1233) Make RDF primitives Serializable

is class-sensitive. > Make RDF primitives Serializable > > > Key: JENA-1233 > URL: https://issues.apache.org/jira/browse/JENA-1233 > Project: Apache Jena > Issue Type: Improvement >

[jira] [Commented] (JENA-1233) Make RDF primitives Serializable

Graph, DatasetGraph? > Make RDF primitives Serializable > > > Key: JENA-1233 > URL: https://issues.apache.org/jira/browse/JENA-1233 > Project: Apache Jena > Issue Type: Improvement

[jira] [Commented] (JENA-1233) Make RDF primitives Serializable

ess is the following 1) A Triple that includes blank nodes (i.e. RDD[Triple]) 2) A Node that is the blank node (i.e RDD[Node]) > Have you looked at jena-elephas? No, I haven't. > Make RDF primitives Serializable > > >

[jira] [Commented] (JENA-1233) Make RDF primitives Serializable

[ https://issues.apache.org/jira/browse/JENA-1233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15474177#comment-15474177 ] Paul Houle commented on JENA-1233: -- In theory the identity of blank nodes between different RDF graphs

[jira] [Commented] (JENA-1233) Make RDF primitives Serializable

[ https://issues.apache.org/jira/browse/JENA-1233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15474145#comment-15474145 ] Andy Seaborne commented on JENA-1233: - Which objects? Have you looked at jena-elephas? > Make

[jira] [Commented] (JENA-1233) Make RDF primitives Serializable

a problem with its lifecycle rather than its interface, and it potentially has a problem using as a RDD-wrapped object in Apache Spark ? > Make RDF primitives Serializable > > > Key: JENA-1233 > URL: https://issues.

[jira] [Comment Edited] (JENA-1233) Make RDF primitives Serializable

lifecycle rather than its interface, and it potentially has a problem using as a RDD-wrapped object in Apache Spark ? > Make RDF primitives Serializable > > > Key: JENA-1233 > URL: https://issues.apache.org/jira/b

[jira] [Commented] (JENA-1233) Make RDF primitives Serializable

have a scope that doesn't particularly coincide with any Java-specified lifecycle. > Make RDF primitives Serializable > > > Key: JENA-1233 > URL: https://issues.apache.org/jira/browse/JENA-1233 > Pr

[jira] [Created] (JENA-1233) Make RDF primitives Serializable

Itsuki Toyota created JENA-1233: --- Summary: Make RDF primitives Serializable Key: JENA-1233 URL: https://issues.apache.org/jira/browse/JENA-1233 Project: Apache Jena Issue Type: Improvement

[jira] [Comment Edited] (JENA-1015) Commons RDF module

to go on in the Commons RDF project itself, tracked at COMMONSRDF-33. was (Author: ajs6f): The work here is going to go on in the Commons RDF project itself. > Commons RDF module > -- > > Key: JENA-1015 > URL: https://issues.apache.

[jira] [Resolved] (JENA-1015) Commons RDF module

[ https://issues.apache.org/jira/browse/JENA-1015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] A. Soroka resolved JENA-1015. - Resolution: Information Provided The work here is going to go on in the Commons RDF project itself

[jira] [Commented] (JENA-1015) Commons RDF module

[ https://issues.apache.org/jira/browse/JENA-1015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15362848#comment-15362848 ] A. Soroka commented on JENA-1015: - I opened it, and I'm cool with that resolution. > Commons RDF mod

[jira] [Commented] (JENA-1015) Commons RDF module

vided"? > Commons RDF module > -- > > Key: JENA-1015 > URL: https://issues.apache.org/jira/browse/JENA-1015 > Project: Apache Jena > Issue Type: New Feature > Components: Jena >Repo

[jira] [Commented] (JENA-1015) Commons RDF module

> Commons RDF module > -- > > Key: JENA-1015 > URL: https://issues.apache.org/jira/browse/JENA-1015 > Project: Apache Jena > Issue Type: New Feature > Components: Jena >Reporter: A. S

[jira] [Commented] (JENA-1015) Commons RDF module

[ https://issues.apache.org/jira/browse/JENA-1015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15361648#comment-15361648 ] A. Soroka commented on JENA-1015: - [~stain] is moving [~andy.seaborne]'s contribution to Commons RDF

Re: Commons RDF (was: Jena core vs. extensions?)

support inhttps://github.com/stain/commonsrdf-parser-jena - but I've >> not submitted this to Commons RDF yet; as Andy's code was not >> formally contributed to ASF I didn't want to do this on his behalf. I >> had considered to do a "clean room" approach - but of course m

Commons RDF (was: Jena core vs. extensions?)

On 02/07/16 01:23, Stian Soiland-Reyes wrote: I think Andy's approach is great, I have extended it with parser support inhttps://github.com/stain/commonsrdf-parser-jena - but I've not submitted this to Commons RDF yet; as Andy's code was not formally contributed to ASF I didn't want to do

[jira] [Updated] (JENA-1015) Commons RDF module

. > Commons RDF module > -- > > Key: JENA-1015 > URL: https://issues.apache.org/jira/browse/JENA-1015 > Project: Apache Jena > Issue Type: New Feature > Components: Jena >

[jira] [Comment Edited] (JENA-1015) Commons RDF module

uthor: andy.seaborne): There is a useful bigger discussion here that would be better on dev@. How can we have a core set of modules (base to Fuseki maybe) and some other modules that range from "additional" to "experimental" while at the same time getting into

[jira] [Commented] (JENA-1015) Commons RDF module

on dev@. How can we have a core set of modules (base to Fuseki maybe) and some other modules that range from "additional" to "experimental" while at the same time getting into release overhead. > Commons RDF module > -- > > Key:

[jira] [Commented] (JENA-1015) Commons RDF module

? [~stain], do you think Commons RDF would be interested in hosting a semi-official Jena impl? That would take the burden away from Jena itself. > Commons RDF module > -- > > Key: JENA-1015 > URL: https://issues.apache.org/jira/b

[jira] [Updated] (JENA-1183) Fuseki is not robust to unwritable RDF/XML

[ https://issues.apache.org/jira/browse/JENA-1183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Seaborne updated JENA-1183: Description: Some RDF graph can not be written in RDF/XML. An example is if a property of {{rdf:li

[jira] [Resolved] (JENA-1183) Fuseki is not robust to unwritable RDF/XML

eki is not robust to unwritable RDF/XML > -- > > Key: JENA-1183 > URL: https://issues.apache.org/jira/browse/JENA-1183 > Project: Apache Jena > Issue Type: Bug >

[jira] [Commented] (JENA-1183) Fuseki is not robust to unwritable RDF/XML

86974d3d922f664413f17e37dd968de55afdea96 in jena's branch refs/heads/master from [~andy.seaborne] [ https://git-wip-us.apache.org/repos/asf?p=jena.git;h=86974d3 ] JENA-1183: Protect against problems writing RDF (esp RDF/XML) > Fuseki is not robust to unwritable RDF/

[jira] [Created] (JENA-1183) Fuseki is not robust to unwritable RDF/XML

Andy Seaborne created JENA-1183: --- Summary: Fuseki is not robust to unwritable RDF/XML Key: JENA-1183 URL: https://issues.apache.org/jira/browse/JENA-1183 Project: Apache Jena Issue Type

[jira] [Updated] (JENA-1183) Fuseki is not robust to unwritable RDF/XML

[ https://issues.apache.org/jira/browse/JENA-1183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Seaborne updated JENA-1183: Priority: Minor (was: Major) > Fuseki is not robust to unwritable RDF/

[jira] [Updated] (JENA-1183) Fuseki is not robust to unwritable RDF/XML

[ https://issues.apache.org/jira/browse/JENA-1183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Seaborne updated JENA-1183: Issue Type: Bug (was: Dependency upgrade) > Fuseki is not robust to unwritable RDF/

Re: CMS diff: Reading RDF in Apache Jena

Fixed - thanks. On 29/04/16 08:25, Tom Saleeba wrote: Clone URL (Committers only): https://cms.apache.org/redirect?new=anonymous;action=diff;uri=http://jena.apache.org/documentation%2Fio%2Frdf-input.mdtext Tom Saleeba Index: trunk/content/documentation/io/rdf-input.mdtext

CMS diff: Reading RDF in Apache Jena

Clone URL (Committers only): https://cms.apache.org/redirect?new=anonymous;action=diff;uri=http://jena.apache.org/documentation%2Fio%2Frdf-input.mdtext Tom Saleeba Index: trunk/content/documentation/io/rdf-input.mdtext === --- trunk

CMS diff: An Introduction to RDF and the Jena RDF API

Clone URL (Committers only): https://cms.apache.org/redirect?new=anonymous;action=diff;uri=http://jena.apache.org/tutorials%2Frdf_api.mdtext Niels Andersen Index: trunk/content/tutorials/rdf_api.mdtext === ---

[jira] [Closed] (JENA-624) Develop a new in-memory RDF Dataset implementation

[ https://issues.apache.org/jira/browse/JENA-624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Seaborne closed JENA-624. -- > Develop a new in-memory RDF Dataset implementat

[jira] [Resolved] (JENA-624) Develop a new in-memory RDF Dataset implementation

ory RDF Dataset implementation > -- > > Key: JENA-624 > URL: https://issues.apache.org/jira/browse/JENA-624 > Project: Apache Jena > Issue Type: Improvement >

[jira] [Updated] (JENA-1140) Jena 3.0.1 model halts reading large rdf file partway through

[ https://issues.apache.org/jira/browse/JENA-1140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Seaborne updated JENA-1140: Attachment: data-500K.nt.gz Data extract. > Jena 3.0.1 model halts reading large rdf file part

[jira] [Commented] (JENA-1140) Jena 3.0.1 model halts reading large rdf file partway through

s/xsd/AbstractDateTime.java]) CY=0, h=, M, m, D, s ). The key is that, for example, m and s are 2 slot hashs apart i.e. "<<4" when the "<<2" is used. Using the Eclipse generated hashCode works just as

[jira] [Comment Edited] (JENA-1140) Jena 3.0.1 model halts reading large rdf file partway through

key is that, for example, m and s are 2 slot hashs apart i.e. "<<4" when the "<<2" is used. Using the Eclipse generated hashCode works just as well and is probably better researched. This is the fixed committed. > Jena 3.0.1 model halts reading large rdf fil

[jira] [Commented] (JENA-1140) Jena 3.0.1 model halts reading large rdf file partway through

8c475680b3d85520e41b7eb78418e9514fb85eef in jena's branch refs/heads/master from [~andy.seaborne] [ https://git-wip-us.apache.org/repos/asf?p=jena.git;h=8c47568 ] JENA-1140: Better hash code for AbstractDateTime. > Jena 3.0.1 model halts reading large rdf file partway thro

[jira] [Resolved] (JENA-1140) Jena 3.0.1 model halts reading large rdf file partway through

ena 3.0.1 model halts reading large rdf file partway through > - > > Key: JENA-1140 > URL: https://issues.apache.org/jira/browse/JENA-1140 > Project: Apache Jena >

[jira] [Updated] (JENA-1140) Jena 3.0.1 model halts reading large rdf file partway through

[ https://issues.apache.org/jira/browse/JENA-1140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Seaborne updated JENA-1140: Priority: Critical (was: Major) > Jena 3.0.1 model halts reading large rdf file partway thro

[jira] [Assigned] (JENA-1140) Jena 3.0.1 model halts reading large rdf file partway through

[ https://issues.apache.org/jira/browse/JENA-1140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Seaborne reassigned JENA-1140: --- Assignee: Andy Seaborne > Jena 3.0.1 model halts reading large rdf file partway thro

[jira] [Commented] (JENA-1140) Jena 3.0.1 model halts reading large rdf file partway through

ade between 2.13.0 and 3.0.0. > Jena 3.0.1 model halts reading large rdf file partway through > - > > Key: JENA-1140 > URL: https://issues.apache.org/jira/browse/JENA-1140 >

[jira] [Commented] (JENA-1140) Jena 3.0.1 model halts reading large rdf file partway through

the additional time is going. It may be HashCommon.findSlot, it may be XSDDatatype.equals or it may be the quality of the hash code. > Jena 3.0.1 model halts reading large rdf file partway through > - > > Ke

[jira] [Updated] (JENA-1140) Jena 3.0.1 model halts reading large rdf file partway through

[ https://issues.apache.org/jira/browse/JENA-1140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Seaborne updated JENA-1140: Priority: Major (was: Critical) > Jena 3.0.1 model halts reading large rdf file partway thro

[jira] [Created] (JENA-1140) Jena 3.0.1 model halts reading large rdf file partway through

Håvard Wanvik Stenersen created JENA-1140: - Summary: Jena 3.0.1 model halts reading large rdf file partway through Key: JENA-1140 URL: https://issues.apache.org/jira/browse/JENA-1140 Project

[jira] [Closed] (JENA-8) Possibly plausible example of loading RDF/OWL into TDB and querying it fails

[ https://issues.apache.org/jira/browse/JENA-8?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Seaborne closed JENA-8. > Possibly plausible example of loading RDF/OWL into TDB and querying it fa

[jira] [Closed] (JENA-815) RDF XML Literals

[ https://issues.apache.org/jira/browse/JENA-815?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Seaborne closed JENA-815. -- > RDF XML Literals > > > Key: JENA-815 >

[jira] [Commented] (JENA-624) Develop a new in-memory RDF Dataset implementation

and concision I want to do when the time is right (e.g. bringing the {{find}} methods up into {{TupleTable}} by using varargs) but I have nothing useful to add to what's there now in terms of getting stuff in front of people. > Develop a new in-memory RDF Dataset implementat

[jira] [Commented] (JENA-624) Develop a new in-memory RDF Dataset implementation

new JIRA as needed. > Develop a new in-memory RDF Dataset implementation > -- > > Key: JENA-624 > URL: https://issues.apache.org/jira/browse/JENA-624 > Project: Apache Jena >

[jira] [Commented] (JENA-624) Develop a new in-memory RDF Dataset implementation

of {{isInTransaction}} in a {{TupleTable}} is inside a check made by {{DatasetGraphInMemory}} of its {{isInTransaction}}. > Develop a new in-memory RDF Dataset implementation > -- > > Key: JENA-624 >

[jira] [Commented] (JENA-624) Develop a new in-memory RDF Dataset implementation

it, no? {grin} The installation of {{ThreadLocal::remove}} calls should address any immediate problems, right? > Develop a new in-memory RDF Dataset implementation > -- > > Key: JENA-624 > URL: https://is

[jira] [Comment Edited] (JENA-624) Develop a new in-memory RDF Dataset implementation

an {{isInTransaction}} {{ThreadLocal}} to {{false}}, I should {{remove}} it? If so, [here:=|https://github.com/apache/jena/pull/104] is a PR for that. > Develop a new in-memory RDF Dataset implementation > -- > > K

[jira] [Comment Edited] (JENA-624) Develop a new in-memory RDF Dataset implementation

an {{isInTransaction}} {{ThreadLocal}} to {{false}}, I should {{remove}} it? > Develop a new in-memory RDF Dataset implementation > -- > > Key: JENA-624 > URL: https://issues.apache.org/jira/

[jira] [Commented] (JENA-624) Develop a new in-memory RDF Dataset implementation

://github.com/apache/jena/pull/103 > Develop a new in-memory RDF Dataset implementation > -- > > Key: JENA-624 > URL: https://issues.apache.org/jira/browse/JENA-624 > Project: Apache Jena >

[jira] [Commented] (JENA-624) Develop a new in-memory RDF Dataset implementation

}} which has it's own {{isInTransaction}}. {{TupleTable}} can inherit {{Transactional}} for the interface operations and does not imply that the internal units of {{HexTable}} or {{TriTable}} have to check again. > Develop a new in-memory RDF Dataset implementat

[jira] [Commented] (JENA-624) Develop a new in-memory RDF Dataset implementation

of {{TupleTable}}. > Develop a new in-memory RDF Dataset implementation > -- > > Key: JENA-624 > URL: https://issues.apache.org/jira/browse/JENA-624 > Project: Apache Jena > Is

[jira] [Updated] (JENA-1077) sparql-results+xml : (RDF 1.1) wrongly output includes datatypes for rdf:langString and xsd:string.

.org/2001/XMLSchema#> :s1 :p "langtag"@en . :s2 :p "simple string" . :s3 :p "datatype string"^^xsd:string . :s4 :p "not a string"^^xsd:anything . {noformat} Output RDF.1.1 : {noformat} http://www.w3.org/2001/XMLSchema#string;>simple string http://www.w3

[jira] [Updated] (JENA-1077) sparql-results+xml : (RDF 1.1) wrongly output includes datatypes for rdf:langString and xsd:string.

.org/2001/XMLSchema#> :s1 :p "langtag"@en . :s2 :p "simple string" . :s3 :p "datatype string"^^xsd:string . :s4 :p "not a string"^^xsd:anything . {noformat} Output Jena 3.0.0, abbreviated: {noformat} http://www.w3.org/2001/XMLSchema#string;>simple string

[jira] [Updated] (JENA-1077) sparql-results+xml : (RDF 1.1) wrongly output includes datatypes for rdf:langString and xsd:string.

:p "datatype string"^^xsd:string . :s4 :p "not a string"^^xsd:anything . {noformat} Output RDF.1.1 : {noformat} http://www.w3.org/2001/XMLSchema#anything;>not a string datatype string simple string langtag {noformat} using the RDF 1.1 guidance that {{rdf:lang

[jira] [Resolved] (JENA-1077) sparql-results+xml : (RDF 1.1) wrongly output includes datatypes for rdf:langString and xsd:string.

[ https://issues.apache.org/jira/browse/JENA-1077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Seaborne resolved JENA-1077. - Resolution: Fixed Fix Version/s: Jena 3.0.1 > sparql-results+xml : (RDF 1.1) wrongly out

[jira] [Updated] (JENA-1077) sparql-results+xml : (RDF 1.1) wrongly output includes datatypes for rdf:langString and xsd:string.

.org/2001/XMLSchema#> :s1 :p "langtag"@en . :s2 :p "simple string" . :s3 :p "datatype string"^^xsd:string . :s4 :p "not a string"^^xsd:anything . {noformat} {noformat} {noformat} was: {noformat} {noformat} > sparql-results+xml : (RDF 1.1)

[jira] [Commented] (JENA-1077) sparql-results+xml : (RDF 1.1) wrongly output includes datatypes for rdf:langString and xsd:string.

c83f234bc33f858cb613014962400df5c46536ac in jena's branch refs/heads/master from [~andy.seaborne] [ https://git-wip-us.apache.org/repos/asf?p=jena.git;h=c83f234 ] JENA-1077: No datatype for langString nor xsd:string. > sparql-results+xml : (RDF 1.1) wrongly output includes datatypes for > rdf:lang

[jira] [Updated] (JENA-1077) sparql-results+xml : (RDF 1.1) wrongly output includes datatypes for rdf:langString and xsd:string.

[ https://issues.apache.org/jira/browse/JENA-1077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Seaborne updated JENA-1077: Description: {noformat} {noformat} > sparql-results+xml : (RDF 1.1) wrongly output inclu

[jira] [Updated] (JENA-1077) sparql-results+xml : (RDF 1.1) wrongly output includes datatypes for rdf:langString and xsd:string.

ta: {noformat} PREFIX : <http://example/> PREFIX xsd: <http://www.w3.org/2001/XMLSchema#> :s1 :p "langtag"@en . :s2 :p "simple string" . :s3 :p "datatype string"^^xsd:string . :s4 :p "not a string"^^xsd:anything . {noformat} {noformat}

[jira] [Commented] (JENA-624) Develop a new in-memory RDF Dataset implementation

new in-memory RDF Dataset implementation > -- > > Key: JENA-624 > URL: https://issues.apache.org/jira/browse/JENA-624 > Project: Apache Jena > Issue Type: Improvement >

[jira] [Commented] (JENA-624) Develop a new in-memory RDF Dataset implementation

(); isInTransaction(false); transactionType(null); getLock().leaveCriticalSection(); } {noformat} > Develop a new in-memory RDF Dataset implementation > -- > > Key: JENA-624 > URL: https://issues.

[jira] [Commented] (JENA-624) Develop a new in-memory RDF Dataset implementation

. > Develop a new in-memory RDF Dataset implementation > -- > > Key: JENA-624 > URL: https://issues.apache.org/jira/browse/JENA-624 > Project: Apache Jena > Issue Type: Improvement

[jira] [Commented] (JENA-624) Develop a new in-memory RDF Dataset implementation

clearly don't understand the use of {{getLock}} yet. I'll take a look at how it used in the rules system to try and understand better. > Develop a new in-memory RDF Dataset implementation > -- > > Key: JENA-624 >

[jira] [Commented] (JENA-624) Develop a new in-memory RDF Dataset implementation

it until I have a chance to squash them. > Develop a new in-memory RDF Dataset implementation > -- > > Key: JENA-624 > URL: https://issues.apache.org/jira/browse/JENA-624 > Pr

[jira] [Commented] (JENA-624) Develop a new in-memory RDF Dataset implementation

}}. The others don't seem to add anything. All calls go via {{DatasetGraphInMemory}}. > Develop a new in-memory RDF Dataset implementation > -- > > Key: JENA-624 > URL: https://issues.apache.org/jira/

[jira] [Commented] (JENA-624) Develop a new in-memory RDF Dataset implementation

itself (e.g. the rules system) and MR+SW lets in situations that conflict with MRSW. > Develop a new in-memory RDF Dataset implementation > -- > > Key: JENA-624 > URL: https://issues.apache.org/jira/

[jira] [Commented] (JENA-624) Develop a new in-memory RDF Dataset implementation

}}. The others don't seem to add anything. All calls go via {{DatasetGraphInMemory}}. > Develop a new in-memory RDF Dataset implementation > -- > > Key: JENA-624 > URL: https://issues.apache.org/jira/

[jira] [Commented] (JENA-624) Develop a new in-memory RDF Dataset implementation

}} to provide for coupling tables together in the manner of {{HexTable}} or {{TriTable}}. So that's why {{isInTransaction}} is in the mix there. > Develop a new in-memory RDF Dataset implementation > -- > > K

[jira] [Commented] (JENA-624) Develop a new in-memory RDF Dataset implementation

in the fact of multi-thread transactions. That's a whole new frontier! :) > Develop a new in-memory RDF Dataset implementation > -- > > Key: JENA-624 > URL: https://issues.apache.org/jira/browse/JENA-624 >

<    1   2   3   4   5   6   7   8   9   >