- From: Markus Lanthaler <markus.lanthaler@gmx.net>
- Date: Sun, 28 Jun 2015 13:27:31 +0200
- To: "'Hydra'" <public-hydra@w3.org>
On 23 Jun 2015 at 23:42, Ruben Verborgh 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. What exactly needs to be mentioned? > 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. Right. Btw. when was this feature introduced? Somehow I completely missed that. I still had the max. 8 static views on a given triple (fixed value/arbitrary value for each triple component) in mind which isn't true with this anymore. > 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. How do your clients deal with servers that return blank nodes nevertheless? > Does anybody see issues with using blank nodes to query patterns such as > _:x foaf:knows _:y I'm fine with it but I'm wondering whether this should still be called TPF or whether it should be a separate LDF interface. -- Markus Lanthaler @markuslanthaler
Received on Sunday, 28 June 2015 11:28:12 UTC