the metagraph -- Re: How to name things with URIs

[Henry Story <he...@bblfish.net>]

On 16 May 2011, at 08:06, Reto Bachmann-Gmuer wrote:

> On Sun, May 15, 2011 at 7:38 PM, Henry Story <he...@bblfish.net> wrote:
>> 
>> [snip]
>> But there are some things I was looking at that may be important to consider.
>> 
>> In the WebProxy I do return a Resource object that comes with information about the graph.
>> So it is a bit more than a graph node. It is a graph containing a graph node: a GraphNodeGraph
>> perhaps; Metadata about a resource, including the graph. I was thinking this would be useful
>> to be able to work out what an issue with a remote graph was, if one should force fetch it again...
> Your proposal introduced new interfaces which are not yet actually
> used,

Well I was going to use them for work in helping debug WebID, pingback and 
other protocols. 

> this is a typical case for over architecture, lets do the
> simplest thing first.

What is simplest is discovered through a process; it is not given ahead
of time. For example it took a first implementation of a simple caching
system, for people here to see the use of it - demonstrated with WebID, 
pingback, and foaf - to see that this should be tied into the more general
structure of zz, which led to this refactoring, and so to the simplification.
I am not sure I would have gotten a lot of attention and interest in the
simplification before showing the value of the system. And indeed not knowing
Clerezza that well, I would probably not have been the right person to make the
correct simplification. It is the usefulness of the service that makes it 
worthwhile investing the energy into the simplification.

> The obvious next step is to have an graph with
> meta information about the cached graphs. Then we might see that we
> can simplify client code by returning an object holding both the graph
> and the meta-information. But by introducing this indirection right
> away you make client code more complicated.

Only because you have now seen the tie in with TcManager 
which is a refactoring. Initially it was not that much more complicated, since 
one gets these pieces of information in the first HTTP GET.

But I agree we can and should have a graph of metadata about the way the
resources were fetched. They should probably use the Tabulator ontology, since that
is already used in a live project. I mentioned this right at the beginning of the
project, and did not develop it more immediately because I wanted to wait for
this kind of refactoring proposition to come along. 

This metadata where graphs were found, the redirects, the e-tags, etc, are all
going to be very important to a good web proxy service, which I think is in fact
going to end up being one of the most important parts of zz.

> 
>> It is something that can be very useful to know: a WebID in your foaf file is no longer accessible,
>> should it be removed from the foaf? A resource was last fetched a week ago, but it is important in the current transaction, one should perhaps fetch it again: the information may be out of date.
>> Two graphs content clash, which one is freshest? Who said what? What was the previous version of this graph? (Oh, it's completely different?! Mhh...). Which application created it? (We deleted that did we not? Perhaps it's graphs should go too)
>> 
>> I was hoping to explore that a bit further to see where it leads to. But it will of course also
>> make sense for a TcProvider too. What do you think?
> This certainly all makes sense, yet there are and always will be
> client that don't need to care about this complexity so an api
> optimized for them need to be provided in any case. So considering
> that the implementation wasn't actually offering this additional
> information it doesn't make sense to make the API preemptively more
> complicated.
> 
> Lets build clerezza like a building, have a modest goal for the next
> step, place a brick, make sure its solid close the issue and proceed.

ok, so the next thing to build then is this metadata information graph.
What shall we call it? (Now here one of those zz urls is of course perfectly
fine!)

Re: the metagraph -- Re: How to name things with URIs

[Reto Bachmann-Gmuer <re...@trialox.org>]

On Mon, May 16, 2011 at 10:32 AM, Henry Story <he...@bblfish.net> wrote:
> ok, so the next thing to build then is this metadata information graph.
> What shall we call it? (Now here one of those zz urls is of course perfectly
> fine!)

What about urn:x-localinstance:/rdf/storage/web/cache-status

Cheers,
Reto