Giter VIP home page Giter VIP logo

solid-client-js's Introduction

Solid JavaScript Client - solid-client

Contributor Covenant

This project adheres to the Contributor Covenant code of conduct. By participating, you are expected to uphold this code. Please report unacceptable behavior to [email protected].

@inrupt/solid-client is a JavaScript library for accessing data and managing permissions on data stored in Solid Pods. It provides an abstraction layer on top of both Solid and Resource Description Framework (RDF) principles and is compatible with the RDF/JS specification. You can use solid-client in Node.js using either CommonJS or ES modules, and in the browser with a bundler like Webpack, Rollup, or Parcel.

@inrupt/solid-client is part of a family open source JavaScript libraries designed to support developers building Solid applications.

Inrupt Solid JavaScript Client Libraries

Data access and permissions management - solid-client

@inrupt/solid-client allows developers to access data and manage permissions on data stored in Solid Pods.

@inrupt/solid-client-authn-browser allows apps running in a browser to authenticate against a Solid server. This is only necessary if you wish to access private resources in a Pod (to access public resources you could simply use standard fetch()).

Vocabularies and interoperability

A fundamental requirement for any two systems to interoperate at all is that they have a shared understanding of the concepts and ideas relevant to those systems. That shared understanding is expressed as a common 'language', and the individual terms from that language are typically described and explained in dictionaries.

The Solid eco-system uses RDF vocabularies (or slightly more formally, 'ontologies') to describe concepts and ideas in a machine-readable, W3C standardized format (effectively, these RDF vocabularies act as dictionaries for systems to share concepts and ideas).

There are already many common vocabularies published on the web, such as the vCard vocabulary for describing the concepts and ideas associated with People and Organizations, or Schema.org for describing the things search engines are typically interested in, intended to be used by webmasters to mark up their pages in ways that those search engines can then understand.

As a convenience for JavaScript developers, Inrupt publishes various npm modules that provide JavaScript classes containing constants representing the individual terms described in many of these vocabularies today, including modules specifically for Solid-related vocabularies, and for Inrupt-specific vocabularies.

By simply importing one of these NPM modules, developers have immediate access to all the terms described in all the RDF vocabularies referenced by that module.

Common RDF vocabularies

This module bundles together JavaScript classes representing many of the most common RDF vocabularies published on the web today (e.g. FOAF, Schema.org, vCard, SKOS, etc.): @inrupt/vocab-common-rdf

Solid-specific RDF vocabularies

This module bundles together JavaScript classes representing all the RDF vocabularies related to Solid (e.g. Solid terms, WebACL, ACP, etc.): @inrupt/vocab-solid-common

Inrupt-specific RDF vocabularies

This module bundles together JavaScript classes representing all the RDF vocabularies created and maintained by Inrupt (e.g. an Inrupt test vocabulary, Inrupt glossaries, Inrupt product vocabularies, etc.): @inrupt/vocab-inrupt-common

Supported environments

Our JavaScript Client Libraries use relatively modern JavaScript, aligned with the ES2018 Specification features, we ship both ESM and CommonJS, with type definitions for TypeScript alongside.

This means that out of the box, we only support environments (browsers or runtimes) that were released after mid-2018, if you wish to target other (older) environments, then you will need to cross-compile our SDKs via the use of Babel, webpack, SWC, or similar.

If you need support for Internet Explorer, it is recommended to pass them through a tool like Babel, and to add polyfills for e.g. Map, Set, Promise, Headers, Array.prototype.includes, Object.entries and String.prototype.endsWith.

Node.js Support

Our JavaScript Client Libraries track Node.js LTS releases, and support 18.x and 20.x.

Installation

For the latest stable version of solid-client:

npm install @inrupt/solid-client

For the latest stable version of all Inrupt Solid JavaScript libraries:

npm install @inrupt/solid-client @inrupt/solid-client-authn-browser @inrupt/vocab-common-rdf

Issues & Help

Solid Community Forum

If you have questions about working with Solid or just want to share what you’re working on, visit the Solid forum. The Solid forum is a good place to meet the rest of the community.

Bugs and Feature Requests

  • For public feedback, bug reports, and feature requests please file an issue via Github.
  • For non-public feedback or support inquiries please use the Inrupt Service Desk.

Documentation

Changelog

See the release notes.

License

MIT © Inrupt

solid-client-js's People

Contributors

ajacksified avatar ameyabhat avatar andydavison avatar chelseapinka avatar dependabot-preview[bot] avatar dependabot[bot] avatar dgbarclay avatar edwardsph avatar jeswr avatar langsamu avatar laurin-w avatar matthieubosquet avatar nicolasmondada avatar nseydoux avatar pmcb55 avatar solid-akb avatar thisismissem avatar travis avatar vanhumbeecka avatar vinnl avatar virginiabalseiro avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

solid-client-js's Issues

Isolate `Resource` functions from `LitDataset` functions

Search terms you've used

Resource, LitDataset

Is your refactoring request related to a problem? Please describe.

As more features are implemented that are relevant for both LitDataset and plain files, depending on the motivation to add these features they may be added arbitrarily to src/litDataset.ts or src/nonRdfData.ts. Centralizing these functions in one place would help having code and tests more focused.

Describe the solution you'd like

src/resource.ts (and src/resource.test.ts) is created, containing functions such as parseResourceInfo, internal_fetchResourceAcl, etc, and the associated tests.

Describe alternatives you've considered

Keeping all the Resource-related code in the current src/litdataset.ts file

Additional context

This issue also aims at experimenting the refactoring issue template.

Use a single DataFactory constructor

Search terms you've used

n3, rdf/js, @rdfjs/data-model

Is your refactoring request related to a problem? Please describe.

We currently import DataFactory from either @rdfjs/dataset (in code) or n3 (in tests). The history behind that is that we used to use N3's DataFactory, then realised that @rdfjs/datasets exports the DataFactory from @rdfjs/data-model, and used that - but kept using n3 in the tests to make sure we're compatible with other implementations of RDF/JS. However, it's not directly clear that and why we're doing this, so we might as well switch to using the same DataFactory everywhere.

Describe the solution you'd like

Use the DataFactory from rdfjs.ts in our tests as well.

Describe alternatives you've considered

Making sure our tests only use the N3 DataFactory.

Additional context

N/A

set...Access does not update existing rules, adding triples

Search terms you've used

"ACL"

Bug description

