Some place to test RDF manual authoring?


#1

When I save RDF of a folder on the Solid data browser it returns me "Error saving back: Error: Web error: 409 (Conflict) on PUT of https://okilele.solid.community/A2/. Another topic mention this ("PUT not supported on containers, use POST instead”) ans sends you to Solid-iide.
So I went there but it returns a TimeOut on save.
I then tried China solid.authing.cn … and got to same 409 (Conflict error). By the way their Data Browser has more tools than the US one,
So where could I test manual RDF authoring ?


#2

Is your turtle valid ?
http://ttl.summerofcode.be/
Have you tried to put it in your ‘public’ folder?


#3

Someday maybe somebody will hook up one of those validators to a visualization…:grinning:


#4

@Smag0 Good idea the public folder. But makes no difference


#5

Turtle validator is ok, but I was quite sure of it.
The fact is I want to be sure Solid will accept the below RDF - what should not be a problem - and then I will be able to read it.
@prefix : <#>.
@prefix Book: <>.
@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#.

@prefix moat: http://moat-project.org/ns#.
@prefix foaf: http://xmlns.com/foaf/0.1/.
@prefix dbpedia: http://dbpedia.org/resource/.
@prefix Paris: http://tags.moat-project.org/tag/paris.

Book:
a ldp:BasicContainer, ldp:Container;
terms:modified “2019-10-27T19:34:18Z”^^XML:dateTime;
st:mtime 1572204858.678;
st:size 4096.

Paris:
a moat:Tag ;
moat:name “paris” ;
moat:hasMeaning [
a moat:Meaning ;
moat:meaningURI http://sws.geonames.org/2988507/ ;
foaf:maker http://example.org/alex/
] ;
moat:hasMeaning [
a moat:Meaning ;
moat:meaningURI http://sws.geonames.org/4402452/ ;
foaf:maker http://example.org/alex/ ;
foaf:maker http://myblog.net/user.rdf#me
] ;
moat:hasMeaning [
a moat:Meaning ;
moat:meaningURI dbpedia:Paris_Hilton ;
foaf:maker http://myblog.net/user.rdf#me
].


#7

AFAIK, the RDF for a Container is created by the server and not editable or updatable by user. You can add a new Container with POST, and you can delete a container, but the only way to modify the container is by adding resources with PUT or POST which automatically updates the Container’s RDF or by editing the .meta file for the container…


#8

the TTL isn’t validating for me because the URIs need to be within < > .


#9

@jeffz If I create a RDF doc using rdflib or TripleDoc that mimics the RDF of a Solid folder will it be accepted as a true folder by Solid ?
Using only folders to store documents is so old-fashion …


#10

No, AFAIK, you can not directly modify the RDF of a ldp:BasicContainer. Solid does not really use folders to store documents (although a server implementation might). Creating a ldp:BasicContainer and then posting contents to it creates an ldp:contains relationship between the container and its contents. You can not explicitly state that relationship for a ldp:BasicContainer although you can with other kinds of containers.


#11

What I want to do is only create a RDF text that mimics a folder, adding some kind of "hidden"information I can reuse as tags.
But once the folder is created it lives its own life and dependencies on sub-folders will be managed by the server. The only intervention on it should be modifying the tags.
So first question is to know if the server will recognize the manual RDF as a folder.
Second question is will it be able to add relationship to subfolders and is there the risk it destroys the tags.


#12

It’s possible to create a folder-like system using different kinds of containers and define your own contains relationship, and you could access that through apps. I think though what you want is the .meta file - it, unlike the RDF for the Container is an editable file where you can put tags relating to the container and its contents. To find the location of the .meta file you should check the location header of the Container but currently, in NSS, it sill be at /container/.meta. Any tags you put in the .meta file will also be visible when you do a GET on the container. But they are only ever modifiable in the .meta file, not in the RDF of the container itself. If you’d like to see an example, see What is a .meta on NSS?.