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

Patrick:
> 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?

I wish to see the working group agree the *need* for it to be in the rec.
(normative or non-normative).

> 
> 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...)

And to be clear, I am making no absolue objection to anything.  It is far
too early to even think of such things.  I want an early rec, delivering
some significant value now, not a later rec. covering a wider range of
values.  I believe that the early/simple rec. will trigger community
requirements we will not think of in this cycle, or not weight highly
enough.

Earlier in the message you said:

> one, basic, default, most
> generally useful/optimal form/resolution of description

and as the discussion shows the FOAF case makes that hard.  There also seems
a tension between "optimal" and "basic".  The "content negotiation" approach
seems over doing it but interesting.  It would not need a  default.


	Andy

-------- Original Message --------
> From: Patrick Stickler <mailto:patrick.stickler@nokia.com>
> Date: 24 March 2004 11:51
> 
> 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

Received on Thursday, 25 March 2004 01:39:12 UTC