RE: DBpedia now available as triple pattern fragments

There is an interesting question about  what the scope/extent of
well-knownness ought to be.

For example, if a named individual with an embedded unnamed structured
value is present in multiple datasets, the wkf will differ.

If one wants to integrate data from multiple sources of fragments, and the
wkf is relative to the dataset,  there may end up being extra equality
reasoning needed wherever the fusing gets done.

OWL HasKey axioms might almost be cheap enough, but only work one way;
inverse functional properties don't work for literals. Also, they're not
RDF.

[Rule of thumb: Getting rid of blank nodes rarely makes things worse.]

Simon
On 29 Okt 2014 at 17:38, Ruben Verborgh wrote:
> Hi Greg,
>
>> I don't see any mention of doing this in the Triple Pattern Fragments
spec.
>
> That's right; we hadn't figured out how we would go about that yet.
> The restriction used to be: no blank node in the dataset.
> I think we can relax that to: exposes your blank nodes as IRIs.
>
>> Would you consider adding this as a recommendation ("SHOULD") to the
spec, with a
> description of the problem it solves?
>
> Good idea, tracking this in
https://github.com/HydraCG/Specifications/issues/77.
> It should probably even become a MUST;
> i.e., blank nodes MUST be mapped to IRIs,
> the RDF 1.1 spec SHOULD be followed for this.

Hmm... is that really necessary? Sure, you can't construct a request but
what about simply including all statements about such a blank node directly
in the response (so that there's no need for a separate query)? Do I miss
something here?


--
Markus Lanthaler
@markuslanthaler