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

On Monday, March 17, 2014 10:02 PM, Ruben Verborgh wrote:
> > 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.
> 
> Exactly, although Turtle might be faster in this particular case since
> the output are triples.

It would be interesting to benchmark that.. I was thinking of JSON-LD
representations of the following form

[
  { "@id": "http://subject", "http://predicate": { "@value": "object" },
  { "@id": "http://subject", "http://predicate": { "@id": "http://object" },
  ...
]

> > 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
> 
> My current answer is:
> 1) < . > or _:x
> 2) "string"
> 3) "string"@en
> 4) "string"^^<type>
> 
> Gregg remarked that <.> are not necessary.

I agree


> I'd just them to differentiate between qnames and full IRIs,
> but that might not be needed.

Probably not. However, *if* we decide to support them, I would prefer to
special-case qnames. I'm offline at the moment but I think the CURIE spec
recommends wrapping them in square brackets [prefix:suffix].


> >> 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?
> 
> It depends on how we'd express property paths.

I think the simplest thing would be to use lists


> >> 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.
> 
> It would be needed we'd also need to detail how each part of the graph
> can be accessed, i.e., what kind of fragments your are offering.
> Without that, no query plan, without query plan, exponential times
> (or you'd have to download the whole thing before querying it).

Well, the ApiDocumentation along with property ranges and supportedProperty
kind of expresses that information, doesn't it?



--
Markus Lanthaler
@markuslanthaler

Received on Tuesday, 18 March 2014 22:14:29 UTC