Re: Hydra use case: Linked Data Fragments (ISSUE-30)

> Yeah.. even though that's always a bit odd with the open world assumption.

Yes, that's a downside. But you know, we're only giving hints to client anyway.
Even an entire parameter could be missing, because of the open world.

In absence of clues about what to do, try the defaults.
(If they fail, we have instructive error resources, also thanks to Hydra, right?)

> OK, yeah.. I think allowing prefixes makes the solution much complex without
> bringing much advantages if we talk about machine clients.

Fully agree; my client only uses full IRIs.

> If a human user
> is interacting such a service, the UI can still support CURIEs but expand
> them before sending the URL to the server. Have you considered doing that in
> your prototype?

No I hadn't… excellent solution.

> A positive side effect of doing so would be increased
> cache-hit rates.

I have (and still am) considering redirects,
that it is a request for ?property=rdf:type comes in,
redirect to ?property=<http://www.w3.org/1999/02/22-rdf-syntax-ns#type>

Downside: in both cases, the input box in the UI
displays something different than what you've typed in.
But I guess that's a minor one.

> I had something similar in mind. I was thinking of something like
> "ValueOnly" which would correspond to your "TextualSerialization" (IRI
> as-is, only lexical form of literals) and "FullRepresentation" (with a
> better name) which would correspond to NodeSerialization.

Good. Should I start building something like this?
And better as a pull request or a separate document?

We'd then of course have to define FullRepresentation.
Do we go the easy way or the deep way.
Concretely, how to represent 'literal with a quote " inside'?
Does that become
    - "literal with a quote " inside" (i.e., double quotes as markers, no escaping)
    - "literal with a quote \" inside" (i.e., double quotes are special chars, esca)e

Currently I use the former, because the whole thing is URI-escaped anyway;
i.e., there is no necessity to escape, only to indicate URI or string.

> Yeah, this is directly related to what we discussed some time ago (the
> actor/blockbuster thing).

I have a feeling you will say that below.

> I wouldn't be opposed to add something like
> hydra:filter for this. However, before doing so I'd still like to evaluate
> if property paths wouldn't be the more powerful alternative at the cost of
> increasing the complexity a bit.

Both can coexist;
with OWL, we could say that hydra:filter has the restriction
that the property paths are always direct mappings.

> Great.. so we are on the same page :-) As you see, I typically reply to
> mails as I read them.. E-Mail Stream ProcessingT :-P

See, I knew you were going to say that ;-)

> Yep.. even though I would say in most cases you can query/filter only by
> object on some properties. So, for example just by last name or whether an
> issue is closed/open and not on all "fields" as LDF currently does. Is there
> already a way to describe that in LDF?

The vocabulary is really in a draft stage at the moment;
it's goal is to explain things like that:
"this server offers fragments that you can select on…”

But at the moment, this selection happens on the meta-level
and not the data-level, i.e., filtering on triple's subject/predicate/object,
not on the actual concepts they describe.

> I meant a Hydra ApiDocumentation along
> with the used vocabularies basically provides a client a(n incomplete) map
> of the graph a service is exposing. Could that map be used to dynamically
> solve queries?

I see. That could be interesting indeed, but might be a little to deep for Hydra
(and the reason there would be an LDF vocabulary).

For query planning to happen (and you need planning or some queries take forever),
the client should be able to interpret that:
1. you can get this dataset in these kinds of fragments
2. each fragment offers the following metadata
3. each fragment offers the following controls

For a basic LDF, the answers are:
1. fragments that correspond to a basic triple pattern selector
2. the total number of items in the fragment
3. links to related fragments and controls towards each basic LDF of the same dataset

The goal is in the future that there are many types of fragments,
even some that servers can define themselves.
Client could then dynamically decide how to approach a certain query optimally.

> Taking the demo issue tracker as example. Let's say I want to query for open
> issues. With LDF I would query for *, vocab:isOpen, true. The service,
> however, may not implement a LDF query interface.

This is exactly where I want to go to, yes. Same page!

> So, if you give the client
> the entry point, it would have to look up the Hydra ApiDocumentation and the
> used vocabularies in order to (try to) fulfill the query.

I follow you here too, except that "entry point" for me would mean
"any fragment of the dataset", i.e., not necessarily a special resource.

> 1) retrieve entrypoint (/api-demo), -> ok, is of type vocab:EntryPoint

So that I'm not sure of.
[See BTW current discussion at
https://groups.google.com/d/msg/hypermedia-web/fWjqit3KtZQ/hBvHpmSgqNwJ.]

> 2) ApiDocumentation -> vocab:EntryPoint -> supportedProperty -> vocab:issue
> (ignoring for the moment that the range is just hydra:Collection and not
> doesn't specify that members will be of type vocab:Issue)
> 3) dereference vocab:issue link (/api-demo/issues) -> hydra:Collection with
> vocab:Issue members
> 4) dereference each vocab:Issue (e.g. /api-demo/issues/5) as the
> vocab:isOpen is not included in collection representation
> 5) filter retrieved issues and only return the ones marked as open

This is awesome.

> Obviously, it would be much more efficient if the service would offer a
> direct interface, but service providers can't always anticipate what
> consumers are interested in.

Exactly. Or to quote myself at the end of our LDF paper [1]:

    "the best way to make intelligent clients happen
     is to stop creating intelligent servers"

So instead of trying to foresee everything a client might be interested in,
we should focus on enabling the client to do those things itself.
And that is where Hydra comes in. (And LDF technology, too. ;-)

Best,

Ruben

[1] http://linkeddatafragments.org/publications/ldow2014.pdf

Received on Friday, 14 March 2014 16:06:24 UTC