setAgentDefaultAccess, setAgentResourceAccess, setPublicDefaultAccess, and setPublicResourceAccess do not modify rules if they already exist. The documentation claims that If rules already exist for the Agent in the given ACL, in the returned ACL, they are replaced by the new rules., but this does not happen in practice.

To Reproduce

  1. Create a folder
  2. Define this function for setting ACLs
export async function setAcl(
  url: string,
  webIdAccess: Record<string, Access>
): Promise<void> {
  // Fetch the SolidDataset and its associated ACLs, if available:
  const myDatasetWithAcl = await getSolidDatasetWithAcl(url, {
    fetch: (info, init) => {
      return fetcher(info, init)
    },
  });

  // Obtain the SolidDataset's own ACL, if available,
  // or initialise a new one, if possible:
  if (
    !hasResourceAcl(myDatasetWithAcl) &&
    !hasAccessibleAcl(myDatasetWithAcl)
  ) {
    throw new HttpError(
      "The current user does not have permission to change access rights to this Resource.",
      403
    );
  }

  let resourceAcl = createAcl(myDatasetWithAcl);
  // Give someone Control access to the given Resource:
  Object.entries(webIdAccess).forEach(([webId, access]) => {
    if (webId === "public") {
      resourceAcl = setPublicDefaultAccess(resourceAcl, access);
      resourceAcl = setPublicResourceAccess(resourceAcl, access);
    } else {
      resourceAcl = setAgentDefaultAccess(resourceAcl, webId, access);
      resourceAcl = setAgentResourceAccess(resourceAcl, webId, access);
    }
  });

  // Now save the ACL:
  await saveAclFor(myDatasetWithAcl, resourceAcl, {
    fetch: (info, init) => {
      return fetcher(info, init);
    },
  });
}
  1. Run the following
await setAcl("https://pod.example/folder/", {
  "https://jackson.solidcommunity.net/profile/card#me": {
    "read": true,
    "write": true,
    "append": true,
    "control": true,
  },
  "public": {
    "read": true,
    "write": true,
    "append": true,
    "control": false,
  }
});
  1. That will cause the ACL to look like
@prefix : <#>.
@prefix n0: <http://www.w3.org/ns/auth/acl#>.
@prefix c: </profile/card#>.
@prefix tes: <./>.
@prefix n1: <http://xmlns.com/foaf/0.1/>.

:16200627777229416622674554878
    a n0:Authorization;
    n0:agent c:me;
    n0:default tes:;
    n0:mode n0:Control, n0:Read, n0:Write.
:16200627777242747520251968627
    a n0:Authorization;
    n0:accessTo tes:;
    n0:agent c:me;
    n0:mode n0:Control, n0:Read, n0:Write.
:16200627777336972880372581038
    a n0:Authorization;
    n0:agentClass n1:Agent;
    n0:default tes:;
    n0:mode n0:Read, n0:Write.
:16200627777355729480738631167
    a n0:Authorization;
    n0:accessTo tes:;
    n0:agentClass n1:Agent;
    n0:mode n0:Read, n0:Write.
  1. Now, run setAcl again as follows:
await setAcl("https://pod.example/folder/", {
  "https://jackson.solidcommunity.net/profile/card#me": {
    "read": true,
    "write": true,
    "append": true,
    "control": true,
  },
  "public": {
    "read": true,
    "write": true,
    "append": true,
    "control": false,
  },
  "https://jackson2.inrupt.net/profile/card#me": {
    "read": true,
    "write": true,
    "append": true,
    "control": true,
  }
});
  1. The ACL now looks like:
@prefix : <#>.
@prefix n0: <http://www.w3.org/ns/auth/acl#>.
@prefix c: </profile/card#>.
@prefix tes: <./>.
@prefix n1: <http://xmlns.com/foaf/0.1/>.
@prefix c0: <https://jackson2.inrupt.net/profile/card#>.

:16200627777229416622674554878
    a n0:Authorization;
    n0:agent c:me;
    n0:default tes:;
    n0:mode n0:Control, n0:Read, n0:Write.
:16200627777242747520251968627
    a n0:Authorization;
    n0:accessTo tes:;
    n0:agent c:me;
    n0:mode n0:Control, n0:Read, n0:Write.
:16200627777336972880372581038
    a n0:Authorization;
    n0:agentClass n1:Agent;
    n0:default tes:;
    n0:mode n0:Read, n0:Write.
:16200627777355729480738631167
    a n0:Authorization;
    n0:accessTo tes:;
    n0:agentClass n1:Agent;
    n0:mode n0:Read, n0:Write.
:16200630181165886215561149628
    a n0:Authorization;
    n0:agent c:me;
    n0:default tes:;
    n0:mode n0:Control, n0:Read, n0:Write.
:162006301811724778766789878337
    a n0:Authorization;
    n0:accessTo tes:;
    n0:agent c:me;
    n0:mode n0:Control, n0:Read, n0:Write.
:16200630181229927508212065623
a n0:Authorization; n0:agent c0:me; n0:default tes:; n0:mode n0:Read, n0:Write.
:16200630181237677687525331884
a n0:Authorization; n0:accessTo tes:; n0:agent c0:me; n0:mode n0:Read, n0:Write.
:162006301813334106972307351047
    a n0:Authorization;
    n0:agentClass n1:Agent;
    n0:default tes:;
    n0:mode n0:Read, n0:Write.
:162006301813808167874828088695
    a n0:Authorization;
    n0:accessTo tes:;
    n0:agentClass n1:Agent;
    n0:mode n0:Read, n0:Write.

Notice that instead of ignoring the authorization rule for c:me and n1:Agent, it duplicated them. This can lead to a lot of unnecessary triples and was the reason for inrupt.net crashing last week.

Expected result

When setAgentResourceAccess (or friends) is called with a WebId that already exists, it will simply update (or ignore if they are identical) existing rules rather than adding new ones.

Actual result

New rules are added.

Environment

