> On Mar 12, 2018, at 11:40 AM, Reto Gmür <r...@factsmission.com> wrote:
> ...
>> -----Original Message-----
>> From: Andy Seaborne <a...@apache.org>
>> ...
>> The point about DESCRIBE is that the "right" answer is not a fixed data-
>> independent algorithm but is best for the data being published.
>
> I realize that. My question was more about the definition of "closure".
> Following forward properties might be a pragmatic approach, the data can
> often be modelled in such a way that this default implementation of DESCRIBE
> returns very useful results.
>
> But, in some cases even forward properties only, might result in a too
> comprehensive response. So if the current system doesn't allow disabling the
> default handler one cannot make this answer smaller (e.g. return a
> description of instances of ex:Organization without all its ex:hasMember
> properties). I think fuseki should both allow returning results that contain
> more as well as less than the default.
I think Andy already offered a solution to this problem:
>> IIRC all the handers are executed - the idea being to apply all policies and
>> handlers may only be able to describe certain classes. Remove any not
>> required, or set your own registry in the query (a bit tricky in Fuseki).
"Remove any not required"
If you build up your own registry, I'm not sure you even need to do that.
> As for the best default I think SCBD is the best because independently of the
> data being published and ontologies being used it returns everything the
> server knows about a particular resource, only stopping the contextual
> description where the client can get more information with another DESCRIBE
> query. With SCBD a connected graph can be fully explored with DESCRIBE
> starting at any resource. Yes the response might be to comprehensive and so
> there needs to be a mechanism for DESCRIBE handlers to allow responses that
> are smaller than the default. But I argue that wasting a bit of bandwith in
> some cases is a better default than arbitrarily limiting information and thus
> providing too little information in many cases.
I have to disagree. The default as-is seems to have served well for most users
so far. Perhaps this is behavior ("expose all the triples in partitions using
one request per partition") that is more suited to something like Linked Data
Platform?
ajs6f
