W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > January to March 2004

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

From: Patrick Stickler <patrick.stickler@nokia.com>
Date: Wed, 24 Mar 2004 16:00:50 +0200
Message-Id: <A86B734E-7D9B-11D8-858C-000A95EAFCEA@nokia.com>
Cc: RDF Data Access Working Group <public-rdf-dawg@w3.org>
To: "ext Seaborne, Andy" <andy.seaborne@hp.com>


On Mar 24, 2004, at 15:10, ext Seaborne, Andy wrote:

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

Absolutely.

I've presented several use cases which reflect this need, and it's up
to the WG to decide if those use cases merit being addressed.

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

Quite.

And I feel that the ability to obtain a concise bounded description
of a resource to be a significant short-term need, and that wanting
descriptions of resources rather than variable bindings to be a
primary form of query result.

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

Eh? I don't see the discussion showing anything of the sort.

Addressing FOAF isn't hard at all. In fact, the problem is addressed
quite simply, with a single parameter.

I honestly feel that you and Alberto are painting dragons that
don't exist. If there truly are signficiant problems/issues, fine,
let's discuss them. I'm not blindly obsessive about this, even
if I do feel strongly that it is needed.

But please present concrete examples of such problems/issues. I
think it's fair that if anyone is going to dismiss a use case
or issue as out of scope, that they defend their dismissal with
concrete evidence/argument. I've tried to do so myself, even if
perhaps imperfectly at times.

You and Alberto seem to be arguing for dismissal of over half
of the use cases I've submitted. I think it's fair to expect
you to back that up with very convincing arguments.

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

No more so than GET needs to ever return anything if conneg
is not used, eh? ;-)

If there's no default, then there's no point. Because then there's
no basic interoperability.

Patrick


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

--

Patrick Stickler
Nokia, Finland
patrick.stickler@nokia.com
Received on Wednesday, 24 March 2004 09:24:29 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:18 GMT