Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Nov 26 23:33
    acoburn commented #356
  • Nov 26 21:53
    RubenVerborgh commented #356
  • Nov 26 21:49
    kjetilk commented #356
  • Nov 26 21:39
    csarven edited #356
  • Nov 26 21:29
    RubenVerborgh review_requested #349
  • Nov 26 19:47
    acoburn commented #356
  • Nov 26 18:50
    csarven edited #356
  • Nov 26 18:05
    csarven commented #355
  • Nov 26 17:55
    csarven opened #356
  • Nov 25 23:29
    kjetilk commented #355
  • Nov 25 22:44
    kjetilk commented #355
  • Nov 25 22:44
    kjetilk commented #355
  • Nov 25 16:05
    ThisIsMissEm commented #355
  • Nov 25 15:57
    langsamu commented #355
  • Nov 25 15:40
    acoburn commented #355
  • Nov 25 15:33
    langsamu commented #355
  • Nov 25 14:29
    ThisIsMissEm commented #355
  • Nov 25 14:18
    csarven commented #355
  • Nov 25 14:18
    csarven milestoned #355
  • Nov 25 14:18
    csarven labeled #355
Josh Collins
@joshdcollins
and CSS also returns ldp:Resource
Jeff Zucker
@jeff-zucker
It certainly would be handy to know without having to parse the content-type
2 replies
Vincent
@Vinnl_gitlab
@joshdcollins I asked the same question in the past. Unfortunately, the answer was no. The recommendation was to not send an Accept header, and check whether the returned Content-Type included either text/turtle or application/ld+json, which is what we ended up doing: inrupt/solid-client-js#214. If it did not include those, then we treat it as a NonRDFSource.
Josh Collins
@joshdcollins
I know that turtle and JSON-LD are the minimally required serializations, but it seems like that client code could erroneously see something as NonRDF if it is n-triples, etc. It seems like it would be helpful for a server to advertise the RDF content types it supports so that logic could be more dynamic?
markjspivey
@markjspivey_twitter
im interested in this as well because I have been exploring (https://forum.solidproject.org/t/what-data-is-the-data-that-users-of-solid-own-and-control/3690) what rights / expectations Pod Provider services / implementations are granted by the Specification versus needing to be considered an Application requesting specific access and control over certain data / types of data to optimize for locally ... i say this for instance because I have leaned towards only accepting / uploading client side encrypted non-RDF data (which actually contains RDF) to a Pod Provider, and then having an Application that then requests access to that in order to decrypt and optimize in a multi-party signed manner ... in other words, what assurances does the Solid Specification offer that the Pod Provider cant just (or to what extent it can) accept user data and optimize, duplicate, replicate, etc however it wants without previously requesting access and control for specific said purpose and usage (like an App would be required to do) .
Vincent
@Vinnl_gitlab
@joshdcollins I suppose it depends on what you want to do with it. The problem with other serialisations is that you cannot assume that the server will understand it, e.g. if you get Trig, sending a PATCH request might still fail. And what if it's HTML with embedded RDF - is that an RDF Resource, or not? So if you just want to display RDF data in a consistent way, then you're going to have to decide what to do in such cases, and the safest option would just be to only support serialisations that you know servers are mandated to support (i.e. Turtle and JSON+LD). But if you're expecting data to have been written in a specific serialisation by the client, even if the server does not explicitly support that format, then you might be able to use that assumption when reading as well.
Josh Collins
@joshdcollins
You’re right, @Vinnl_gitlab — it matters more if the client can process it as RDF or not. Does this ultimately mean that the Link header with “type" relation should only be used to determine container vs. non-container?
Vincent
@Vinnl_gitlab
Well, if what's relevant is whether the client can process is, then I'm quite sure that Content-Type is the way to go. Containers in Solid are identified by their URL ending in a trailing /, so you don't need the type Link header for that. Unfortunately I'm not sure what are and are not it's use cases, I'm mostly just regurgitating what I got as answers when I asked the same question a while ago :)
Sarven Capadisli
@csarven
@Vinnl_gitlab You said "not send Accept header" was recommended but I don't see it at the link you've provided.
Sarven Capadisli
@csarven
Receiver needs to know representation with image/png media type is not RDF?
and the use case - documented? - needs additional information through Link rel=type so then it knows whether to parse image/png as RDF or give its reference a specific view?
Sarven Capadisli
@csarven
No, ldp:(Non)RDFSource is not necessary.
Josh Collins
@joshdcollins
Does that mean that the only thing that the Link header with type relation is used for is indicating the creation of a container in a POST? Beyond that content-type and / should be used to determine (from the client’s viewpoint) whether something is container or not or consumable as RDF?
Sarven Capadisli
@csarven

