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
Sarven Capadisli
@csarven
Not sure why the last definition omits RDF/XML
Sarven Capadisli
@csarven
re RDFa, it is possible that documents serialised with the HTML, XML-family syntax can be RDF bearing. Clients may want to RDF parse messages with certain Content-Types (eg. text/html, application/xhtml+xml, image/svg+xml, ..)
Sarven Capadisli
@csarven
Basically if a format is listed in those links, associated data can be interpreted as RDF bearing.
In Solid, we have a hard(-ish) requirement for JSON-LD and Turtle. At least MUST for servers. RDFa is a bit fuzzy - will discuss that later in context of containers.
Sarven Capadisli
@csarven
Just to be clear, the reason I mentioned different formats is because a client may acknowledge that some of the resources have an RDF representation, but it may not be able to parse the encoded RDF graph from all (unless of course it has all of the parsers). Besides that, it can stick to JSON-LD and Turtle.
Vincent
@Vinnl_gitlab

Right, technically obviously any possible (current and future) serialisation can be stored in the server, and the server has no way to know. But it does explicitly distinguish between "RDF" and "anything else (which could possibly also be RDF", right?

In the sense that I can store RDF on the Pod and request it from the server in either Turtle or JSON-LD format - which I can't do for other data like PNGs, is that correct?

Sarven Capadisli
@csarven
As in JPEG, TIFF,..?
I'm not sure I follow what you mean.
Sarven Capadisli
@csarven
Client request includes payload and Content-Type (and may have other information like Content-Language). Server verifies. Server knows a resource has a representation in RDF (a class of types) or anything else.
Right, if a request originally included RDF, and got created, server wouldn't give a representation for non-RDF mediatypes. It'll return 406.
Sarven Capadisli
@csarven
(mixing up my error codes)
Related: I suppose server should return 415 if resource originally created in RDF and the subsequent write operation uses a non-RDF payload and mediatype in Content-Type.
Dmitri Zagidulin
@dmitrizagidulin
@csarven +1 to #184, i wholeheartedly agree
Sarven Capadisli
@csarven
Actually, RFC 7231 says that for PUT. If the representation is unsuitable, it can (SHOULD) return 415. We should perhaps clarify that in the spec especially between RDF and non-RDF.
@dmitrizagidulin Great! I always found infinite meta/acl'ing confusing.
Dmitri Zagidulin
@dmitrizagidulin
same, yeah
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.