Re: possible stances with respect to multiple reification

On 24/04/2024 12:19, Adrian Gschwend wrote:
> On 22.04.2024 17:22, Peter F. Patel-Schneider wrote:
>> I am against stating that well-formedness is something that might be 
>> used to limit what an RDF implementation accepts.  In my view that 
>> will either split the RDF space or (worse) choke off non-wellformed 
>> RDF graphs.
> In practice this IMO already happened. Stardog by default enables 
> "strict parsing", which rejects datatypes that are incorrect [1]. I 
> guess other stores do the same, at least optionally.
> Rdflib will throw an exception if a datatype does not adhere to the 
> standard. Furthermore, as we've discussed multiple times, lists are not 
> well supported in various stores partly because they are prone to failure.

The datatype and list examples show two different aspects:

* The datatype condition is "local" - it can be determined immediately 
on seeing the datatype.

* The list case, it needs the "whole graph" and can't be determined 
until the whole graph can be inspected.

The list is also an example (albeit rare) that the condition can be 
broken by merge.

Some of the reification related well-formedness, around URIs for 
reifiers, make merge-breaking well-formedness more significant.

> I completely understand the utility of being able to load any dataset 
> regardless of its content's coherence. However, as I mentioned two weeks 
> ago, this approach becomes problematic when developing applications on 
> top of this data. In such scenarios, users expect a more closed-world 
> handling of data where everything should be 'proper'; otherwise, it 
> becomes significantly more challenging to develop frontend applications.
> And I say that as someone who earns his living building applications 
> based on RDF data.
> With literals, the solution is relatively straightforward: we can simply 
> validate the datatypes. Implementing a similar standard of 
> well-formedness for RDF-Star (and hopefully for lists in the future) is 
> essential for these applications.
> The problem is that right now I don't have a way to say "I need this set 
> of restrictions" for my use-case, it's very vendor/implementation 
> specific. I think I would need something similar to OWL-profiles, where 
> I know what to expect.

It doesn't seem to be a hard boundary though. It is data quality and the 
data needs checking on receipt  with local requires (e.g. expected 

So, yes, there needs to be a way to say it; it's a requirement of the 
stack, not just the RDF data layer. SHACL as "valid datatype".

One thing that may help is "advisories" -- "implementations SHOULD warn 
and SHOULD (MAY) accept"


> regards
> Adrian
> [1]: 

Received on Wednesday, 24 April 2024 12:43:22 UTC