$ npx envinfo --system --npmPackages --binaries --npmGlobalPackages --browsers
System:
    OS: macOS 11.3
    CPU: (8) x64 Intel(R) Core(TM) i5-1038NG7 CPU @ 2.00GHz
    Memory: 119.89 MB / 16.00 GB
    Shell: 5.8 - /bin/zsh
  Binaries:
    Node: 15.2.1 - /usr/local/bin/node
    npm: 7.0.10 - /usr/local/bin/npm
    Watchman: 4.9.0 - /usr/local/bin/watchman
  Browsers:
    Chrome: 90.0.4430.93
    Firefox: 88.0
    Safari: 14.1
  npmPackages:
    @inrupt/solid-auth-fetcher: jaxoncreed/solid-auth-fetcher-fork#master => 0.0.6 
    @inrupt/solid-client: ^1.0.0 => 1.6.1 
    @inrupt/solid-client-authn-browser: ^1.0.0 => 1.8.0 
    @rdfjs/fetch: ^2.1.0 => 2.1.0 
    @types/bluebird: ^3.5.33 => 3.5.33 
    @types/clownface: ^1.0.1 => 1.2.0 
    @types/cookie-parser: ^1.4.2 => 1.4.2 
    @types/cors: ^2.8.7 => 2.8.10 
    @types/express: ^4.17.8 => 4.17.11 
    @types/express-session: ^1.17.0 => 1.17.3 
    @types/ioredis: ^4.17.8 => 4.26.0 
    @types/jest: ^26.0.14 => 26.0.22 
    @types/jsonschema: ^1.1.1 => 1.1.1 
    @types/mongodb: ^3.6.0 => 3.6.12 
    @types/multer: ^1.4.5 => 1.4.5 
    @types/node-cron: ^2.0.3 => 2.0.3 
    @types/node-fetch: ^2.5.7 => 2.5.10 
    @types/parse-link-header: ^1.0.0 => 1.0.0 
    @types/rdfjs__dataset: ^1.0.4 => 1.0.4 
    @types/rdfjs__fetch: ^2.0.2 => 2.0.2 
    @types/rdfjs__parser-n3: ^1.1.3 => 1.1.3 
    @types/socket.io: ^2.1.11 => 2.1.13 
    @types/url-parse: ^1.4.3 => 1.4.3 
    @types/uuid: ^8.3.0 => 8.3.0 
    @types/web-push: ^3.3.0 => 3.3.0 
    @types/ws: ^7.4.0 => 7.4.1 
    @typescript-eslint/eslint-plugin: ^4.2.0 => 4.22.0 
    @typescript-eslint/parser: ^4.2.0 => 4.22.0 
    bluebird: ^3.7.2 => 3.7.2 
    body-parser: ^1.19.0 => 1.19.0 
    clownface: ^1.0.0 => 1.2.0 
    cookie: ^0.4.0 => 0.4.1 
    cookie-parser: ^1.4.5 => 1.4.5 
    cors: ^2.8.5 => 2.8.5 
    dotenv: ^8.2.0 => 8.2.0 
    eslint: ^7.10.0 => 7.25.0 
    eslint-config-prettier: ^6.12.0 => 6.15.0 
    eslint-plugin-prettier: ^3.1.4 => 3.4.0 
    expo-server-sdk: ^3.6.0 => 3.6.0 
    express: 5.0.0-alpha.8 => 5.0.0-alpha.8 
    express-session: ^1.17.1 => 1.17.1 
    ioredis: ^4.19.2 => 4.26.0 
    jest: ^26.4.2 => 26.6.3 
    jsonschema: ^1.4.0 => 1.4.0 
    jsonwebtoken: ^8.5.1 => 8.5.1 
    mongodb: ^3.6.3 => 3.6.6 
    multer: ^1.4.2 => 1.4.2 
    n3: ^1.6.4 => 1.9.0 
    node-cron: ^2.0.3 => 2.0.3 
    node-fetch: ^2.6.1 => 2.6.1 
    onesignal-node: ^3.2.0 => 3.2.1 
    prettier: ^2.1.2 => 2.2.1 
    socket.io: ^3.0.3 => 3.1.2 
    socket.io-client: ^3.0.3 => 3.1.3 
    ts-node: ^9.0.0 => 9.1.1 
    ts-node-dev: ^1.0.0-pre.63 => 1.1.6 
    typescript: ^4.1.2 => 4.2.4 
    url-parse: ^1.4.7 => 1.5.1 
    uuid: ^8.3.2 => 8.3.2 
    web-push: ^3.4.4 => 3.4.4 
    ws: ^7.4.0 => 7.4.5 
  npmGlobalPackages:
    @paciolan/remote-component: 0.0.0-semantic-versioning
    @paciolan/remote-module-loader: 1.0.0-symantec-versioning
    @solid/oidc-auth-manager: 0.24.1
    @solid/oidc-op: 0.11.1
    componentsjs-generator: 1.6.0
    dts-gen: 0.6.0
    expo-cli: 4.0.16
    http-server: 0.12.3
    jest: 26.6.3
    nodemon: 2.0.6
    npm-check-updates: 10.2.2
    npm: 6.14.9
    ochat-api: 1.0.0
    oidc-provider: 6.29.8
    react-dom: 16.13.1
    react: 16.13.1
    ts-node-dev: 1.0.0
    ts-node: 9.0.0
    typescript: 4.1.2

Enhance file fetching with `ResourceInfo` and optional `ACL`

Search terms you've used

File, ACL, ResourceInfo

Is your feature request related to a problem? Please describe.

When fetching a LitDataset, the information associated to the Resource is returned by the fetcher, while this information must be read manually in the Response returned by fetchFile. There is also an alternative fetchLitDatasetWithAcl function that do net exist for files.

Describe the solution you'd like

  1. Make it so that fetchFile returns the information attached to the fetched file
  2. Add a function to fetch both a file and its ACL

Describe alternatives you've considered

Do all the operations manually by parsing the headers and sending additional requests.

Finding Thing(s) given some criteria

Hi there! Hope I'm using the right template for this question 😀

Search terms you've used

query, find

What problem are you trying to solve? Please describe.

Almost every application needs to find data matching some specific criteria (some object containg a string, an integer range, and so on...) and I would like to know what this library will provide in the future? I don't want to retrieve all Thing locally to evaluate some predicate and filter client side and I'm thinking about using SPARQL queries to ask the server to do the hard job for us but maybe there's another nifty way.

I'm aware that, as of now, the support for SPARQL in the Solid spec is already being discussed...

What existing documentation is relevant to your problem, and why is it insufficient?

https://docs.inrupt.com/client-libraries/solid-client-js/tutorial/read-write-data.html#read-data
https://docs.inrupt.com/client-libraries/solid-client-js/api/modules/_thing_get_.html

Additional context

This question arise because I'm building a tiny library depending only on @inrupt/solid-client to make the mapping between my javascript objects and triples easier and more pleasant to work with and making easy and efficient to query for data with specific criteria is a must have.

