Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

getThing should support name as well as url like createThing does #1511

Open
ianconsolata opened this issue Mar 9, 2022 · 0 comments
Open
Labels
enhancement New feature request Triaged This means that we've a ticket to look at this in the future

Comments

@ianconsolata
Copy link
Contributor

ianconsolata commented Mar 9, 2022

Search terms you've used

getThing

Feature suggestion

I find myself creating named Things a lot, and relying on the client / server to set the base url to match a given resource when I save the resource. However, when I go to get those Things back out of the dataset, I can no longer solely use the name, I have to also use the base url to construct the full URL identifier for that Thing.

I often pass datasets around the code, and want to refer to Things in that dataset by name without also having to keep track of where that dataset was from. While I could do it myself using getSourceUrl, it seems like the SolidDataset should also have the information to just accept a string and do that conversion for me.

Expected functionality/enhancement

getThing can be called with either the name relative to the base IRI of the dataset, or the full url

getThing(dataset, "name")) === getThing(dataset,`${getSourceUrl(dataset)}#name`)

I would be happy to implement this if there is support for it, but it seems like it might be a controversial API choice, so wanted to open the issue to chat about it first. Personally, I think for pure feature parity, if createThing supports name, then getThing should as well.

@ianconsolata ianconsolata added the enhancement New feature request label Mar 9, 2022
@ThisIsMissEm ThisIsMissEm added the Triaged This means that we've a ticket to look at this in the future label Nov 25, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature request Triaged This means that we've a ticket to look at this in the future
Projects
None yet
Development

No branches or pull requests

2 participants