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

Hi Markus,

> So, in principle "basic Linked Data Fragments" are a more sophisticated and
> generalized ersion of Luca Matteis' Restpark API
> (http://lmatteis.github.io/restpark/), right? Are you aware of Restpark? I
> forgot it myself but after reading your mail I had a flashback :-)

Basic Linked Data Fragments share the URI template of Restpark.
I actually had a rather similar experience as you;
read about them and forgot until Luca pinged me.

However, whereas Restpark still has "query" in its terminology
(for instance, there is a limit parameter);
basic LDFs are really just specific fragment of a dataset
that can (and should) be interpreted separately from their application.
And that's where Hydra comes in:
my client might use fragments to solve SPARQL queries,
but other clients might do something completely different.

>>    :dbpedia void:subset <http://data-
>> cdn.linkeddatafragments.org/dbpedia?subject=&predicate=dbpedia-
>> owl%3AbirthPlace&object=dbpedia%3ANew_York>;
>>        hydra:search _:triplePattern.
> 
> This all makes perfect sense to me.. the only thing that you might wanna
> change (not sure) is to what hydra:search is attached to.  In this case
> here, I (as a client) would assume that you further query that Linked Data
> Fragment (instead of querying the whole DBpedia dataset).

The above are two distinct triples, right? So I'm saying that:

>> :dbpedia void:subset <…………>.
>> :dbpedia hydra:search _:triplePattern.

So this does capture the semantics that the whole dataset is searched?
I.e., would the client know that the query searches DBpedia, not the fragment?

> Really cool stuff. I see a lot of potential for this. It can be used to add
> extremely sophisticated querying to Hydra-powered Web APIs without
> (over)burdening the server as most other solutions do.


>> 1) How should a parameter be serialized in the URI template?
>> 
> [...]
>> 
>> How can I explain to clients which ones it can use,
>> which ones are the same and which ones are different?
> 
> Very good question. This is tracked as ISSUE-30, right?
> 
>  https://github.com/HydraCG/Specifications/issues/30

Exactly. I've added a link there to this use case.
Ideally, this use case is used as one test to see whether the issue is resolved.

> We can either define (and fix) how
> IRIs/literals are to be serialized or we add a mechanism to describe how
> they should be serialized.

That's it.
But… the full flexibility that this use case needs
will probably be overkill for many use cases.
So I'm afraid there will have to be a mechanism,
because few would want to go all-the-way.

As I've shown, for this use case it's crucial to distinguish
beween literals and URIs. It's a no-go to do anything else.
But it would probably be unreasonable to expect
that people will want to indicate this difference all the time.
(For instance, always have < > around URIs or "" around strings.)

> Allowing to describe the expected serialization
> format is much more flexible but makes the implementation of (primarily)
> clients more difficult.

What could work is "convention over configuration".
(But still allowing configuration.)

>> And of course, there would be many more ways to parse parameters.
>> I could live with only giving one that works for clients,
>> but it should be consistent and allow to differentiate between strings
>> and URIs.
> 
> Would be your preference or can you "just live with it"?

What I mean is that:
the server currently supports different ways to pass a URI.
You could abbreviate it with prefixes, or have to full URI in < >.
It would be totally fine with me if Hydra were only able
to explain just one of them, and not both.

But it would need to explain one of them.

> Do you think there
> are many cases where a variable can take both an IRI and a literal and the
> distinction is important?

No, in the majority of cases it won't be;
because there are few properties that could either take a URI or string.
rdf:object is actually one of the only ones.

But in this case, it is rdf:object I need.

> I kind of have troubles to find an example where that would matter…

In the LDF use case it does, hence my mail ;-)

I understand that a spec cannot be tailored to individual needs,
but LDF could be a big and compelling use case for Hydra.

What I would propose is something like:

   _:object hydra:variable "object";
       hydra:property rdf:object;
       hydra:serialization hydra:NodeSerialization.

Where hydra:NodeSerialization is a way that distinguishes
between IRIs, literals, blank nodes, and variables.

The default ("convention over configuration") could be hydra:TextualSerialization,
where the IRIs or literals as-is value is passed; losing the ability to distinguish.

Summarized: simple cases stay simple,
complex cases are supported and still simple.

>> 2) What do the subject, predicate, and object properties really mean?
> 
> My take on this would be to either specialize the IriTemplate class to
> something like a LdfIriTemplate or to specialize hydra:search.. something
> lik ldf:queryInterface.

That's an interesting option and I like it.
However, I wonder whether Hydra itself could also have
"collection search semantics" built in;
so a specialization of hydra:search that says
"and I will now return those element of the collection
 that directly have the specified property values”.

A discussion in this direction is here:
http://lists.w3.org/Archives/Public/public-hydra/2014Feb/0153.html

I think such a use case would be common enough
to justify its inclusion in Hydra.

> You could then even go as far as saying
> 
>  ldf:queryInterface a hydra:TemplatedLink ;
>    supportedOperation [
>      a ldf:RetrieveBasicLdfOperation ;
>      hydra:method "GET"
>      hydra:returns ldf:BasicLdf
>    ] .
> 
> (sorry, haven't looked up LDF vocabulary yet)

Neither have I :-)

I would also make it a subclass then of hydra:search;
or the more specific property in Hydra is we decide to create that one.

> I'm pretty excited about this as I really see a lot of potential. It would
> be interesting to see if a Hydra ApiDocumentation would provide enough
> information to dynamically "crawl" the data instead of querying it by SPO.
> Have you spent any thoughts on that already?

Oh! No I hadn't. Documentation is a very nice application area indeed. Thanks!

Best,

Ruben

Received on Friday, 14 March 2014 13:26:56 UTC