- From: Markus Lanthaler <markus.lanthaler@gmx.net>
- Date: Mon, 17 Mar 2014 21:48:23 +0100
- To: "'Ruben Verborgh'" <ruben.verborgh@ugent.be>
- Cc: <public-hydra@w3.org>
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