incubator-clerezza-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reto Bachmann-Gmuer <>
Subject Re: How to name things with URIs
Date Sat, 14 May 2011 15:09:12 GMT
On Fri, May 13, 2011 at 5:46 PM, Henry Story <> wrote:
> Clerrezza-489 and you also quote may statement of 463. okay, you might say
> that I'm stating rather than arguing.
> :-)
> The argument: they are different thing, both intensionally (cache and
> source) as in many case extensionally (triples may differ).
> in that sense I agree.
> But then the other point I made is also true, and that is that different
> users may get different
> graphs back for the same remote resource. In fact those users may be the
> same user at different times.  Since those are all different graphs by your
> definition above one should also give them different names.
We do not have support for this yet and I think its a feature
increasing complexity massively. I don't think that clerezza-490 need
to be resolved urgently, but anyway we should proceed issue by issue,
and the best resolution of an issue is a minimal resolution not one
that tries to foresee and future issues.

> So local graph naming schemes should take that into account, which is why I
> suggest that we have an API that can allow for extensibility here.
We have currently things and we are naming them badly.

Prior to you r webproxy we had:
<webid-profile-url>.cache as name for the cache of the webprofile
<webid-profile-url> as uri for triples the user generated locally,
this can be seen as extensions to the remote profile with information
(like preferred language) that happen not to be in the remote profile

which was consistent with local users who only had
<webid-profile-url> for the triples they control which include both
the regular profile as well

Now <webid-profile-url> is the cache, not sure where additional
triples added locally get stored, i.e. where triples added to
webIdGraphsService.getWebIDInfo(webId).publicUserGraph are stored.

I'm not saying the old naming was perfect but it worked in a somehow
consistent fashion for local and remote users. Now my application taht
used this feature is now longer working.

> in Clerezza-489 I wrote that one could describe each graph like this in a
> special Cache graph perhaps.
> :g202323 a :Graph;
>     = { ... };
>     :fetchedFrom <;;
>     :fetchedBy <;;
>     :representation <file:/tmp/repr/202323>;
>     :httpMeta [ etag "sdfsdfsddfs";
>                      validTo "2012...."^^xsd:dateTime;
>                     ... redirected info?
>                     ] .
> :g202324 a :Graph;
>     = { ... };
>     :fetchedFrom <;;
>     :fetchedBy <;;
>     :representation <file:/tmp/repr/202324>;
>     :httpMeta [ etag "ddfsdfsddfd";
>                      validTo "2012...."^^xsd:dateTime;
>                     ... redirected info?
>                     ] .

If we had barketing in RDF and our tooling would support it the the
above might be somehow topical, answer to the question "how to name
this?" "don't name it". Please lets proceed issue by issue and make
sure every brick we place is really solid and separate this from
visionary long term stuff.

> Then this API could use information from this graph to and information from
> the user's request
> to find the correct local graph he wants.
Still the local graph would have a name, probably - but as I said its
irrelevant. Lets deal with the issues at hand, you changed the names
of graph (which I agree didn't have the best possible names) with
names that I think are worse, lets find something we can agree upon.
(otherwise, please roll back to the version with the orginal names
till we find a consensus).


> Henry
> PS. Having said that one then may just wonder why local graphs should ever
> have anything other than
> local URLs, since every time someone made a copy of a local graph it would
> be different.

View raw message