Hello Peter,
thank you for sharing your thoughts as well as giving me some inside into the history of Commons RDF. Maybe my comment came over wrong. I didn't want to and probably will not tamper into the development of Commons RDF. I don't have the necessary knowledge about the field and I trust the people involved here to build something that truly is the common implementation of the RDF spec. 2015-04-01 1:45 GMT+02:00 Peter Ansell <[email protected]>: > Hi Benedikt, > > I agree that building an actual consensus, ie, full (~100%) consensus, > not just a democratic majority (>50%) consensus, could still be used > to change some of the stable aspects of the system. > That's probably what I was trying to say but expressed far more eloquently :-) Benedikt > However, in regard to some of the architecture choices, continuous > debate will not cause any change and may reduce the possible usage of > the resulting API if they are forced through. The sole use of > interfaces is one of those requirements for me. Sorry if that is > offensive, but we have already made hard and fast decisions about some > architectural principles during the last 12 months, which required a > lot of discussion already, and which Reto was privy to but chose not > to say anything about some of these issues until now. > To be a success across the widely varying communities that have > historically been very disjoint, we have to be consistent and make the > API as applicable as possible to all of the implementations, in > addition to using the published RDF-1.1 W3C Recommendation as our main > reference for technical aspects and the scope of the system. I.e., we > aren't planning on being fair to any particular implementation, we > would prefer to reduce the number of technical obstacles for all > theoretical implementations. > > In this case there is a clear technical obstacle which is added if we > change any of our interfaces to classes, and comparatively there is no > actual difference if we stay with interfaces, hence why we already > decided this issue in our initial phases and nothing except full > consensus will change that. > > Similarly with the other issue where an implementor has been lobbying > for their particular preference to be adopted, with regard to casing, > there is no current or near future technical obstacle to upper-cased > acronyms. We are only providing interfaces to override to give other > implementations a common reference for reusing their objects, not > class names that they would need to reuse internally. In addition, we > have a very limited scope intentionally in the hope of getting any of > the major implementations to use Commons RDF at all, so we do not > envisage any multi-acronym interface names even in the long term. > Hence, given that the status quo holds significant sway over any > alternative except full consensus, continued implementation specific > lobbying in the hope of scraping across the line to majority consensus > may be starting to turn some of the contributors and implementers > away. > > Cheers, > > Peter > > On 31 March 2015 at 19:20, Benedikt Ritter <[email protected]> wrote: > > 2015-03-30 23:40 GMT+02:00 Peter Ansell <[email protected]>: > > > >> The use of interfaces is a deliberate step to improve the usefulness > >> of the API by not mandating any particular implementation. We are not > >> going to change that. > >> > > > > ... unless the community builds consensus about such a change. > > > > > >> > >> I don't understand what makes a simple String a bad choice for > >> representing language tags. There are no other attributes that could > >> be attached to the string, per the BCP47 design to have all of the > >> information required in a simple string. In addition that BCP47 string > >> literal is all that is referred to in RDF-1.1, which is our core > >> reference, not the JVM or other libraries design choices. Ie, the > >> RDF-1.1 specs do not disect the language tag, so we see no need to do > >> so here. The equality rules (lower case comparison with any casing for > >> the tag literal itself) are all defined at the total level, so in that > >> case it also doesn't make sense to decompile the string. > >> > >> On 31 March 2015 at 00:21, Reto Gmür <[email protected]> wrote: > >> > Hi Andy, > >> > > >> >>> > >> >>> and you have evolved to something for Clerezza that is not interface > >> >>> based, which, as already commented (no response from you BTW) is a > >> >>> roadblock for some. There was a point about scalability as well. > >> > > >> > I was waiting for jira, I will create an issue to address this. I > think > >> > IRIs and and language should be glasses. The current code uses an > >> interface > >> > IRI (a different from URL and URI in the java core library for which I > >> fail > >> > to understand the justifying use cases) and a String to express the > >> > language tag (poor OO and wrong identify criterion, as the casing of > the > >> > language tag makes is irrelevant). > >> > > >> > As for scalability I don't know what you are referring to. > >> > > >> > I will create issues and answer your other points when I'm back on a > >> better > >> > connection. > >> > > >> > Cheers, > >> > Reto > >> > > > > > > > > -- > > http://people.apache.org/~britter/ > > http://www.systemoutprintln.de/ > > http://twitter.com/BenediktRitter > > http://github.com/britter > -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter http://github.com/britter
