incubator-clerezza-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reto Bachmann-Gmuer <reto.bachm...@trialox.org>
Subject Re: EzGraph
Date Thu, 30 Jun 2011 22:36:32 GMT
Hi Henry and all,

I committed a version that includes the usingAsciiArrows-test with only
minor modification while I think it simplifies the code a lot

A few remarks:

- the default way of creating a new EzGraph is by subclassing as in

val ez = new EzGraph() {
    "http://bblfish.net/#hjs".uri -- FOAF.knows --> "
http://farewellutopia.com/reto/#me".uri
}

The create ez above is an MGraph with one triple.

- because of the inherited implicit conversion using the "u"-method you
proposed is no longer needed, the following is a valid another valid
one-triple MGraph

val ez = new EzGraph() {
    DC.comment -- OWL.sameAs --> RDFS.description
}

- while the implicit argument version you implemented for alternative method
names (english terms or single-unicode characters) shows some nice feature
of scala I think this can be achieved much easier by importing a class doing
implicit conversions e.g. from RichGraphNode to UnicodeRichGraphNode that
adds the required overloaded methods, like that any numbers of alternative
names/syntaxes can be added without requiring a particular and complexity
enhancing support in the core.

- I haven't ported the support for rdf:List as I think there's a
code-duplication there with the existing RdfList class and also

There's some clean-up to do and some comments need to be fixed, yet you
could already have a look at the test and let me know if you think the api
should be different.

Cheers,
Reto

On Thu, Jun 30, 2011 at 11:21 PM, Reto Bachmann-Gmuer <
reto.bachmann@trialox.org> wrote:

>
> On Jun 30, 2011 5:55 PM, "Henry Story" <henry.story@bblfish.net> wrote:
> >
> >
> > On 30 Jun 2011, at 17:23, Reto Bachmann-Gmuer wrote:
> >
> >> On Thu, Jun 30, 2011 at 3:15 PM, Henry Story <henry.story@bblfish.net>
> wrote:
> >>>
> >>> On 1st of June you wrote:
> >>>
> >>> [[
> >>> For the issue to be resolvable:
> >>> - It should be at least minimally documented, a minimal documentation
> includes api documentation for all public members.
> >>> - not use unicode character not readily available in the most commonly
> used fonts on all major operating systems.
> >>> - EasyGraph should not extend SimpleMGraph, the current implementations
> copies all the triples of the wrapped graph in memory
> >>> - As I already commented on May 8, as writing generally goes together
> with reading I don't see why we should have a RichGraphNode for reading and
> EasyGraphNode for writing
> >>> ]]
> >>>
> >>>
> >>> I have now done all you asked me to do then: unit tests, documentation,
> not to extend simple graph.
> >>
> >> I've looked at the code and it contains several improvements and very
> elegant approaches. We still disagree on the need to introduce a new
> subclass of GraphNode and a subclass of Language. For the unicode style I
> think it should be possible to find a set of unicode characters  supported
> by more fonts (anybody got the characters to show up in an IDE on a OS other
> than MAC?).
> >
> >
> > yes, I'd be interested in that. The default is now the ascii arrows, so
> things should be good to go at least.
> > If there are better unicode arrow characters then that would be a good
> thing to know about. I think it is kind of useful to allow unicode
> characters at least as an option, as it pushes the infrastructure everywhere
> a bit. Unicode support should be available everywhere. A lot of very good
> scala libraries use them, especially Scalaz which implements a lot of
> concepts from category theory.
>
> You make it sound as if the issue was supporting unicode or not but in fact
> we are talking about a few characters not contained in default fonts.
>
> >>>
> >>>> Discussion takes time. Code speaks louder than words here. I don't see
> what you are unhappy about.
> >>
> >> I created the issue branch in two variants CLEREZZA-510-bblfish and
> CLEREZZA-510-reto, lets work on this issue branches to talk in code. Maybe
> seeing the code differences and the implications they have on the tests we
> can solve the remaining issues.
> >>
> >> In between, could you remove the CLEREZZA-510 code from trunk? This
> requires some rewriting of code you introduced for other issues.
> >
> >
> > Look, I'd really need to move onto other things.
>
> I really like many parts of your contributions and of your ideas. However
> we must work hard on working the right way. You really did a lot of work,
> however it is much better to have a small and consensus capable patch than a
> big patch that is hard to be reviewed and discussed about and thus takes a
> lot of time till it can be accepted. Also keep in mind that when there is
> code in trunk from unclosed issues this is a big impediment for others to
> work on the affected modules. To summarize: if you have a lot of other
> things to do do smaller stuff but do it right (referring to the process)
> nobody here has fun or is paid for cleaning up experiments others left in
> trunk.
>
> > You agree the code is nice and elegant. It can be done otherwise I am
> sure. I don't think any of the code here is perfect. And I can try to
> improve it over time as we use it.
>
> I said that your code "contains several improvements and very elegant
> approaches" but it also contains what I consider wrong design decisions
> which should not be part of clerezza.
>
> But the main thing that went wrong is the size of the issue and its
> ramifications. The issue could have been tackled in many small issues. What
> you did looks more like a spike to me, an experiment on how things could be
> done without caring about the best possible integration. This is good for
> discussion but then it should result in many small well integrated
> improvements like the closed CLEREZZA-577 issue is such an example of a tiny
> improvement derived from this spike (and again, the spike code should not be
> in trunk).
>
> >This code has already been used a lot, so instead of reworking everything
> we can just go with it.
>
> The fact that code of the yet unresolved issue is used by other code you
> committed to trunk is part of the problem.
>
>
> > As I said I was working a bit over a week ago on a port of foafssl.orgto clerezza
and would like to continue with that.
>
> I think I'm not the only who would like to do a release asap. The hindrance
> to releasing is the trunk code of these unclosed issues, you suggested this
> can be removed so please go ahead and do it. I was trying to find a way to
> get as much as possible closed, but I'm happy with you removing the code and
> discuss on the best approaches after the release.
>
> Cheers,
>
> Reto
>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message