- From: Gregg Kellogg <gregg@greggkellogg.net>
- Date: Tue, 23 Jun 2015 20:55:43 -0700
- To: Ruben Verborgh <ruben.verborgh@ugent.be>
- Cc: Markus Lanthaler <markus.lanthaler@gmx.net>, Hydra <public-hydra@w3.org>
> On Jun 23, 2015, at 2:42 PM, Ruben Verborgh <ruben.verborgh@ugent.be> wrote: > >> Do you see any problems with going down that route? > > I don't see technical problems using blank nodes as identifiers. > We will need to explicitly mention this in ExplicitRepresentation though. > > It just makes things a little harder to explain and understand TPF, but not impossible. > Blank nodes in their usual meaning are not interesting for TPF interfaces anyway. > > For instance, suppose that a TPF interface gave a response containing > _:x a foaf:Person. > then there is no way to get more information about _:x, > because this blank node identifier is only valid in the scope of the response > (and thus means something different in the next request). > This is why, in responses, a TPF interface replaces blank nodes by well-knowns URIs. > An example is at http://data.linkeddatafragments.org/.well-known/genid/ugent-biblio/B1. > > Does anybody see issues with using blank nodes to query patterns such as > _:x foaf:knows _:y > ? In SPARQL, BNodes act as existential quantifiers, so that the about query could match a single _:x and a single _:y, which may be any legitimate RDF Term (URI, BNode or Literal). As you suggest, serializing BNodes using a skolum URI is probably a good idea, but likely something that should be signaled through a VOID definition (I would think, not really sure). If you wanted to get all _:x and _:y that match this pattern, at least using SPARQL semantics, you need variables which are universal quantifiers. Gregg > Best, > > Ruben
Received on Wednesday, 24 June 2015 03:52:18 UTC