Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jul 28 12:49
    csarven commented #288
  • Jul 28 08:03
    csarven commented #288
  • Jul 28 06:47
    rubensworks commented #291
  • Jul 28 01:08
    gibsonf1 commented #288
  • Jul 28 01:05
    acoburn commented #288
  • Jul 28 00:18
    acoburn commented #291
  • Jul 27 19:50
    kjetilk labeled #291
  • Jul 27 19:50
    kjetilk labeled #291
  • Jul 27 19:50
    kjetilk opened #291
  • Jul 27 19:50
    kjetilk labeled #291
  • Jul 27 18:39
    kjetilk commented #220
  • Jul 27 18:36
    kjetilk demilestoned #125
  • Jul 27 18:36
    kjetilk commented #125
  • Jul 27 18:21
    kjetilk commented #125
  • Jul 27 18:16
    kjetilk commented #288
  • Jul 27 18:06
    kjetilk unlabeled #267
  • Jul 27 13:48
    csarven labeled #290
  • Jul 27 13:48
    csarven milestoned #290
  • Jul 27 13:48
    csarven opened #290
  • Jul 27 13:46

    csarven on trust-between-owners-same-origin-multiple-storages

    Trust between owners on same or… (compare)

Vincent
@Vinnl_gitlab

I'd presume that the primary case to do a HEAD on a resource to check if it is available in RDF or not is because the resource URI was discovered in a containment listing.

Since the container description is not expected to include information about the contained resources (re RDF or not) client will need to go through the resources one by one.

Yes exactly. But then that info does need to be available on those Resources, so if it doesn't state that it's an RDFSource (or something equivalent), then that doesn't work either.

The Content-Type header (combined with an Accept header in the request) is probably your best bet

But at that point we're looking at actual representations right? Or should I just request text/turtle, and if that doesn't result in a 406, I know that it's RDF?

What do -RS and -NR stand for?
Sarven Capadisli
@csarven
RDFSource, NonRDFSource
Sarven Capadisli
@csarven
@acoburn Just thinking re what Vincent just said.. and this might sound silly but any reason why Content-Type can't be in response to HEAD? Wouldn't that be sufficient to tell if a resource has an RDF representation or not?
As I understand it, HEAD should return the same headers as GET, optionally omitting payload headers.
So, Content-Type will be available.
Sarven Capadisli
@csarven
I thought we covered this angle before.
Aaron Coburn
@acoburn
I can say that the Trellis server returns an appropriate Content-Type header for HEAD requests. If the resource is an LDP-RS, the Content-Type is text/turtle (unless content-negotiation requires otherwise — though I’m not sure what conneg means for HEAD requests), and if the resource is an LDP-NR, the Content-Type will be whatever the binary is (e.g. image/jpeg)
that is to say, yes the Content-Type header will be present and should be sufficient for any client to figure out what the resource is

in Solid, it is possible to have containers with HTML(+RDFa) representations

In Trellis, all Resources can be represented using RDFa (if content-negotiation requires such), and that includes containers, binaries and non-container RDF resources