e.g. if you get Trig, sending a PATCH request might still fail.

PATCH is not a request to update whatever representation of a resource, it is to update the resource state

At the moment, yes. It is only a specific case though with POST + Link rel=type: Client wants to 1) create a container, and 2) wants to let the server to allocate the URI (ie. the path under the request target)
I'm not sure I understand your second question. Can you rephrase?
Client and server have a shared understanding of whether a resource is a container or not - trailing slash in URI path or no?
Josh Collins
@joshdcollins

I have a (potentially flawed) mental model of the general categories of resources:

  1. RDF resources (ldp:RDFSource)
  2. Containers (ldp:Container / ldp:BasicContainer)
  3. Non-RDF resources (ldp:NonRDFSource)

I was asking for confirmation that the determination of RDF resources vs. Container was based on the / (which you confirmed above)
And that it is up to the client to determine RDF vs. non-RDF based on Content-Type header — based on which content types the client can process as RDF.

Sarven Capadisli
@csarven
Zero: Stop thinking in terms of LDP
No, that's not what I confirmed.
/ means container. No / means not container.
Besides what / entails re containment rules/lifecycle stuff.. the container is first and foremost intended to be representable as an RDF graph.
encoded I should say
Sarven Capadisli
@csarven
Solid adopts RDF 1.1's concrete RDF syntaxes. When a client asks for the container in Turtle or JSON-LD, server must provide a representation in one.
Josh Collins
@joshdcollins
Got it — and in terms of a client determining whether a resource is RDF or not, that is up to the client to determine based on content-type?
Sarven Capadisli
@csarven
Besides that, for non-container resources, yes, Content-Type will tell the receiver if it can be processed as one of the concrete RDF syntaxes or not. Of course the client can do more than the minimum that's specified eg. the spec doesn't explicitly require N-Triples because it is not one of the "concrete RDF syntaxes" but an application/library should "know" that Turtle is a superset... so if it can parse Turtle (and it needs to), it should be able to handle a representation with Content-Type: application/n-triples - if it wants to of course.
Sarven Capadisli
@csarven
RDF 1.1 is not particularly "concrete" on "concrete RDF syntaxes" beyond the 4 that it lists - in practice it just means any existing or new spec format calls itself RDF / can be.
Aaron Coburn
@acoburn
There are several different permutations here:
  1. First, all containers will have a representation in a concrete RDF 1.1 syntax (the slash will tell you if it’s a container)
  2. Non-containers come in three forms:
    a. RDF resources that the server natively understands as RDF. You can PATCH to these resources (look for Allow: PATCH and Accept-Patch: application/sparql-update). The other clue is that the Content-Type header will be an RDF syntax that the client understands
    b. RDF resources that the server does not natively understand as RDF. For instance, if the Solid server is an LDP server and does not support TriG, a client can still create a TriG file as an ldp:NonRDFSource. I will emphasize that the ldp distinctions here are not important for Solid. The only difference between this and (a) is that you probably can’t PATCH to these resources and expect the RDF serialization to change in expected ways
    c. Everything else: JPEGs, TXT files, PDFs, etc, etc. These are not RDF and do not pretend to be.
Sarven Capadisli
@csarven
Folks approaching from LDP want to either (rightfully/naturally) fit Solid under LDP or maybe want to know why Solid is not full out LDP. I just don't know how significant that is right now.. but have considered adding a short "Relation to LDP" section somewhere - either in the protocol spec or in a primer.
Aaron Coburn
@acoburn
+1 to adding a note along those lines
Josh Collins
@joshdcollins
+1 as well
Justin Bingham
@justinwb
+1 - LDP shows up often enough in the text and in interactions that this clarification would be helpful
Vincent
@Vinnl_gitlab

