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

On Friday, March 14, 2014 5:06 PM, Ruben Verborgh wrote:
> > 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.

Redirects increase latency without bringing a real advantage in this case.
You could work around the UI issue by doing an AJAX call instead of
reloading the whole page. Loading JSON-LD would make it quite trivial to do
the templating client-side.


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

That would be fantastic. Then we'd have something to iterate on.


> And better as a pull request or a separate document?

I think this clearly belongs into the core vocab. So a PR would be fine.


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

Hmm.. I don't care that much but the former looks a bit strange to me. We
also need to consider datatypes and language tags. So we have 4 cases:

  1) IRI (+ bnode ID)
  2) literal of type rdf:string
  3) literal of type rdf:langString
  4) literal of any other type

We could of course also combine 2 & 4 by always including the datatype


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

I haven't checked that yet. Do you have that declaration at hand?


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

Yeah, that's exactly what I meant. I think that would be something very
valuable for Hydra.


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

I'm not sure that anything new is needed, it's more about exploiting the
information that's already available.


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

I think my question goes more in the opposite direction. An API exposes
numerous very small LDFs.. the question is how to *collect* or find the
relevant LDFs to get all the data to be able to answer complex queries.


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

Awesome!


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

Yeah, that's what I meant with that term. You give the client the URL of an
arbitrary resource that is part of the API as a starting point. Doesn't have
to a specific one. I see how the example is confusing in that regard but
it's the most practical at the moment :-P


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

Tomorrow I'll be on a train for 9h.. so I'll finally have time to fully read
your paper and have a closer look at the current LDF vocabulary


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

I couldn't agree more! It's great to see that we share the same vision.



--
Markus Lanthaler
@markuslanthaler

Received on Monday, 17 March 2014 20:48:56 UTC