Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 06:30
    damooo commented #329
  • 06:27
    damooo commented #329
  • 06:27
    damooo commented #329
  • 05:55
    damooo commented #329
  • 05:53
    damooo commented #329
  • Oct 25 10:44
    kjetilk commented #298
  • Oct 25 10:34
    csarven commented #298
  • Oct 25 10:33
    kjetilk commented #298
  • Oct 25 10:30
    acoburn commented #298
  • Oct 25 10:02
    kjetilk commented #298
  • Oct 25 09:57
    csarven commented #298
  • Oct 25 09:56
    kjetilk commented #310
  • Oct 25 09:16
    csarven commented #329
  • Oct 25 09:03
    kjetilk commented #329
  • Oct 25 09:03
    csarven commented #317
  • Oct 25 09:00
    kjetilk labeled #329
  • Oct 25 09:00
    kjetilk labeled #329
  • Oct 23 20:50
    bblfish commented #325
  • Oct 23 20:49
    bblfish commented #325
  • Oct 23 20:47
    bblfish commented #325
Sarven Capadisli
@csarven
re ldp:(Non)RDFSource
Aaron Coburn
@acoburn
@Vinnl_gitlab that will be in a Link header: Link: <http://www.w3.org/ns/ldp#NonRDFSource>; rel=“type” (but only if it’s a conforming LDP server)
but note @csarven’s note about Solid’s relationship to LDP :-)
Sarven Capadisli
@csarven
That would make a great Spec Note :P
Vincent
@Vinnl_gitlab
So does "complicated" mean I'm supposed to be able to count on it, as a client, or not?
Sarven Capadisli
@csarven
I'll have to check my notes but Solid doesn't take on all of the LDP interaction models
Container->BasicContainer yes
There are long threads on this.. Solid Containers are RDF Sources but not necessarily LDP RDFSources
It is not crystal clear where RDFa embedded documents live in LDP. Not ldp:RDFSource apparently but can be ldp:NonRDFSource
Sarven Capadisli
@csarven
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.
Aaron Coburn
@acoburn
That’s where a query interface (c.f. Linked Data Fragments) would be hugely helpful
Jeff Zucker
@jeff-zucker
Related question : if Solid and LDP have different definitions of RDFSource, is there an ontology term to describe all RDFSources. I've run into this in app where I basically want to be able to say in a triple whether a thing is parseable by rdlib or not.
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