Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 14:04
    phochste commented #63
  • 14:02
    phochste commented #63
  • 12:50
    kjetilk commented #125
  • 12:48
    kjetilk synchronize #320
  • 12:48

    kjetilk on sparql-update

    Simplify the BNF Reintroduce DeleteWhere Update change count and 2 more (compare)

  • 12:48
    kjetilk closed #321
  • Oct 15 21:51

    csarven on main

    Minor (compare)

  • Oct 15 15:19
    kjetilk milestoned #321
  • Oct 15 15:19
    kjetilk labeled #321
  • Oct 15 15:19
    kjetilk labeled #321
  • Oct 15 15:17
    kjetilk synchronize #321
  • Oct 15 15:17

    kjetilk on sparql-update-simplify

    Add overview section, link Yack… (compare)

  • Oct 15 15:12
    kjetilk commented #125
  • Oct 15 15:02
    RubenVerborgh commented #125
  • Oct 15 14:26
    kjetilk commented #125
  • Oct 15 14:13
    kjetilk commented #321
  • Oct 15 14:01
    kjetilk commented #125
  • Oct 15 12:56
    kjetilk commented #320
  • Oct 15 12:51
    kjetilk milestoned #324
  • Oct 15 12:51
    kjetilk labeled #324
Sarven Capadisli
@csarven
can you add any significant information perhaps that's overlooked from the other repo/issues or at least any significant implementation experience that we should note?
Aaron Coburn
@acoburn
@Vinnl_gitlab a server doesn’t necessarily store any particular RDF serialization. It may have its own internal (application-specific) format that is stored. In that case, when a client requests a particular serialization via content-negotiation, that serialization is dynamically produced (assuming the server supports the desired serialization)
Vincent
@Vinnl_gitlab
@csarven Right, so I can do a HEAD request to check for a 406, and decide on whether to parse it or not based on that.
@acoburn Yeah that's what I meant: a server does dynamically produce a serialisation of PNG images, but it does do so for RDF, so it should be able to distinguish between those two. I was just wondering whether that distinction was also accessible to clients
Aaron Coburn
@acoburn
@Vinnl_gitlab if the Solid server implements LDP, a head request to the resource will tell you if it is an ldp:RDFSource or an ldp:NonRDFSource
Vincent
@Vinnl_gitlab
Ah that's perfect! And where is that listed? (Also, I presume that it's mandatory for a Solid server to do that, according to the Solid spec?)
Sarven Capadisli
@csarven
"Relationship status: Complicated"
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)