What is a .meta on NSS?

Is .meta discussed in any spec? I haven’t seen it. One can’t do a GET on them. Are they even files in NSS, or are they something else? Do they get created automatically when a new resource is POSTed or PUT? Or are they created on-the-fly when needed?

I am asking in relation to recursiveCopy - should it be copying .meta files from the source to the destination?

Here is the spec I found about it: https://github.com/solid/solid-spec/blob/master/content-representation.md#metadata

And there are some issues regarding it too: https://github.com/solid/solid-spec/search?q=.meta&type=Issues

But I am not sure if that answers your question. I believe it should be copied, as it contains relevant and specific information about this resource:

“The metadata (extra RDF triples such as types, titles, comments, and so on) about non-RDF resources (e.g. containers, images, binaries, etc.) will be stored in a corresponding meta resource.”

I don’t think this information is automatically created by the server (except for some defaults maybe), so I would copy it too if possible.

1 Like

Ah great, thanks for the link to the spec. Here’s the rub though - since I can’t do a GET on them, how can I copy them? :slightly_smiling_face:

For example:

const auth = require('solid-auth-cli')
const file = 'https://jeffz.solid.community/public/likes.ttl.meta'

async function run(){
    await auth.login()
    await auth.fetch(file,{
        body:"<> a <#test>.",
    }).catch(e=>{console.log("Error : "+e)})
    let response = await auth.fetch(file).catch(e=>{console.log("Error : "+e)})
    console.log(response.status +" "+ response.statusText)
    console.log(await response.text())
/* output :                                                                               
404 Not Found                                                                             
Trying to access metadata file as regular file                                            

I don’t know if copying is possible. I think this issue would answer it, but hasn’t been updated in the last two weeks: https://github.com/solid/solid-spec/issues/168

This https://github.com/solid/solid-spec/issues/10 seems to give some clue how .ACL and .meta are accessible through HEADER with the same mechanism using IANA ontology to find the URI (acl or describedBy) and then if it exist you can copy it.

When copying from one pod to an other you must find in the destination HEADER the destination link that can be different from the source (depending from the implementation mechanism)

Yes I can easily read the header. The problem is that a GET does not work.

I can access .meta and .acl with solid-ide in the same way through the Url, but only if it exists and then edit them.
.meta and .acl works in the same way.

  • if the ressource do not exist it returns 404 error.
  • if exist you should be able to copy it

From trials, errors and access to the filesystem :

  • .meta ressource are automatically created when creating a folder with solid-ide then you can edit it with the about UI databrowser.
  • I did not find a way to create .meta for file ressources

nota : when creating a folder with the databrowser UI .meta are not created. What are the differences ???

1 Like

It appears that for folder .meta content appears in the turtle representation of the folder :

@prefix : <#>.
@prefix tes: <>.
@prefix ldp: <http://www.w3.org/ns/ldp#>.
@prefix terms: <http://purl.org/dc/terms/>.
@prefix XML: <http://www.w3.org/2001/XMLSchema#>.
@prefix st: <http://www.w3.org/ns/posix/stat#>.

    a ldp:BasicContainer, ldp:Container, :test;                **as you can see here with .meta content "<> a <#test>."**
    terms:modified "2019-05-24T08:27:31Z"^^XML:dateTime;
    st:mtime 1558686451.259;
    st:size 4096.
1 Like

Hmm, that is very interesting about putting the .meta in the folder’s turtle file. What produced that? a PUT on folder.meta?

I suppose that is what the about edit function from the databrowser UI does.

I’m hitting up against this at the moment in my development. This is definity not authoritative, but here is my thinking on the matter:

  1. Solid is based on LDP.
  2. LDP requires that a basic container has a tripet representation:
    e.g for a container called “photos” within “alice”:
@prefix ldp: <http://www.w3.org/ns/ldp#> .
@prefix dcterms: <http://purl.org/dc/terms/> .

<http://example.org/alice/photos/> a ldp:Container, ldp:BasicContainer;
  dcterms:title "Photos of Alice" ;
  dcterms:description "This container will contain photos of Alice." .  
  1. however, Solid is tied to the filesystem, so the above example would actually be represented as:
|- Alice
  |- Photos
    |- ...
  1. since it’s a directory on a file system, it has no associated triplet data (that i’m aware of).
  2. thus the .meta file is the triplet representation (and more) for the container.

If we look in the ldp.js class on NSS - we can see:

async readContainerMeta (url) {
    if (url[ url.length - 1 ] !== '/') {
      url += '/'
    return this.readResource(url + this.suffixMeta)

which i’m assuming helps in creating the RDF graph with the right container data

Edit: there is also a put method in the ldp.js file - which seems to create a .meta file for a contianer:

async post (hostname, containerPath, stream, { container, slug, extension, contentType }) {
    const ldp = this
    debug.handlers('POST -- On parent: ' + containerPath)


    // Containers should not receive an extension
    if (container) {
      extension = ''
    // TODO: possibly package this in ldp.post
    let resourceUrl = await ldp.getAvailableUrl(hostname, containerPath, { slug, extension })
    debug.handlers('POST -- Will create at: ' + resourceUrl)
    let originalUrl = resourceUrl
    if (container) {
      // Create directory by an LDP PUT to the container's .meta resource
      resourceUrl = `${resourceUrl}${resourceUrl.endsWith('/') ? '' : '/'}${ldp.suffixMeta}`
      if (originalUrl && !originalUrl.endsWith('/')) {
        originalUrl += '/'



Yes, currently if you PUT triples to /container/.meta, they will appear when you do a GET on /container/. These triples can apply to either the container or its contents. The databrowser uses this fact to display a container based on the triples in its metadata file.

solid-meta .

See the ongoing discussion on metadata.


Makes sense - and thanks for clarification!

Quick question: where’s the best location for these converations - this forum or Github?

My $0.02 - if your question is about how to do something or how the current software behaves, ask here or in the chat. If you want to discuss why things work the way they do or how they should work in the future, the github repos and W3 community group are a better location.