Re: thoughts and some refs about AFS-2 UC (simplicity, minimalism )

On Mar 24, 2004, at 13:14, ext Alberto Reggiori wrote:

>
> as far as I understand (and implemented [1]) the "fetch object" method 
> for a Concise Bounded Description (CBD) [2], Patrick's algorithm 
> starts from a URI denoting some resource, visiting nodes down the 
> graph till it finds another URI (leaf node) - and then return all 
> visited statements to the client. Quite neat and common case and works 
> pretty well for I2C DDDS or MGET methods - but at same time we found 
> the algorithm not general enough.
>
> A server might as well decide to go further than leaf URI nodes for a 
> certain number N of levels in the graph, or using some server side 
> specific rule, perhaps following specific typed nodes - and so on.
>

I'm not at all proposing that we close the door on other 
forms/resolutions
of descriptions -- only that we define at least one, basic, default, 
most
generally useful/optimal form/resolution of description so that, unless
otherwise specified/requested/indicated, that's what should be 
used/returned.

It's like content negotiation. With conneg, you can specialized your GET
request -- but it's optional, and not all servers support it.

So, while some knowledge sources may support the request of special 
kinds
of descriptions, they should also support the default, and support for
other than the default type of description would be optional for DAWG
conformance.

> in other words, CBD as defined by Patrick today is about returning 
> "outbound" nodes from a URI (Andy's bNodes closure is another example 
> of that AFAIK) - while sometimes the server might need/want to return 
> "inbound" nodes or a mixture of the two.
>
> I found the RDF Objects [3] paper explaining this point a little bit 
> more clearly.

I'll have to have a look at that...

>>
>>
>> I don't see why a standardized definition is needed in a W3C 
>> recommendation.
>
> indeed!

Again, it seems to me that I am being misunderstood as proposing
a prescriptive/restrictive definition rather than a default/typical
definition.

Andy, Alberto, are you opposed to the definition of a default/typical
form of description which allows for any number of additional forms of
descriptions to be provided by any given server?

Or is your objection absolute, against any kind of definition 
whatsoever?
(in which case, I'd ask why you would be opposed to facilitating 
consistency
across disparate implementations...)

>
> we will perhaps need one special keyword/clause into our DAWG query 
> language for the specific case of CBD or fetch_object() (using bNodes 
> closure)

I have been thinking along the lines of a single parameter 'uri='
which, if specified, constrains the input query to the concise bounded
description of the resource denoted by that URI.

If no query is otherwise specified, then the request is for the entire
description. If a query is specified, then the description is returned
only if the query matches the description (e.g. give me the description
if the ex:status property is equal to ex:active, otherwise, don't
return anything).

And, BTW, bnode closure is IMO insufficient. Reifications should be
included. It should also probably be possible to limit the number
of levels of bnode closure, in case one is querying knowledge based
on FOAF like models... maybe even facilitating arbitrary levels
in general, e.g.

uri=             the URI of the 'target' resource

max-levels=      maximum number of bnode closure levels
                  (default = infinity)

levels=          number of description levels below 'target'
                  resource to include (default = 0)

If max-levels < levels than treat max-levels as equal to levels.

etc...

Patrick

--

Patrick Stickler
Nokia, Finland
patrick.stickler@nokia.com

Received on Thursday, 25 March 2004 02:55:02 UTC