Sarven Capadisli
@csarven
Great!
^ @Vinnl_gitlab is that reasonable to you? Just check Content-Type of HEAD.
NSS emits the Content-Type in HEAD AFAICT
Vincent
@Vinnl_gitlab
That is reasonable, assuming that I can rely on the value of the Content-Type. Does Solid mandate it to be text/turtle for RDF Resources without content negotiation? (And likewise, can I rely on it not being that for e.g. images if I don't send an Accept header?)
Aaron Coburn
@acoburn
If the server conforms to https://tools.ietf.org/html/rfc7231#section-4.3.2 (which it really should), I think you can rely on that behavior
Vincent
@Vinnl_gitlab
And if the server conforms to the Solid spec? I don't really care about anything else :P
I suppose it's an implicit assumption from the Solid side that a server complies to that? And it does mandate that text/turtle is the default format for RDF, and not e.g. JSON-LD?
Dmitri Zagidulin
@dmitrizagidulin
I don’t think there’s a mandate/requirement like that
Aaron Coburn
@acoburn
If a server conforms to the Solid spec then, via https://solid.github.io/specification/#http-server it must be a conforming HTTP/1.1 server (i.e. RFC7230 and RFC7231). In other words, you can rely on that RFC section mentioned above
Vincent
@Vinnl_gitlab
OK, that's great. But @dmitrizagidulin, when you say "I don't think there's a mandate/requirement like that", does "that" refer to the RFC, or to text/turtle being the default format?
Sarven Capadisli
@csarven
@Vinnl_gitlab re "default format" => Where applicable, servers are required to accept payloads in Turtle and JSON-LD. Servers are also required to handle proactive negotiation so that representations can be in Turtle or JSON-LD.
Sarven Capadisli
@csarven
LDP says a bit more on "default format", aka when Accept header is missing, it says that server should return Turtle. Or if Accept is say */* it should return JSON-LD.
Besides that, writing is possible with either.. and reading is about the same.
So, you can expect GET/HEAD to have a Content-Type including text/turtle or application/ld+json
Dmitri Zagidulin
@dmitrizagidulin
@vinnl_gitlab yeah i just meant turtle being the default format
Vincent
@Vinnl_gitlab
If I can be sure that it's either text/turtle or application/ld+json and nothing else when doing a HEAD request on RDF Resources without an Accept header, that would solve my use case.
Martynas Jusevicius
@namedgraph_twitter
why though?
that's what the Accept header is for
Vincent
@Vinnl_gitlab
If it required the Accept header as well, that could work for me, assuming that I'm not suddenly getting an RDF representation of a PNG, for example
So I don't want to tell the server that I want some data in a particular format, I want to know if it's RDF or not (or when in doubt, assume that it's not)
Sarven Capadisli
@csarven
Accept header is useful. Client should make the effort to send something. No Accept is fine for legacy agents - so the server returning an appropriate representation is a way to handle that. Wildcard is fine if agent can really handle anything or just a fallback. Above all, preference (q-values) is useful. So, client should really let the server know what it can handle.
Martynas Jusevicius
@namedgraph_twitter
well, RDF representation of PNG is RDF, so you would get what you ask for
Sarven Capadisli
@csarven
Just to clarify "where applicable", I didn't mean that anything should have Turtle or JSON-LD in https://gitter.im/solid/specification?at=5eeb6607c4bdd83475efa5f8 . The context is really RDF as this was primarily about that. Of course the server will return the appropriate representation and not arbitrary weird serializations.
@namedgraph_twitter Well, it is not possible for a resource to have both RDF and non-RDF representations. We cooooould discuss that but rather invest energy elsewhere. I think LD/SW discussions moved forward on that matter.
That reminds me.. I was in the middle of a comment/PR or something on this topic. Need to find the tab :(
Tom Gallivan
@sideshowtom
Hi. Sorry, this is another topic...Don't know if this is the right place to ask, but is the ontology/vocabulary of Solid terms at http://www.w3.org/ns/solid/terms still in use and up to date with the specification work? We are talking at https://forum.solidproject.org/t/volunteers-needed-for-solidlov-app/3177/54 about an app to use the Linked Open Vocabularies dataset on Solid pods and the question came up in that context.
Sarven Capadisli
@csarven
@sideshowtom Was there something that I've overlooked in my response in solid/chat?
Sarven Capadisli
@csarven
@gatemezing Did we already talk about LOV having an inbox to receive notifications about new vocabs or updates to existing ones. You can have a shape for the notification so that can work as a way to register vocabs in LOV
Martynas Jusevicius
@namedgraph_twitter

@csarven

Well, it is not possible for a resource to have both RDF and non-RDF representations

if you show me a specification that states this, i will accept that

unless it's LDP which has no standing in my world
Sarven Capadisli
@csarven
Hmm, yea, I don't know if LDP will do that either.
Tom Gallivan
@sideshowtom
@csarven you said there "Feel free to raise spec questions in https://gitter.im/solid/specification or on GitHub with the same path. There is also https://github.com/solid/vocab that's intended as the place to request/register etc terms." so i asked here. So basically, any questions about it should go to issues on https://github.com/solid/vocab?
Sarven Capadisli
@csarven
@sideshowtom Right. Please see the subsequent messages.
Martynas Jusevicius
@namedgraph_twitter
@csarven I don't see anything in https://www.w3.org/TR/webarch/ that prevents a resource having both RDF and non-RDF representations
Sarven Capadisli
@csarven
@namedgraph_twitter I think URI Persistence would cover that.
Martynas Jusevicius
@namedgraph_twitter
where is that specified?
Sarven Capadisli
@csarven
@sideshowtom Yes, solid-terms is still in use. If it wasn't updated since 2018 that doesn't mean it is outdated either. Why would it be? Is there something missing that should be in there? We generally experiment with implementations first, raise issues in solid/vocab .. spec it in parallel, and then they'll get added to the vocab.
Tom Gallivan
@sideshowtom
ok
Sarven Capadisli
@csarven
@namedgraph_twitter What's the resource about? What information is it supposed to convey?
Information about a non-RDF resource (like an image) and an RDF resource (like a comment/annotation) are different things.