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

On Mar 24, 2004, at 14:37, ext Eric Prud'hommeaux wrote:

>

>>> A FOAF example, which is good as a FOAF graph is all bnodes, would be
>>> to
>>> return the description of the person specificied by foaf:mbox and the
>>> defining properties of the foaf:knowns foaf:Persons so that further
>>> graph
>>> retrievals can be done.
>>
>> A concise bounded description, as specified by
>> http://sw.nokia.com/uriqa/URIQA.html#cbd,
>> would do the same in the case of FOAF.
>>
>> In fact, I've long considered adding a parameter to limit the number 
>> of
>> secondary levels in a resource description as in some cases, the bnode
>> closure can be overly large.
>
> If I do my arithmetic right, that would be necessary when querying a
> foaf entity. Given a typical foaf graph:
>
>   _:1 foaf:firstName "bob"
>   _:1 foaf:surname "smith"
>   _:1 foaf:knows _:2
>   _:2 foaf:firstName "bob"
>   _:2 foaf:surname "smith"
>   _:2 foaf:knows _:3 ...
>   _:1 foaf:knows _:4
>   ...
>
> the data bounded by a CBD would encompass most of the graph.

Right.

Though I think most folks will likely agree that FOAF is, er, "special" 
;-)

But having an upper bound on the bnode closure would be useful.

>

>>>
>>> I don't see why a standardized definition is needed in a W3C
>>> recommendation.
>>
>> So that there is consistency in the behavior of conforming servers.
>>
>> So that when a client says "tell me about X" to a dozen different
>> servers,
>> they understand exactly what is meant, and in the same way.
>>
>> So that implementors creating new services which provide descriptions 
>> of
>> resources can be provided guidance about what an optimal level of
>> resolution
>> for a description is.
>
> Suppose we had a query language that allowed some sort of URI-labeld
> profiles.
>   GET http://liber.examaple.com/book1
>   Profile: http://www.example.com/profiles/Book
>
> This would allow for the definition of different queries, some of
> which would specify that no addtional data would be returned, and
> would thusly be more attractive to small devices at the end of long
> thin pipes (network term meaning slow data feeds).

As far as I'm concerned, that's not much different from the present
day situation. I.e., if there is no guidance about generally preferred
or expected default behavior, then there is no global interoperability.

>
> If the DAWG query language did not specify that returned triples
> and/or bindings must all be specified in the query, folks wishing
> to define such profiles could define them in terms of properties.
> Query servers that didn't understand these profiles would simply
> give no results for a query like:
>
>   <http://liber.examaple.com/book1> 
> <http://www.example.com/profiles/Book> ?x
>
> The upside is that you get distributed and domain-specific profile
> definition. The downside is that a client can't lean on a
> specification that says "if you answer this port, or claim to handle
> this SOAP message, you must also understand this profile."

At the very least, there should be a default, basic profile that
implementations must support, and must use if not otherwise
specified by the client.

>
>> I think there are many reasons why a standardized definition is needed
>> in a W3C recommendation.
>
> I suspect that defining the perfect resource description query is as
> difficult as defining the perfect ontology.

I never said perfect. Nor have I ever said it would be exclusive.

I said most optimal for the most typical applications, which we are
in the process of defining by our use cases.

And, BTW, I think there is very strong concensus about what that 
optimal,
typical form of description would be, so I remain very puzzled why there
is such strong opposition to its specification.

I've yet to see a concrete example of where its definition causes pain 
or angst
for developers -- since most of them are going to be providing 
definitions
of that sort anyway (in addition to, perhaps other more specialized or 
more
paramterized forms of descriptions).

To make this more specific, let's take as a strawman, the definition
of a concise bounded description as defined in the URIQA spec. Can you
provide some concrete examples of how it fails to meet typical needs
or causes substantial implementational or operational problems (leaving
aside the known issue of limiting the depth of the bnode closure, which 
is
already recognized as something needed to be addressed)?


> The parallel follows for
> "good enough" queries and ontologies.

IMO, the definition of a concise bounded description is more than "good 
enough"
for most applications where a resource description is desired. If you
disagree, then please provide concrete examples of where it fails.

Patrick

--

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

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