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

On Mar 24, 2004, at 12:50 PM, Patrick Stickler wrote:
>>
>> 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.

I have been trying to make a simple point - CBDs are useful and good 
construct to use - but too restrictive for the general case, which I 
think is what the DAWG should try to recommend instead e.g. "give me 
'stuff' about X" where "stuff" is "application-profile" dependent. And 
X might be a URI as well as an arbitrary "RDF object" reference (e.g. 
typed bNode triple-pattern)

Now - if we decide to put your CBD (or Andy's bNodes closure or 
whatever) definition into the spec it should only be for the savvy of 
"best practice" - but we should be clear to the user/reader that 
different federations might use/agree on different "description" 
definitions as requested by their applications. It is clear, that 
different "extraction algorithms" will be used/invented by users 
anyway.

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

Patrick - I feel we agree on the basic line - but what I would *not* 
like to see in the spec is one single black-on-white definition of 
"description about X" - we should stay as "opaque" as possible on that 
IMO

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

I feel this (and other aspects arose in other use-cases threads) need 
further discussion some time - better now to concentrate to get some 
basic core spec out - but at same time is good to brainstorm on other 
issues and "keep an eye on them"

cheers

Alberto

>>
>> 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 09:36:17 UTC