On Jul 24, 2011 12:20 PM, "Henry Story" <[email protected]> wrote:
>
> In a reply to Reto's post, which did not make it to the Clerezza list,
> but which is available here
> https://groups.google.com/d/msg/scala-user/IsJ1yXjd2lw/cdAsYsPc4-EJ
>
> Rex Kerr wrote
>
> > Is Clerezza intended to be used primarily on its console? If yes, then
interactive usability is more important than maintainability of large blocks
of code, since you don't typically have large blocks of code, but you have
lots of interaction. Otherwise, you can take advantage of the fact that you
have some control over the console, unlike raw Scala source code. You can
have a modal console that wraps everything in a new context(x) { } line by
line, or a context character like : that indicates that the following stuff
is in the context of the current graph (which can be a signal for the
wrapping).
> >
> > --Rex
>
> I agree with Rex there, there are other ways around the problem of the
> console.
Taking into account difficulties of getting things like autocomplete to work
it seems like a huge effort just to be able to reduce the visibility of some
methods. Also, while bad style, it should be possible to write any code the
console style. People that use clerezza have often to do with scala the
first time on the clerezza console, lifting the quality of code written for
clerezza by a more restrictive api seems like a secondary objective to me. I
agree we should support more explicit scoping and use this method
exclusively for code accepted into clerezza.
We might want to post an rfe against scala to allow for implicits scoped to
a method arguments, as the syntax
new context(tc) {
.... Scoped code
}
Which is the best we have now, has the "new" which seems a bit unnecessary
and it doesn't easily suppport a return value.
Cheers,
Reto
>
> Henry
>
>
> On 22 Jul 2011, at 16:45, Reto Bachmann-Gmür wrote:
>
> > I think the issue boils down to a design recommendation for code using
> > the clerezza rdf library.
> >
> > Importing the members of an EzGraph as context makes perfectly sense
> > on the clerezza console. The "coding" there is imperative, one want to
> > see the results ideally after each line. Creating a block scoped to
> > graph is clearly much less user-friendly [1]. Also having the content
> > graph as default is very useful and shouldn't be sacrificed for
> > enforcing good design in another context. Opening and being in the
> > context you most often want to be is not only handy for rapid queries,
> > the shell is a triple sink where new triples can be added to the
> > clerezza instance simply by writing them down in a syntax similar to
> > the turtle or the n-triples rdf format. Not having to call a method on
> > some nodes on the graph makes a big difference in terms of usability.
> > In program code that as opposed to the commands on the shell is
> > deigned to last and which isn't executed while you type it is better
> > design practice to instantiate an anonymous subclass of EzGraph (which
> > could be renamed or aliased as context as in your examples) rather
> > than importing the members (methods and implicts) of an instance.
> >
> > Your anti-pattern example shows horrible code that you can write using
> > the library, you could very well write a similar example using the
> > java transaction api. The clerezza API however supports better coding
> > practices and the documentation shall focus on these, changing the api
> > to enforce these better practice would be at high costs for those
> > using the api interactively on the shell or in scripts.
> >
> > Reto
> >
> >
> > 1. the clerezza faq entry on how to reset the password shows an
> > example real-life usecase for switching graph-context on the console
> >
> > On Fri, Jul 22, 2011 at 10:12 AM, Henry Story <[email protected]>
wrote:
> >> Great I think I have the solution now.
> >> This thread [1] has helped a lot to make clear the use of context, why
> >> imports that bring behaviour with them
> >> are confusing (they loose context) but also why it was tempting to use
> >> them. It turns out then that one has to take
> >> context seriously, and rewrite the library in order not to have to use
the
> >> confusing implicit imports whilst making code
> >> as easy to read as if they were there (because they will be). Ie: we
can
> >> use those imports but make them explicit,
> >> without ever writing them. If that sounds confusing, it turns out not
to be
> >> in practice, as the following code shows.
> >> One can easily create two graph:
> >> val ez1 = new context {
> >> b_("reto") -- FOAF.name --> "Reto Bachman-Gmür".lang("rm")
> >> -- FOAF.homepage -->
> >> "http://bblfish.net/".uri
> >> }.graph
> >> val ez2 = new context {
> >> b_("hjs") -- FOAF.name --> "Henry Story"
> >> }.graph
> >> but one can then easily continue writing in each graph, in a layered
way
> >> without confusion
> >> new context(ez1) {
> >> b_("reto") -- FOAF.interest --> "scala"
> >> }
> >> new context(ez2) {
> >> b_("hjs") -- FOAF.homepage --> "http://bblfish.net".uri
> >> }
> >> The context protects the blank nodes in the context, so they can't jump
from
> >> one context to the other
> >> (well they can because the framework at the top is leaky - but that is
> >> something for another day),
> >> the subject of the context is very clear too, and one can even add
methods
> >> to this context.
> >> The only thing that is odd from a technical perspective is that this
will
> >> create a bunch of classes on
> >> each "new".
> >> So I must admit without the discussion I would not have walked down
this
> >> path, which seems like a good one.
> >> Henry
> >> The commit for this is here:
> >>
> >>
https://github.com/bblfish/clerezza/commit/6c95c934f15b96c753e3e8eb091482ccaf1b5e32
> >> The files to look at are the new context class
> >>
> >>
https://github.com/bblfish/clerezza/blob/6c95c934f15b96c753e3e8eb091482ccaf1b5e32/parent/rdf.scala.utils/src/main/scala/org/apache/clerezza/rdf/scala/utils/context.scala
> >> But especially the test class that has many examples of usage
> >>
https://github.com/bblfish/clerezza/blob/6c95c934f15b96c753e3e8eb091482ccaf1b5e32/parent/rdf.scala.utils/src/test/scala/org/apache/clerezza/rdf/scala/utils/EzMGraphTest.scala
> >> [1] https://groups.google.com/d/topic/scala-user/IsJ1yXjd2lw/discussion
> >> On 21 Jul 2011, at 21:32, Henry Story wrote:
> >>
> >> On 21 Jul 2011, at 15:32, Rex Kerr wrote:
> >>
> >> But anyway, I am less concerned about the library than about standard
use
> >> cases. Would anyone want to use different graphs? If yes, selecting
them
> >> based on sort-of-hidden context is unwise. Henry's example made it
look
> >> like using different graphs was a pretty reasonable thing to do. And
note
> >> that a one-character variable is a lot more informative than a
zero-variable
> >> character:
> >>
> >> graphContext(definitionsPreamble.currentGraph) { g =>
> >> whatever -- g(edgelabel) --> soandso
> >> }
> >>
> >> Now you have, with a couple extra characters per call, documentation of
what
> >> the relevant context is.
> >>
> >> Thanks Rex. This discussion has helped me also see how it could have
seemed
> >> so
> >> attractive for Reto to want to use this import behaviour.
> >> We start from something very nice and simple we can all agree on
(pretty
> >> much)
> >> val g = new EzMGraph {
> >> reto -- FOAF.knows --> ( bnode --FOAF.name --> "henry" )
> >> -- FOAF.knows --> danny
> >> }
> >> This is both nice and readable, efficient and context bound. (And this
was
> >> one of Reto's early ideas.)
> >> So bnode above is a method that returns a GraphNode (as defined in [1])
> >> using the graph itself. Ie the above is equivalent
> >> to
> >> val g = new EzMGraph {
> >> node(reto) -- FOAF.knows --> ( this.bnode -- FOAF.name -->
"henry"
> >> )
> >> -- FOAF.knows --> danny
> >> }
> >> The good thing is that the result of ( this.bnode -- FOAF.name -->
"henry" )
> >> is a GraphNode with the same
> >> backing graph as EzMGraph, so there is no copying of information from
one
> >> graph to another to do (which due
> >> to blank nodes in the semantic web, might end up being more complex
than one
> >> may think)
> >> Now if one wanted to fill the graph with information from another
context,
> >> one would want a notation
> >> more like
> >> val retoNd = g.node(reto)
> >> for (p <- people) { retoNode -- FOAF.knows --> ( p -- FOAF.knows
--> me
> >> ) }
> >> ie for a list of people assert that Reto knows them and that they also
know
> >> me .
> >> But here if p were say a URI for a person, then one would be creating
in the
> >> code
> >> ( p -- FOAF.knows --> me )
> >> an new GraphNode each time backed by a different empty graph, because
of the
> >> implicit
> >> implicit def resource2graphNode(res: Resource) = new
RichGraphNode(res,
> >> new SimpleMGraph())
> >> This will feel wasteful, when compared to the import solution that Reto
had
> >> proposed where all
> >> resources end up being transformed to GraphNodes with the same backing
> >> graph.
> >> With the code as it stands now in [1] one can still do that. Then
one
> >> would have
> >> import g.node
> >> for (p <- people) { retoNode -- FOAF.knows --> ( p -- FOAF.knows
--> me
> >> ) }
> >> So now each p will be transformed into a GraphNode using the same
store
> >> as g.
> >> Of course, this is nothing more than one would have had one written
> >> for (p <- people) { retoNode -- FOAF.knows --> ( g.node(p) --
> >> FOAF.knows --> me ) }
> >> It is more repetitive, and will be even more so the longer the code.
But I
> >> still prefer it to the
> >> import above (for the moment). One feeds that something needs to be
> >> delimited more clearly.
> >> So perhaps the subclassing solution is the good one again for this
> >> new EzMGraph(g) {
> >> for (p <- people) { retoNode -- FOAF.knows --> ( p --
FOAF.knows
> >> --> me ) }
> >> }
> >> is not that much more verbose that then import version, but it does
make
> >> it clear where the graph
> >> is delimited. With an type alias one could even make that look like
this:
> >> new graph(g) {
> >> for (p <- people) { retoNode -- FOAF.knows --> ( p --
FOAF.knows
> >> --> me ) }
> >> }
> >> Is that perhaps good enough?
> >> Henry
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> [1]
https://github.com/bblfish/clerezza/blob/51be3b14a5488838d87094e81455ca806507b72b/parent/rdf.scala.utils/src/main/scala/org/apache/clerezza/rdf/scala/utils/EzMGraph.scala
> >> Social Web Architect
> >> http://bblfish.net/
> >>
> >> Social Web Architect
> >> http://bblfish.net/
> >>
>
> Social Web Architect
> http://bblfish.net/
>