Constructing and making a SPARQL query against a Solid document works like a charm, I can get back some turtle but since the function turtleToTriples is marked as internal, I can't use it and need to duplicate it on my side and this is why I'm here to see if there's another take on your side for this problem.

I will make the repo public as soon as my public API is done.

Thanks for reading me and this library BTW 👍

Rename `Struct`s

@pmcb55 indicated that he didn't think it added much value to use a suffix to indicate when types are not expected to occur independently. Additionally, he prefers ChangeLog over Diff, and SolidMetadataDatasetInfo over Metadata. Thus, we could rename the Structs as follows:

  • DiffStruct -> ChangeLog
  • MetadataStruct -> DatasetInfo

Add type of Resource to ResourceInfo

Search terms you've used

RDF, binary, file.

Is your feature request related to a problem? Please describe.

Trying to fetch a non-RDF Resource with fetchLitDataset will fail. If we are dynamically discovering a Resource (e.g. in Pod Manager), we need to be able to figure out in advance what function to call.

Describe the solution you'd like

Apparently we can check whether something is an ldp:RDFSource or ldp:NonRDFSource, which we could expose in ResourceInfo.

Describe alternatives you've considered

We can also do a request with a Content-Type specified, which supposedly returns a 406.

Additional context

https://github.com/inrupt/pod-manager/pull/20#issuecomment-645437906

#203

It could also be useful to distinguish between a Container and a non-Container (i.e. by checking for a trailing slash).

Add timestamp to notifications

Search terms you've used

Notification, Timestamp

Is your feature request related to a problem? Please describe.

When building a notification, the provenance information only contains the notification actor, but not the time where the notification was created. This would be an issue when processing notifications as a chronological stream of events.

Describe the solution you'd like

Have the library add a notification timestamp when building the notification, without requiring any input from the caller.

Describe alternatives you've considered

Have the caller provide the timestamp, or not add a timestamp at all.

Use @inrupt/lit-generated-vocab-solid-common

In constants.ts we have a number of IRI's of specific namespaces. The package @inrupt/lit-generated-vocab-solid-common has now been published to npm and includes those same constants, so let's use those instead and verify how much that impacts bundle sizes.

Re-enable CI on OS X and Windows

Once this repository is made public, we should re-enable the CI runs on OS X and Windows, which were disabled in #50. (The reason was that they're relatively expensive, but they're free for public repositories.)

Error when building angular app with solid-client: Module '"../constants"' has no exported member 'acp'

Search terms you've used

inrupt module acp

Bug description

npm error when building application with "@inrupt/solid-client": "^1.0.0", using angular's ng build

