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