Agree that the various Literal conversion could be useful for anyone using Commons RDF, but it should be better provided as some kind of LiteralUtils -- mirroring BeanUtils etc. in Apache Commons. Would that live in its own module, e.g. commonsrdf-utils ?
On 24 March 2016 at 19:56, Andy Seaborne <[email protected]> wrote: > > > > > On 01/03/16 23:06, Paul Houle wrote: >> >> Personally I am not at all happy with representing literals solely as the >> direct product of a value and a type. >> >> The first problem is performance. When I talk with the various burnouts >> and refugees from the semantic web one of the things I hear the most about >> is the "RDF Tax"; performance wise we can't afford to go through this >> serialization-deserialization every time we move data from one rdf toolset >> to another. > > > Moving between toolkits - or rather working with more than one toolkit at > once, is an import feature for commonsrdf, otherwise it is just another > toolkit, which, for me at least, would make it rather less interesting. > > Your proposal is to add to the literal interface with operations such as: > > Literal.asBigInteger > Literal.asLong > and others to match the XSD atomic types together with createLiteralDynamic > for the value to term direction. > > If this were done as a function: > > SomeLib.asBigInteger(Literal) > > then there is opportunities for caching. > > Either avoids serializing and de-serializing. > >> The other one is correctness. If you don't have a "standard library" for >> parsing and unparsing dates people are going to screw it up over and over >> again. For me the whole point of having RDF is going frictionless: once >> data goes to RDF it stays RDF -- I don't need to write different tools to >> deal with JSON, XML, spreadsheets all of which are ill-formed to some >> extent or another. > > > Java has XMLGregorianCalendar > > In Literal.asTemporal like all the as* doesn't check the datatype and are > only working on the lexical form. > > Again - would this be better as a library? It is after all casting, in the > same way SPARQL has cast like xsd:integer("string") > > What I'm wondering is whether there is a basic requirement to out these in > the Literal interface or not. > >> >> If it is easier to screw up dates than get them right you are losing most >> of the benefits of RDF and you are back in the same awful world of data >> integration with awk, sed and microsoft excel that everybody else is in >> and >> now RDF is just another source of problems rather than of solutions. >> >> The code at my fork here >> >> https://github.com/paulhoule/incubator-commonsrdf >> >> frankly does suck, but I have yet to have seen a real evaluation of the >> ideas here, but it comes down to four things: >> >> (i) you can implement the string [x] string interface for literals >> (ii) you can also pass literals around in java object form (Integer, >> LocalDateTime, etc.) >> (iii) if you don't implement (ii) default methods will give you correct >> serialization and deserialization of literal values >> (iv) the code is ergonomic for the end user. > > > The other thing you have is the RDF interface whereby all RDFTerms return > the RDFactory (RDFContext) used to make them. > > Could you say more about this? > > Andy > > >> >> ---- >> >> Bigger picture, however, I have been thinking about a few other things: >> >> * a DSL that uses static imports to reduce the size of Jena client code >> considerably (these days I think the biggest difference between Java and >> Python is the attitude of the communities towards static imports) >> * from another perspective at the low level (objects that reflect the >> structure of RDF) you could say that performance is not everything, it is >> the only thing. That points towards some system that uses plain objects >> as >> literals, not out of any kind of ideology, but to avoid senseless >> allocation of objects. >> >> What I have been working on over the last few months is a system that is >> getting a bit complex and I am starting to transition away from the >> "manipulate rdf data with rdf operators" paradigm towards a "serialize and >> deserialize compound objects into RDF". I found myself writing a lot of >> awkward and error prone code to do that serialization and deserialization. >> >> >> On Tue, Mar 1, 2016 at 5:41 PM, Lewis John Mcgibbney < >> [email protected]> wrote: >> >>> LOL Stian >>> >>> :) >>> >>> On Tue, Mar 1, 2016 at 2:39 PM, < >>> [email protected]> wrote: >>> >>>> ---------- Forwarded message ---------- >>>> From: Stian Soiland-Reyes <[email protected]> >>>> To: dev <[email protected]> >>>> Cc: >>>> Date: Tue, 1 Mar 2016 22:39:31 +0000 >>>> Subject: Re: March 2016 Report >>>> +1 :-)) >>>> >>>> Although this is starting to sound like my EU projects.. do we need >>>> User Stories and Personas? :) >>>> >>>> >>> >> >> >> > -- Stian Soiland-Reyes Apache Taverna (incubating), Apache Commons RDF (incubating) http://orcid.org/0000-0001-9842-9718