To Reproduce

  1. generate new angular app (https://angular.io/tutorial/toh-pt0, ng new solid-error)
  2. add solid-client (based on https://docs.inrupt.com/developer-tools/javascript/client-libraries/tutorial/getting-started/, npm install @inrupt/solid-client @inrupt/solid-client-authn-browser @inrupt/vocab-common-rdf)
  3. use import {getSolidDataset, getStringNoLocale, getThing} from '@inrupt/solid-client'; in a component
  4. run app (ng serve)

Expected result

application gets built without error and starts

Actual result

the following error occurs:
ERROR in node_modules/@inrupt/solid-client/dist/acp/control.d.ts:21:10 - error TS2305: Module '"../constants"' has no exported member 'acp'.

Environment

$ npx envinfo --system --npmPackages --binaries --npmGlobalPackages --browsers

  System:
    OS: Windows 10 10.0.19041
    CPU: (16) x64 Intel(R) Core(TM) i9-9980HK CPU @ 2.40GHz
    Memory: 17.01 GB / 31.71 GB
  Binaries:
    Node: 12.18.3 - C:\Program Files\nodejs\node.EXE
    npm: 6.14.8 - C:\Program Files\nodejs\npm.CMD
  Browsers:
    Edge: Spartan (44.19041.423.0), Chromium (86.0.622.69)
    Internet Explorer: 11.0.19041.1
  npmPackages:
    @angular-devkit/build-angular: ~0.1001.7 => 0.1001.7
    @angular/animations: ~10.1.6 => 10.1.6
    @angular/cli: ~10.1.7 => 10.1.7
    @angular/common: ~10.1.6 => 10.1.6
    @angular/compiler: ~10.1.6 => 10.1.6
    @angular/compiler-cli: ~10.1.6 => 10.1.6
    @angular/core: ~10.1.6 => 10.1.6
    @angular/forms: ~10.1.6 => 10.1.6
    @angular/platform-browser: ~10.1.6 => 10.1.6
    @angular/platform-browser-dynamic: ~10.1.6 => 10.1.6
    @angular/router: ~10.1.6 => 10.1.6
    @inrupt/solid-client: ^1.0.0 => 1.0.0
    @inrupt/solid-client-authn-browser: ^1.0.0 => 1.0.0
    @inrupt/vocab-common-rdf: ^0.6.3 => 0.6.3
    @types/jasmine: ~3.5.0 => 3.5.14
    @types/jasminewd2: ~2.0.3 => 2.0.8
    @types/node: ^12.11.1 => 12.19.4
    codelyzer: ^6.0.0 => 6.0.1
    jasmine-core: ~3.6.0 => 3.6.0
    jasmine-spec-reporter: ~5.0.0 => 5.0.2
    karma: ~5.0.0 => 5.0.9
    karma-chrome-launcher: ~3.1.0 => 3.1.0
    karma-coverage-istanbul-reporter: ~3.0.2 => 3.0.3
    karma-jasmine: ~4.0.0 => 4.0.1
    karma-jasmine-html-reporter: ^1.5.0 => 1.5.4
    protractor: ~7.0.0 => 7.0.0
    rxjs: ~6.6.0 => 6.6.3
    ts-node: ~8.3.0 => 8.3.0
    tslib: ^2.0.0 => 2.0.3
    tslint: ~6.1.0 => 6.1.3
    typescript: ~4.0.2 => 4.0.5
    zone.js: ~0.10.2 => 0.10.3
  npmGlobalPackages:
    @angular/cli: 10.1.7
    npm: 6.14.8
    windows-build-tools: 5.2.2

Additional information

I've created a sample angular project with the error: https://github.com/WhyINeedToFillUsername/solid-error

  • check it out, run npm install and ng serve

Considerations before 1.0 release

In this issue we can keep track of issues that arose in reviews, the resolution of which might affect our public API.

  • ThingPersisted/ThingLocal - might be better to rename these, since the former needn't actually be persisted.
  • "metadata" - the code refers to metadata, when really it's referring to our specific metadata (e.g. where a LitDataset was fetched from). Thus, maybe we need to rename it to differentiate it from other types of metadata that the user might add to a Dataset by calling it, say "LitMetadata"? (And LitMetadataStruct and hasLitMetadata, etc.)
  • *Struct - I'm not sure if that's an appropriate name for the properties that an object might have (e.g. DiffStruct).

Fetching the fallback ACL should not throw an error when the Container is not Readable

Search terms you've used

fallback ACL, container, error, 404

Describe the bug

When trying to fetch the fallback ACL, when the current user does not have Read access to one of the parent Containers, functions that fetch the ACL will throw an error, whereas if fetching that Container's ACL fails (because the current user does not have Control access), it just sets the fallback ACL to null because it couldn't be fetched.

Instead, not being able to get the location of the fallback ACL should also result in null instead of an error, because it, too, indicates that the fallback ACL is not available.

To Reproduce
Steps to reproduce the behavior:

  1. Create a Container.
  2. Add an ACL to that Container that gives a given user Read and Control access to its children, but not to the Container itself.
  3. Create a Resource inside that Container.
  4. When logged in as that user, call getSolidDatasetWithAcl() on that Resource.

CodeSandbox

https://codesandbox.io/s/black-butterfly-cbsh3?fontsize=14&hidenavigation=1&theme=dark

Expected behavior

The fetched Resource should not have a fallback ACL available, but it should not throw an error either.

Log output

See CodeSandbox.

Environment

Only attempted to reproduce in the CodeSandbox.

Additional context

Discovered when investigating this question: https://gitter.im/solid/app-development?at=5f894e52bbffc02b581d264c

getUrl(resource, AS.type)

hi !
I absolutely don't understand why a getUrl or getNamedNode throw me an error with https://www.w3.org/ns/activitystreams#type

the doc is build with Tripledoc at https://agora.solid.community/public/popock/inbox/
with https://github.com/scenaristeur/solid-vue-panes/blob/71668f80aa41c26f8cf9171cc0d24f07ab262d12/src/components/agora/Agora.vue#L104

  let activityDoc = {}
    try{
      activityDoc = await fetchDocument(fileUrl);
    }catch(e){
      activityDoc = await createDocument(fileUrl);
    }

    console.log("webId",this.webId)
    let autoSummary = [this.activity.actor.name, this.activity.type, "a", this.activity.object.type, "with name", this.activity.object.name].join(" ")
    console.log("Musr create outbox object first, then activity !",activityDoc, messageId, date)
    let subj =   activityDoc.addSubject({identifier:messageId})
    //subj.addLiteral(sioc.content, this.activity)
    subj.addLiteral(rdfs.label, autoSummary)
    subj.addLiteral(dct.created, date)
    subj.addRef(foaf.maker, this.webId)
    subj.addRef('https://www.w3.org/ns/activitystreams#actor', this.webId)
    subj.addRef(rdf.type, 'https://www.w3.org/ns/activitystreams#'+this.activity.type)
    subj.addLiteral('https://www.w3.org/ns/activitystreams#summary', this.activity.summary)
    subj.addRef('https://www.w3.org/ns/activitystreams#type', 'https://www.w3.org/ns/activitystreams#'+this.activity.type)
    subj.addLiteral('https://www.w3.org/ns/activitystreams#object', "test"+this.activity.object)
    await activityDoc.save();

then i can retrieve all that data , but not AS.type , with the code :
https://github.com/scenaristeur/solid-vue-panes/blob/71668f80aa41c26f8cf9171cc0d24f07ab262d12/src/components/agora/ActivityItem.vue#L41

  this.label = getStringNoLocale(this.activity, RDFS.label);
      this.created = getStringNoLocale(this.activity, DCTERMS.created);
      this.summary = getStringNoLocale(this.activity, AS.summary);
      this.object = getStringNoLocale(this.activity, AS.object);
      console.log("Summary",this.summary)
      this.maker = getUrl(this.activity, FOAF.maker);
      console.log("maker", this.maker)
      this.actor = getUrl(this.activity, AS.actor);
      console.log("actor",this.actor)
      this.type = getUrl(this.activity, RDF.type);
      console.log("type", this.type)
      /* THE CODE AFTER THROW ERROR
    */
      this.type2 = getUrl(this.activity, AS.type);
      console.log("type AS", this.type2)

image

the online demo is https://scenaristeur.github.io/solid-vue-panes/agora

If i do something wrong, I absolutely does not know what

unstable_fetchResourceInfoWithAcl does not return type information, or webIds for ACL

The new API for fetching resource information without a full request (unstable_fetchResourceInfoWithAcl) does not return the information needed for our use-case. Currently it does not return the type information of the given resource and it appears to have a simplified ACL.

The desired information received from this call the following:

  • The type of the resource
  • All permissions granted to the resource and the webIds associated with the permissions (so we can display profile info for each permitted party)
  • Fallback permissions

If I were to put this data into a JSON object, it would look something like this:

{
  "type": "http://www.w3.org/ns/ldp#BasicContainer",
  "acl": {
    "https://dayton.dev.inrupt.net/profile/card#me": {
      "read": true,
      "write": true,
      "append": true,
      "control": true,
    },
    "https://ajacksified-dev.dev.inrupt.net/profile/card#me": {
      "read": true,
      "write": true,
      "append": true,
      "control": false,
    },
    "fallbackAcl": {
      "read": true,
      "write": false,
      "append": false,
      "control": false,
    }
  }

}

Include GET headers in dataSet object (Especially eTag)

It would be great if the dataset could harvest the headers as an object, maybe dataset.headers. Our particular case is we need to check the eTag in the header to see if a resource has been updated since last load, and then we wouldn't need to do an additional HEAD after loading the dataset to get that header.

The other information we need from the headers is whether or not a redirect occurred, and if so, what the redirected uri is.

Remove unstable_ prefix for unstable functions

Concerns have been raised that unstable_ looks unprofessional. It was intended to make it easier to migrate when the function signature changes later; instead, we'll preserve the deprecated functions with a _deprecated suffix when we introduce replacements, so a stopgap migration could always be a simple search-and-replace.

The experimental status of an API should still be highlighted in the API documentation as follows:

The use of the $_ prefix indicates that this function is pre version 1.0 and there is a possibility the function signature will change.

Additionally, we'll mark the internal_ functions using just _, i.e. the relatively common convention of Hungarian notation for private functions.

Use `If-None-Match` header when saving a file

Currently, unstable_overwriteFile(fileUrl: RequestInfo, file: Blob, options explicitly overwrites any data at the provided URL. A more subtle behaviour would be to change it to unstable_saveFile(fileUrl: RequestInfo, file: Blob, options), with options including a parameter overwrite: boolean set to true by default (to be consistent with the default behaviour of unstable_overwriteFile that would be replaced by unstable_saveFile).

Under the cover, the library would set the If-None-Match header for the server to check if a resource already exists at the provided URL.

This feature should coordinate with nodeSolidServer/node-solid-server#1431.

in "Getting Started: Part 1", in step 5 "Run the Application" we get a regex error

Search terms you've used

Pasted the error into DucDuckGo search engine

Bug description

Regex error:
SyntaxError: Invalid regular expression: /(\p{Uppercase_Letter}+|\p{Lowercase_Letter}|\d)(\p{Uppercase_Letter}+)/: Invalid escape

To Reproduce

  1. Go to Documentation: Introduction: "Getting Started: Part 1"
  2. Complete all steps to Step 5
  3. In Step 5. Run the Application, we get the error

Minimal reproduction

Expected result

execute "npm run build && npm run start"

Result should be

ℹ 「wds」: Project is running at http://localhost:8080/
...
ℹ 「wdm」: Compiled successfully.

Actual result

$ npx envinfo --system --npmPackages --binaries --npmGlobalPackages --browsers

System:
OS: macOS 10.15.7
CPU: (8) x64 Intel(R) Core(TM) i7-4870HQ CPU @ 2.50GHz
Memory: 113.56 MB / 16.00 GB
Shell: 5.7.1 - /bin/zsh
Binaries:
Node: 8.9.1 - /usr/local/bin/node
Yarn: 1.3.2 - /usr/local/bin/yarn
npm: 6.14.8 - /usr/local/bin/npm
Browsers:
Chrome: 86.0.4240.198
Firefox: 77.0.1
Safari: 14.0
npmPackages:
@inrupt/solid-client: ^1.0.0 => 1.0.0
@inrupt/solid-client-authn-browser: ^1.0.0 => 1.0.0
@inrupt/vocab-common-rdf: ^0.6.3 => 0.6.3
css-loader: ^5.0.1 => 5.0.1
style-loader: ^2.0.0 => 2.0.0
webpack: ^5.4.0 => 5.4.0
webpack-cli: ^4.2.0 => 4.2.0
webpack-dev-server: ^3.11.0 => 3.11.0
npmGlobalPackages:
@angular/cli: 1.6.2
composer-playground: 0.20.7
generator-blockstack: 0.1.9
npm: 6.14.8
remix-ide: 0.6.4
yo: 2.0.0

Additional information

400 Bad Request when storing a SolidDataset

Search terms you've used

400 Bad Request, changelog, empty delete

Bug description

The request does not seem to match the changelog.

Source: https://forum.solidproject.org/t/curious-400-error-when-removing-using-inrupt/4163

image

To Reproduce

Not sure yet, will investigate...

Minimal reproduction

Not reproduced yet.

Expected result

SolidDataset to be saved properly.

Actual result

400 Bad Request.

Environment

$ npx envinfo --system --npmPackages --binaries --npmGlobalPackages --browsers

Additional information

createAclFromFallbackAcl copies over a `default` block that confuses NSS

When using createAclFromFallbackAcl on a document, it copies over acl:default triples (which only apply to containers), which it seems to do so by creating separate blocks for acl:accessTo and acl:default.
This confuses NSS, which then blocks access to the document under certain circumstances.

Create migration guide for existing libraries

Search terms you've used

Migration guide, LDflex, Tripledoc, rdflib, Soukai, rdf-easy,

What problem are you trying to solve? Please describe.

There are a number of other libraries out there that are already used to manipulate data on a Solid Pod. Some people might want to migrate their code from that to lit-pod. Documentation on how to do that could be helpful.

What existing documentation is relevant to your problem, and why is it insufficient?

https://vincenttunru.gitlab.io/tripledoc/docs/cheatsheet

But that doesn't list lit-solid.

Additional context

N/A

The async litDataset methods manipulate the input LitDataset

Search terms you've used

immutability, LitDataset, Resource, ACL

Describe the bug

The async methods in litDataset.ts (or, if #161 gets implemented first, also the Resource-specific async methods) use Object.assign() to add metadata returned from the call to the Pod to the input Resource. However, Object.assign() also changes its first argument.

Normally, you'd solve that by passing an empty object as the first argument, and shift the other arguments one position. However, because LitDatasets actually are a class, that's not sufficient here, IIRC because the prototype chain doesn't get copied over.

As an additional complexity, some of these methods (specifically, saveAclFor() and deleteAclFor()) only operate on the metadata, and should hence work on both LitDatasets and, after #219, regular files.

Presumably, the solution here is to check whether a Resource is a file, in which case the file should be cloned in whatever way is appropriate, if it's a LitDataset, in which case it should use clone() from rdfjs.ts, or just metadata, in which case we can just initialise an empty object. Then, cloneLitStructs (which should probably be renamed as well, since we no longer use the term Struct) should be modified to operate on the resulting clone to copy over the relevant properties from the input Resource.

To Reproduce
Call saveLitDatasetAt() with a changed LitDataset. Afterwards, check .changeLog on the input LitDataset. Instead of still listing the changes that were applied to it, it is now empty.

Expected behavior

It should still list the changes applied before saving it.

package path not exported for 'access/universal'

When using the @inrupt/solid-client library in a NodeJS back-end, I'm getting the following stacktrace when adding this line:

import { setPublicAccess } from '@inrupt/solid-client/dist/access/universal'

I haven't seen this problem when using the solid-client in the front-end, only now when using it in back-end. I'm using TypeScript (v4.2)

@inrupt/solid-client version is 1.6.1

Stacktrace is:

internal/modules/cjs/loader.js:450
      throw e;
      ^

Error [ERR_PACKAGE_PATH_NOT_EXPORTED]: Package subpath './dist/access/universal' is not defined by "exports" in /Users/andries/projects/consolidate/survey-aggregator/node_modules/@inrupt/solid-client/package.json
    at throwExportsNotFound (internal/modules/esm/resolve.js:285:9)
    at packageExportsResolve (internal/modules/esm/resolve.js:491:3)
    at resolveExports (internal/modules/cjs/loader.js:444:36)
    at Function.Module._findPath (internal/modules/cjs/loader.js:484:31)
    at Function.Module._resolveFilename (internal/modules/cjs/loader.js:818:27)
    at Function.Module._load (internal/modules/cjs/loader.js:687:27)
    at Module.require (internal/modules/cjs/loader.js:903:19)
    at require (internal/modules/cjs/helpers.js:74:18)
    at Object.<anonymous> (/Users/andries/projects/consolidate/survey-aggregator/dist/modules/survey/SurveyCreatorService.js:11:21)
    at Module._compile (internal/modules/cjs/loader.js:1015:30) {
  code: 'ERR_PACKAGE_PATH_NOT_EXPORTED'
}

Rename to @solid/lit-pod

  • Update CI scripts to publish to new package name
  • Do not forget to update the cd_teardown script from #132 as well
  • Mark the old package as deprecated.

Reading a Thing from a blank node in a SolidDataset

Search terms you've used

I've searched the issues on this repo and the solid community forum for posts referring to "blank node"

The getThing documentation has a variation for getting a Thing from a URL, and one for a LocalNode which may be the right track

Feature suggestion

I have a SolidDataset containing a blank node as the object of a triple and I want to be able to read it, ultimately into a ThingLocal object

Expected functionality/enhancement

If it wasn't a blank node, I could do this:

const newThing: Thing = getThing(dataset, getUrl(thing, property));

My dream would be something more intuitive and similar to Jena:

const newThing: Thing =  thing.getPropertyResourceValue(property);

Actual functionality/enhancement

I find that getUrl returns null because it's not a valid URL which throws an error

Use Cases

I make a request to the server which returns content in Turtle format. I'm able to parse that data into a SolidDataset containing the following Quad entry:

object: BlankNode {id: "_:n3-3"}
predicate: NamedNode {id: "..."}
subject: NamedNode {id: "..."}

Additional information

I'm in control of this server endpoint so I don't have to return the resource with a blank node - I'll workaround this issue by returning the object as a named node

404s on ACLs throw an error

Search terms you've used

ACL, 404, rejects Promise, throws error.

Describe the bug

When I call fetchLitDatasetWithAcl and the request to fetch an ACL file results in a 404 (which is an expected situation, e.g. when the user does not have Control access), then instead of the acl being null, it appears that it throws an error/rejects the Promise.

To Reproduce
Steps to reproduce the behavior:

const resource = await unstable_fetchLitDatasetWithAcl('https://dayton.dev.inrupt.net/public/');
const acl = unstable_getAgentAccessModesAll(resource);

This supposedly throws.

Expected behavior

For resource to just be the Resource with acl: { resourceAcl: null; fallbackAcl: null }.

Log output

image

Additional context

Reproduced from this report: https://github.com/inrupt/pod-manager/pull/20#issuecomment-645535608

Changelogs get out of sync with the Pod

Search terms you've used

Storing the Resource failed: 409 Conflict., changelog, deletions

Describe the bug

When adding something to a LitDataset and later removing it again, the respective Quads are added to both the list of additions and the list of deletions. However, because the Quads never existed on the Pod, when lit-pod then tries to do a PATCH, the server responds with a 409 Conflict because it tried to delete data that wasn't there.

To Reproduce
Steps to reproduce the behavior:

  1. Fetch a LitDataset.
  2. Add a new Thing with some data.
  3. Remove that Thing.
  4. Try to save it.

Expected behavior

The save is a successful no-op PATCH request.

Log output

N/A

Environment

$ npx envinfo
Screw you Vincent you know what your environment is.

Additional context

The solution here is probably to remove duplicates between additions and deletions when modifying the changelog.

Expose status codes and error messages on errors

Search terms you've used

HTTP status codes, error message.

Is your feature request related to a problem? Please describe.

When calling a function that reads or writes data (e.g. getSolidDataset or overwriteFile), the server can return an error, which solid-client then throws and exposes in the error message. However, the error message cannot be relied upon to reliably get access to what in particular went wrong.

Describe the solution you'd like

The error object that gets thrown in functions that make HTTP requests also exposes a property containing at least the status code and the status message, and possibly the entire Response object.

Describe alternatives you've considered

Manually parsing the error message for the expected status code.

Additional context

N/A

Allow getting *any* RDF node

Search terms you've used

getNamedNodeOne, getNamedNodeAll. getLiteralOne, getLiteralAll

Is your feature request related to a problem? Please describe.

If the developer has or wants to work with RDF/JS data types, we currently only provide get/add/set functions for Literals and NamedNodes directly, but not a generic Term.

Describe the solution you'd like

Addition of escape hatch functions (i.e. marked as @hidden, but available):

  • getTermOne
  • getTermAll
  • setTerm
  • addTerm

Describe alternatives you've considered

Just forcing developers to use native RDF/JS libraries if they want to work with them, or to only work with NamedNodes and Literals (because boo BlankNodes :P).

Additional context

N/A

Add ability to get parsed file metadata

Search terms you've used

File metadata, ACL, resource ACL.

Is your feature request related to a problem? Please describe.
If I want to know what permissions the user has w.r.t. a plain file, I currently have to manually parse the Response Headers. Whereas when I fetch an RDF resource, I can use both the ACL-reading methods, or read the parsed WAC-Allow statements.

Describe the solution you'd like
For getFile to return an object that has the blob as a property, but also LitDatasetInfo.

Describe alternatives you've considered
A separate fetchFileInfo (or perhaps fetchResourceInfo) would also work, that does a HEAD request (and possibly fetchFileInfoWithACL). This could also work for Resource of which we don't need to inspect the contents.

Additional context
See this PR of Pod Manager where they had to write the WAC-Allow parsing code themselves, meaning they'll now manually have to keep up with the spec. (Direct link to source code.)

Make it possible to read access permissions without fetching a Resource

Search terms you've used

ACL, Resource, HEAD

Is your feature request related to a problem? Please describe.

Currently, the functions reading access permissions expect a resource as a parameter (e.g.

unstable_getAgentAccessModesOne(
  dataset: LitDataset & ResourceWithInfo & unstable_Acl,
  agent: WebId
): unstable_AccessModes | null

while really only the resource information and the ACL is required here, and not the Resource itself.

Describe the solution you'd like

Make it unnecessary to provide a Resource (be it a Blob or a LitDataset) when reading access permissions.

Describe alternatives you've considered

Mock up the Resource: unstable_getAgentAccessModesOne({acl: myAcl, resourceInfo: MyResourceInfo}.

Additional context

Now that we have implemented features to access only resource information, without the resource itself, these functions should evolve to support new use cases.

Complete README

Once the documentation is ready and we've settled on a name and location for the API docs, the README (and homepage in package.json) should be updated to point there.

(Or alternatively, we should create an issue about moving the API docs, and make sure that "update the README" is in there.)

solid-client doesn't PATCH unchanged SolidDatasets

Search terms you've used

412 Precondition failed

Bug description

solid-client doesn't initialise an empty ChangeLog for fetched SolidDatasets, leading to saveSolidDatasetAt() not recognising that it needs to send an empty PATCH request rather than a PUT when saving back that SolidDataset unchanged.

To Reproduce

  1. Fetch a dataset from an ESS Pod with getSolidDataset
  2. Immediately save it to the same location (assuming you have permissions to) using saveSolidDatasetAt
  3. Observe the 412 Precondition Failed

NSS doesn't appear to enforce the precondition and therefore does not run into this.

Minimal reproduction

This should be a reproduction, but I since I wasn't able to make it publicly writeable so far it's not: https://codesandbox.io/s/async-dream-2j4bp?file=/src/index.ts

Expected result

A successful (albeit useless) request.

Actual result

$ npx envinfo --system --npmPackages --binaries --npmGlobalPackages --browsers

This was first encountered by @ABhat00, I'm not sure what his environment was.

Additional information

Replace N3.js DataFactory with the @rdfjs/dataset one

Apparently @rdfjs/dataset does not just exports methods for the RDF/JS Dataset specification, but also a factory for the Data Model spec. So to make it easier to make N3.js optional later (e.g. when allowing the developer to replace it with their own set of parsers/serialisers), we can use the @rdfjs/dataset factory methods to instantiate Literals and NamedNodes.

Should we support deprecated predicate acl:defaultForNew?

Search terms you've used

acl, defaultForNew

Is your feature request related to a problem? Please describe.

I'm working on an app that uses acl/agent#unstable_getAgentAccessAll, and noticed that my app failed to load the default access controls for a resource. I realized the Pod I'm working on used a deprecated version of acl:default, namely acl:defaultForNew.

Describe the solution you'd like

This is not a bug per ce, but wondered if there is plans to support reading acl:defaultForNew? Could help some confussion by developers who've used the Solid systems for a while, and might still have uses of acl:defaultForNew hanging around.

Describe alternatives you've considered

If we don't want to support acl:defaultForNew, we might want to note that in the documentation.

Additional context

Don't think any extra context is required.

Use term `Quad` everywhere

Some variables in the code are currently called statement, whereas I've referred to the same things as "quads" elsewhere. I'll submit a PR that aligns this terminology throughout the codebase.

Match the `homepage` field in `package.json` with the actual homepage

Search terms you've used

Website, Homepage (for real this time)

What problem are you trying to solve? Please describe.

Once the place for the new documentation settles, it should be referenced in the package.json.

What existing documentation is relevant to your problem, and why is it insufficient?

The homepage currently advertized in the package.json is the GH repository, instead of the generated documentation.

Additional context

N/A

Test bug

Search terms you've used

This is a test bug

Describe the bug

To Reproduce
Steps to reproduce the behavior:

  1. Given this data:
  2. Call this function
  3. See error

CodeSandbox

Expected behavior

Log output

Environment

$ npx envinfo --system --npmPackages --binaries --npmGlobalPackages --browsers


Additional context

Align non-RDF functions return types with RDF ones

Search terms you've used

Non-RDF, Response

Is your refactoring request related to a problem? Please describe.

There is a mismatch between functions such as unstable_fetchFile, which returns a Promise<Response>, much like a regular fetch, and fetchLitDataset, which returns a Promise<LitDataset & WithResourceInfo>. There is a gap in abstraction between the two, and returning a plain Response puts more burden on the developer to extract relevant information from this response.

Describe the solution you'd like

Since #215 adds Content-Type to WithResourceInfo, which was initially missing and was a motivation to return a full Response for non-RDF files, the return type of should be unstable_fetchFile should be Promise<Blob & WithResourceInfo>.

Describe alternatives you've considered

Keep the current design, where the developers has to manually extract informations from the Response.

Additional context

Libraries depending on unstable_fetchFile will need to be updated accordingly.

Turtle manipulation/validation

Search terms you've used

Asked this question in Gitter chat. Was directed here to explain the use case.

Use Case

This is part question/feature-request.

I'm working on a prototype that extensively uses solid pods for storing/retrieving information.
Because I noticed most solid apps use schema names all over the place, I was trying to abstract away all the schema names, so potential app developers could work with datastructures without worrying about underlying schema's. In my case, I'm working on a project that involves Surveys. Based on the 'survey-ontology' (that can be found at https://cefriel.github.io/survey-ontology/docs/index.html), I'm in the process of creating a simple wrapper library to abstract away all the schema stuff (which is a public npm package for now: @consolidate/survey-ontology-ts. This package is Solid agnostic and its goals is to provide an interface for creating survey datastructures and don't worry about the underlying schemas: it can generate turtle files out of the survey you constructed with it.

However, I'm now noticing not every turtle file is solid compatible (or I'm building the wrong turtle files).
Whatever the case, I'm trying to convert my turtle files to valid SolidDatastructures. But there doesn't seem to be interfaces in the solid-client to deal with this. The only way to construct SOlidDatastructures is to use the interfaces provided by dealing with 'Quads' (which is part of the n3 library apparently).

Feature Request

It would certainly help to have some kind of 'processing' and/or 'validation' steps that can create SolidDatasets from turtle files directly. This would bypass the conversion from turtle >> quads >> load all quads in SolidDataset, and instead go directly from turtle >> SolidDataset. This could also potentially help if there is some build in validation of the provide turtlefile with helpfull messages regarding syntax and other errors.

(Another thing I noticed, is that, even though I'm able to add 'Quads' to an empty SolidDataset, that doesn't mean it's valid. When I try to save it to my solid-pod, I get a lot of errors telling me nothing was saved in the end without much further explanation. There is no build in 'validation'. You have to try and save it to know it's valid or not, but this validation step is maybe part of another feature request, so I'm leaving this here..)

Expected functionality/enhancement

Example usage:

try {
  const solidDataset = SolidDataset.fromTurtle("...")
} catch (e) {
  console.error("parsing errors: ", e)
}

So the fromTurtle could be a factory method:

class SolidDataset {
  static fromTurtle(input: string): SolidDataset
}

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.