Rename Repository

[tpendragon]

So, this isn't really a linked data fragments building block, and I don't think it's going to become one. It's not a triple pattern fragments server, so what is it? "Cached Data Fragments"? "Subject Fragments"? Do we need a spec?

[no-reply]

:+1: to a spec.

[scande3]

I don't care much for names (functionality is the more important thing). I would like it to eventually be able to do more than just strict subject string resolutions. Out of scope for now, yes, but I can think of additional use cases that I'd want to use my caching layer for than just strict uri resolution. (I believe you had even mentioned partial string matching in the past @tpendragon ?).

I'd be fine renaming it to "Cached Data Fragments" of the options proposed, I suppose.

[tpendragon]

Partial string matching would be a different spec from what exists in the repository now, I think.

[scande3]

"Different spec"? Can you elaborate? If you mean there is no support or basis for that support yet, that is correct. I want to take it one feature at a time and get something working with code using it first before getting to more advanced functionality potential?

[tpendragon]

I mean if we're going to build up a spec for a LDF server which caches, partial matching on object strings would be a different spec and potentially a different service (I assume...surely it would be hard to know when something's being cached otherwise?)

[scande3]

No idea how it might potentially work. (Other use cases might be passing in a predicate with your subject if you just need a certain object... reduces bandwidth). But if I name it "Cached Data Fragments", does that work? Can figure out additional functionality at a point in the future of what is appropriate for this library to support then.

(I'd do the renaming and fix the tests later tonight. Justin Coyne then has a client wrapper he plans to add to projecyhydra-labs linked_data to talk to it as a Repository interface. So hopefully he will have a demo and I'll have the Metadata Enrichment Interface port complete to show off the first use cases for this library).

So any objections to "Cached Data Fragments" (CDF for short)?

[tpendragon]

I don't have any objections, but it should probably fly by the Applied Linked Data group before we start just renaming stuff.

[scande3]

I'll send an email now then. Can also make a new repo if preferred over renaming?

[tpendragon]

Nah, I think renaming is the correct route, just should probably have more input.

[chrpr]

What's the motivation for the renaming? Is it just the fact that we're not building a full set of LDF functionality? I was under the impression that the LDF moniker referred to any and all possible LDF patterns, and an implementation didn't need to support everything.

We're definitely not building the full set of triple pattern fragments, so this is not a Triple Pattern Fragments Server. If I understand the spec correctly, what we've got is a "Linked Data Fragments Subject Pages" caching service.

I feel like calling it Cached Data Fragments muddies things quite a bit, but that's just me.

[chrpr]

"A Linked Data Fragments server (LDF server) is an HTTP server that offers Linked Data Fragments covering one or more datasets in at least one triple-based representation." -- http://linkeddatafragments.org/in-depth/#ldf-server

Does this not fit that definition?

[tpendragon]

@chrpr I don't think it invalidates the spec, but certainly the spirit, yes? If we were making a Triple Pattern Fragments server we wouldn't call it ActiveTriples/linked-data-fragments

[no-reply]

:+1: to a name change. linked-data-fragments suggests a general infrastructure for an LDF server (or client).

Not sure I like "Cached Data Fragments", though, and I agree with @chrpr that this name confuses things a bit, too.

If we wrote a spec for what exists, it would basically be a subset of "Triple Pattern Fragment" scoped to <s> ?p ?o patterns, right? What about "Subject Pattern Fragments"? There's the added quirk that this service does follow-your-nose/description caching, which might be another lead for naming ("Description Fragments"?).

[no-reply]

re: "Cache". Would a service adopting the same request/response interactions that ran over a static dataset (rather than caching), be considered conformant to a (hypothetical) spec?

[chrpr]

@tpendragon I'm cool with a name change as well. Not sure it invalidates the spirit of the spec though. The LDF's own Triple Pattern Fragments implementation has "Linked Data Fragments Server" as the header of its README: https://github.com/LinkedDataFragments/Server.js

I also see @scande3's point that we're implement one specific Linked Data Fragment right now (Subject Pages), and may implement others in the future. I imagine the ability to do <s> <p> ?o patterns as another short term valid use case once <s> ?p ?o is working. It's possible though, that those would not live in the same gem.

[chrpr]

@no-reply: I think what you describe would still be a Linked Data Fragment according to their spec, since a static data dump itself is technically a Linked Data Fragment, no?

[no-reply]

@no-reply: I think what you describe would still be a Linked Data Fragment according to their spec, since a static data dump itself is technically a Linked Data Fragment, no?

Absolutely.

I'm suggesting "Cached Data Fragments" would be inappropriate, unless the caching is considered the main feature.

[tpendragon]

Yes. It would be valid. Subject pattern fragments :+1:

[scande3]

@chrpr - It would live in the same gem unless this one has a limited planned lifespan. Maintaining multiple gems would be a nightmare and break the whole concept of having one standard we can code interfaces to. (ie. X gem may need this, Y gem with the new application, this meaning you can't use both unless you spin up to new application paths which is horrid imo). Beyond slightly different input, isn't the output exactly the same to make it redundant to duplicate the whole caching negotiation layer?

@no-reply - the only reason I will be using this gem is due to it acting as a way to standardize all of our different caching backends to make code shareable. What other use case do you see for this gem beyond resolving URIs against our varying cache implementations easily and fixing responses from troublesome linked data uris?

@tpendragon - what happens when we support more than just the subject pattern? (We wouldn't initially, of course, but it is possible it could expand as a shared use case emerges like having the ability to specify a predicate)?

If we cannot come up with a descriptive name to agree on, we could just name it something else. (ie. Marmotta doesn't indicate it is a triple store by name alone... neither does Apache Stanbol).

[scande3]

Some suggestions: ld-recall, ld-mutter, ld-unity, koinonia (from https://en.wikipedia.org/wiki/Koinonia)?

[chrpr]

ld-fraggles?

[gkellogg]

It seems to me that this repo is about linked data fragments, even though you are only intending to implement a subset. Eventually, you may find important use cases to more fully implement the spec, or someone else may contribute changes to do that. I don't think it makes sense to create a different gem for a subset of a spec, when that would more naturally be extended to be fully compliant in the future.

[scande3]

On the Applied Linked Data call today, there was a 3-0 consensus to keep it called "Linked Data Fragments" for now with sentiments in agreement with @gkellogg . @no-reply and @tpendragon - do you want to make a case against this further? (We can still revisit this topic in the future once we have things running against this code to understand the exact scope of use cases that actually come into existence for it).

[no-reply]

Nope. If there's general agreement, I'd say carry on.

Closing this. If there's cause to reraise it, we can always do that.