@Vinnl_gitlab You said "not send Accept header" was recommended but I don't see it at the link you've provided.

:point_up: January 4, 2021 9:18 PM @csarven I asked whether I can be sure that I won't get a Content Type of Turtle or JSON+LD if I didn't send an Accept header in the follow-up message, to which @acoburn responded affirmatively.

Although given Aaron's excellent overview above, I'm inclined to think that looking for an Accept-Patch: application/sparql-update header rather than such a Content-Type might be more explicit - at least in my case, I want to know whether such a PATCH will have the desired effect.
Sarven Capadisli
@csarven

@Vinnl_gitlab RFC 7231:

A request without any Accept header field implies that the user agent
will accept any media type in response.

The Solid Protocol doesn't specify how servers should respond to requests without a Accept header. It is within server's right to reject or respond with an "appropriate" representation.

In the case of resources having an existing representation ie. can be represented with a concrete RDF syntax, then server must accept requests including Accept: text/turtle, application/ld+json. If no Accept header targeting those resources, server can indeed respond with something other than Turtle or JSON-LD.

Silent non-normative: servers might want to / maybe even encouraged to respond with Turtle or JSON-LD if it is "appropriate" (re RDFable resources) so that clients can presumably work with the response. But this is really edge-case territory because clients should indicate which media types they are able to accept.

There is no "default format" per se. Reasonable Variability.

Vincent
@Vinnl_gitlab
OK, that sounds like looking for the Accept-Patch header might indeed be more appropriate for us then.
Sarven Capadisli
@csarven
It depends. Are you interested in writing?
Vincent
@Vinnl_gitlab
Yes
Sarven Capadisli
@csarven
Then the appearance of any of Accept-Patch, Accept-Put, Accept-Post can help. I'm not sure why Accept was part of this discussion though.
Sarven Capadisli
@csarven
@/all I've updated the current Solid CG's Work Items at https://solid.github.io/specification/ to include publication status (current, next), target (delivery), and expected dates. Please take this information as early draft - expect changes - for the next weeks until CG participants get a chance to review and provide feedback eg. panel members can decide for themselves on the dates (including the expected completion date). For the time being, I've noted down rough/desired expectation based on current progress. Looking good! For new work items, please go through the common process.
Jan Schill
@janschill
Great! Thanks, this is very helpful.
Sarven Capadisli
@csarven
And, reminder to all: we're in the process of transitioning to using solidproject.org for spec URLs. So, please mind how you share/use the current URLs. Don't hesitate to ask here.. or please provide feedback.
Sarven Capadisli
@csarven
Anyone have solutions/suggestions/preferences on what we should do with github.io URLs (driven by gh-pages) once we switch over to solidproject.org URLs for the technical reports? solid/specification#215
Sarven Capadisli
@csarven
I'd also suggest doing this in phases and only for documents that are reviewed+approved for the ecosystem. solidproject.org/TR/ is intended to be persistent space ( solid/solidproject.org#247 ) so need to take care what makes it there and stays put.
Fred Gibson
@gibsonf1
A note on TrinPod, we are standardizing on webid in the form https://user.trinpod.us/@ which can also be reached with https://user.trinpod.us/profile/card#me . We wanted a more user friendly webid that would be as easy to remember and use as an email address, but still stay compliant with the typical #me approach
elf Pavlik
@elf-pavlik
I think https://user.trinpod.us/@ could do HTTP 303 redirect to https://user.trinpod.us/profile/card
Fred Gibson
@gibsonf1
or wouldn't it be the other way around? I definitely like that idea. The card node itself is yet a different uri in the form of /node/radix , but I guess you can't redirect to a URI with fragment.
elf Pavlik
@elf-pavlik
https://www.w3.org/TR/cooluris/#r303gendocument If https://user.trinpod.us/@ gets used as user's WebID, than i should 303 redirect to https://user.trinpod.us/profile/card which would be document with statements describing that WebID
Fred Gibson
@gibsonf1
that makes sense, thanks @elf-pavlik