Re: proposal: a reifier should reify only one "thing"

> On Apr 18, 2024, at 9:00 AM, Thomas Lörtsch <tl@rat.io> wrote:
> 
>> On 18. Apr 2024, at 17:41, Gregory Williams <greg@evilfunhouse.com> wrote:
>> 
>> We all come from diverse backgrounds. I’m not sure if “us” was meant to mean WG members, or the RDF community/users, or something else, but I’d suggest we not make claims about what “most” people are or are not confused by here.
> 
> Sure speaking for "us" is always a bit difficult in heterogenous groups (and the WG is a heterogeneous group, not to mention the RDF community/users)  but I share the sentiment that there was at least a lot of surprise about the position Ora brought forward. "Some" of "us" would definitely not like to constrain the mechanism just for the sake of not irritating prospective LPG-convertants.

Understood. But I have a slightly different take – it’s not just about “not irritating LPG-coverts.” It’s about leveraging real value to be found in increasing interop between LPG and SPARQL. The charter specifically calls out that the early RDF* work did this, and I continue to think we should be striving to maintain that.

>> I’m not sure I’d describe myself as being confused by (most of) your proposal, but I do think it addresses use-cases which I myself have never encountered, it adds complexity for implementations,
> 
> How?

I think this is partly my fault for poor choice of language. I’ll admit that if I implemented the current proposal as pure triples, with the rdf:reifies data as just another triple in a simple graph, then it’s probably no more complex an implementation to do many-to-many as it would be for many-to-one. However, if you’re starting out with the goal of having a system that can support both LPG and SPARQL over a shared data model and storage system (as in AWS’s proposed OneGraph), or if you’ve got a system where triples/quads are stored in something like a relational table (conceptually, not necessarily at the implementation level), then you may very well already have identifiers for each edge/triple/row. What the many-to-many proposal does for these systems is block off a possible implementation approach that would use the existing identifiers as the reifiers. The “added complexity” I mentioned is really about having to add to these systems something on top of the existing identifiers. This extra system of many-to-many identifiers would then introduce requirements for extra storage/indexing and extra joins to support something that otherwise might be nearly already implemented.

> I bet you happily use named graphs for grouping ;-) Well, maybe, maybe not, but if you accept that named graphs have no semantics and should not be used for anything else than application-specific concerns, then how do you group things?

I’d group things with application-level modeling. Not everything has to be built *into* RDF. There are many ways to do this sort of grouping *on top of* RDF, and I’m nervous about the WG being well ahead of any practical experience with the current proposal. If we get something wrong (if it’s hard to understand for users, or if it makes interop impossible, or if it makes efficient implementation much more difficult), there’s no going back once we put it into the spec. There’s a fair amount of experience with the RDF* CG work that we’re standing on top of; it seems clear we’re going to go beyond what the work did (e.g. to support "parallel edges”/“multiple reifiers”), but the farther we go beyond the existing experience, the more risk there is that we get something wrong.

> And don’t you agree that grouping stuff by attributes is one of the most basic KR activities there is? That’s my use case, and to me its an absolute no-brainer, but if you don’t need it, don’t use it - completely fine by me! But formulating extra restrictions, performing operations at the heart of RDF, just to disable a potentially very (or maybe just marginally) useful feature? I’m really irritated by this fervor. I just can’t imagine who could actually get hurt, and how, if we leave this option open. Reminder: the annotation syntax doesn’t support it, so casual users won’t even note (which I could agree to be a good thing, given the LPG part of the target audience).


thanks,
greg

Received on Friday, 19 April 2024 15:44:28 UTC