Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Sep 23 12:22
    elf-pavlik commented #315
  • Sep 23 11:11
    csarven edited #315
  • Sep 23 11:00
    csarven edited #315
  • Sep 23 10:31
    csarven milestoned #315
  • Sep 23 10:31
    csarven assigned #315
  • Sep 23 10:31
    csarven labeled #315
  • Sep 23 10:31
    csarven opened #315
  • Sep 23 06:59

    csarven on main

    Add 2021-09-22 Editors meeting … (compare)

  • Sep 22 20:13
    kjetilk commented #220
  • Sep 22 20:13
    kjetilk milestoned #220
  • Sep 22 20:13
    kjetilk assigned #220
  • Sep 22 20:13
    kjetilk commented #125
  • Sep 22 20:12
    kjetilk milestoned #125
  • Sep 22 08:42
    csarven commented #311
  • Sep 22 08:41
    csarven commented #311
  • Sep 22 08:00
    csarven edited #311
  • Sep 22 06:47
    csarven milestoned #313
  • Sep 21 15:14
    csarven commented #313
  • Sep 21 14:12
    csarven unlabeled #313
  • Sep 21 14:12
    csarven labeled #313
Aaron Coburn
@acoburn
The Content-Type header (combined with an Accept header in the request) is probably your best bet
Sarven Capadisli
@csarven
LDP RDF Source is a subset of RDF Source
Jeff Zucker
@jeff-zucker
and RDF Source could be something not on eiither Solid or LDP?
Sarven Capadisli
@csarven
uhm.. Hang on..
So far Solid uses RDF 1.1's RDF Source.
Jeff Zucker
@jeff-zucker
Yet that says "we informally use RDF Source ..." is it an actual ontology term?
Sarven Capadisli
@csarven
It is defined in the LDP vocab yes
@TallTed can explain LDP's RDFSource better.
Jeff Zucker
@jeff-zucker
LDP's RDFSource is defined as an LDPR so presumbaly that could include a resource on an LDP or Solid server, but would not include some web or local file based RDFSource
Sarven Capadisli
@csarven
As I understand LDP RDF Source (based on Ted's explanation), "full state" in RDF is what qualifies. RDFa in a host language doesn't qualify apparently because the host language would include non-RDF information. So the state includes both RDF and non-RDF. That's why.
RDF 1.1 is about the document format being RDF bearing.
Ted admits that the LDP language is not very clear on this.
I would have been fine with keeping LDP RDF Source and RDF 1.1's RDF Source compatible.
Sarven Capadisli
@csarven
Any way.. long story short, this was the last state of things in the issues. We don't currently require LDP-RS or -NR because of these splits. Server knows RDF or not.. but client doesn't until it sees Content-Type
Excluding containers here because client will be able to tell if a URI identifies a container by checking the trailing slash.
Sarven Capadisli
@csarven
Oh and by the way @Vinnl_gitlab @acoburn , as I understand Ted/LDP, an LDP-NR can be RDF bearing. So in terms of LDP, it is more about whether the state is in whole/full RDF (LDP-RS) or not/partial (LDP-NR).
IIRC, NSS is not particularly strict about that. I think it only actually cared about a resource being a container or not.
So, it would include ldp:(Basic)Container for the link relation.
The current Solid spec is closer to that view than LDP's.
Let me add more fun/confusion to this by saying that, in Solid, it is possible to have containers with HTML(+RDFa) representations... and in LDP, Containers are LDP-RS. That's why earlier I said that so far solid containers are RDF bearing but not expected to be LDP-RS.
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