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
Martynas Jusevicius
@namedgraph_twitter
@afs in other words concatenating 2 files that are reusing the same bnode labels and loading the result into a triplestore will have a different outcome than loading them separately, right?
Andy Seaborne
@afs
Yes. Key is "same file scope" : "_:a" is the same bnode within a file, and different across files.
Fred Gibson
@gibsonf1
thanks @namedgraph_twitter We'll update our turtle parser to support dynamically changing base and prefix throughout the file/stream
Martynas Jusevicius
@namedgraph_twitter
why don't you use some existing I/O library?
Fred Gibson
@gibsonf1
We're doing transformations for our turtle output, such as translating path uri/s to the underlying generic nodes we use for the sytem. We are using other libraries to then translate from turtle into any other format
Fred Gibson
@gibsonf1
We also have both a lower and upper ontology where the lower ontology translates standard triples into causal states whose changes can be tracked through time and attributes, with the upper ontology using industry standard ontology terms
Martynas Jusevicius
@namedgraph_twitter
right, but the I/O level like parsers and writers is at a lower level of abstraction
why waste time implementing that when you can reuse a well-tested library?
Fred Gibson
@gibsonf1
It's basically our interoperability interface - so not sure how we could do it differently to enable internal node uris that are different that public path uris that represent the same node
Martynas Jusevicius
@namedgraph_twitter
still don’t get what this has to do with parsing :) you should be able to accept a stream of triples via an API, without having to do the actual parsing
Fred Gibson
@gibsonf1
we use most of the same interface for sparql insert to the graphdb, so having native turtle is easier as the point of interface translation - and interface to our in-memory graphdb etc. We translate directly bidirectionally with our in-memory graph nodes and edges and turtle. Because turtle is very efficient with data, we like the choice. The dynamic update is very easy to do for us with prefix/base
Josh Collins
@joshdcollins
Question about non-RDF data. As I read the specification (protocol doc) nothing is explicitly said about how non-RDF resources are to be handled. Specifically I’m looking at whether it can be relied upon for a non-RDF resource to return a link header with a type relation of ldp:NonRDFSource?
Jeff Zucker
@jeff-zucker
At the moment, ESS does return ldp:NonRDFSource, NSS only ldp:Resource.
Josh Collins
@joshdcollins
and CSS also returns ldp:Resource
Jeff Zucker
@jeff-zucker
It certainly would be handy to know without having to parse the content-type
2 replies
Vincent
@Vinnl_gitlab
@joshdcollins I asked the same question in the past. Unfortunately, the answer was no. The recommendation was to not send an Accept header, and check whether the returned Content-Type included either text/turtle or application/ld+json, which is what we ended up doing: inrupt/solid-client-js#214. If it did not include those, then we treat it as a NonRDFSource.
Josh Collins
@joshdcollins
I know that turtle and JSON-LD are the minimally required serializations, but it seems like that client code could erroneously see something as NonRDF if it is n-triples, etc. It seems like it would be helpful for a server to advertise the RDF content types it supports so that logic could be more dynamic?
markjspivey
@markjspivey_twitter
im interested in this as well because I have been exploring (https://forum.solidproject.org/t/what-data-is-the-data-that-users-of-solid-own-and-control/3690) what rights / expectations Pod Provider services / implementations are granted by the Specification versus needing to be considered an Application requesting specific access and control over certain data / types of data to optimize for locally ... i say this for instance because I have leaned towards only accepting / uploading client side encrypted non-RDF data (which actually contains RDF) to a Pod Provider, and then having an Application that then requests access to that in order to decrypt and optimize in a multi-party signed manner ... in other words, what assurances does the Solid Specification offer that the Pod Provider cant just (or to what extent it can) accept user data and optimize, duplicate, replicate, etc however it wants without previously requesting access and control for specific said purpose and usage (like an App would be required to do) .
Vincent
@Vinnl_gitlab
@joshdcollins I suppose it depends on what you want to do with it. The problem with other serialisations is that you cannot assume that the server will understand it, e.g. if you get Trig, sending a PATCH request might still fail. And what if it's HTML with embedded RDF - is that an RDF Resource, or not? So if you just want to display RDF data in a consistent way, then you're going to have to decide what to do in such cases, and the safest option would just be to only support serialisations that you know servers are mandated to support (i.e. Turtle and JSON+LD). But if you're expecting data to have been written in a specific serialisation by the client, even if the server does not explicitly support that format, then you might be able to use that assumption when reading as well.
Josh Collins
@joshdcollins
You’re right, @Vinnl_gitlab — it matters more if the client can process it as RDF or not. Does this ultimately mean that the Link header with “type" relation should only be used to determine container vs. non-container?
Vincent
@Vinnl_gitlab
Well, if what's relevant is whether the client can process is, then I'm quite sure that Content-Type is the way to go. Containers in Solid are identified by their URL ending in a trailing /, so you don't need the type Link header for that. Unfortunately I'm not sure what are and are not it's use cases, I'm mostly just regurgitating what I got as answers when I asked the same question a while ago :)
Sarven Capadisli
@csarven
@Vinnl_gitlab You said "not send Accept header" was recommended but I don't see it at the link you've provided.
Sarven Capadisli
@csarven
Receiver needs to know representation with image/png media type is not RDF?
and the use case - documented? - needs additional information through Link rel=type so then it knows whether to parse image/png as RDF or give its reference a specific view?
Sarven Capadisli
@csarven
No, ldp:(Non)RDFSource is not necessary.
Josh Collins
@joshdcollins
Does that mean that the only thing that the Link header with type relation is used for is indicating the creation of a container in a POST? Beyond that content-type and / should be used to determine (from the client’s viewpoint) whether something is container or not or consumable as RDF?
Sarven Capadisli
@csarven

e.g. if you get Trig, sending a PATCH request might still fail.

PATCH is not a request to update whatever representation of a resource, it is to update the resource state

At the moment, yes. It is only a specific case though with POST + Link rel=type: Client wants to 1) create a container, and 2) wants to let the server to allocate the URI (ie. the path under the request target)
I'm not sure I understand your second question. Can you rephrase?
Client and server have a shared understanding of whether a resource is a container or not - trailing slash in URI path or no?
Josh Collins
@joshdcollins

I have a (potentially flawed) mental model of the general categories of resources:

  1. RDF resources (ldp:RDFSource)
  2. Containers (ldp:Container / ldp:BasicContainer)
  3. Non-RDF resources (ldp:NonRDFSource)

I was asking for confirmation that the determination of RDF resources vs. Container was based on the / (which you confirmed above)
And that it is up to the client to determine RDF vs. non-RDF based on Content-Type header — based on which content types the client can process as RDF.

Sarven Capadisli
@csarven
Zero: Stop thinking in terms of LDP
No, that's not what I confirmed.
/ means container. No / means not container.
Besides what / entails re containment rules/lifecycle stuff.. the container is first and foremost intended to be representable as an RDF graph.
encoded I should say
Sarven Capadisli
@csarven
Solid adopts RDF 1.1's concrete RDF syntaxes. When a client asks for the container in Turtle or JSON-LD, server must provide a representation in one.
Josh Collins
@joshdcollins
Got it — and in terms of a client determining whether a resource is RDF or not, that is up to the client to determine based on content-type?
Sarven Capadisli
@csarven
Besides that, for non-container resources, yes, Content-Type will tell the receiver if it can be processed as one of the concrete RDF syntaxes or not. Of course the client can do more than the minimum that's specified eg. the spec doesn't explicitly require N-Triples because it is not one of the "concrete RDF syntaxes" but an application/library should "know" that Turtle is a superset... so if it can parse Turtle (and it needs to), it should be able to handle a representation with Content-Type: application/n-triples - if it wants to of course.
Sarven Capadisli
@csarven
RDF 1.1 is not particularly "concrete" on "concrete RDF syntaxes" beyond the 4 that it lists - in practice it just means any existing or new spec format calls itself RDF / can be.
Aaron Coburn
@acoburn
There are several different permutations here:
  1. First, all containers will have a representation in a concrete RDF 1.1 syntax (the slash will tell you if it’s a container)
  2. Non-containers come in three forms:
    a. RDF resources that the server natively understands as RDF. You can PATCH to these resources (look for Allow: PATCH and Accept-Patch: application/sparql-update). The other clue is that the Content-Type header will be an RDF syntax that the client understands
    b. RDF resources that the server does not natively understand as RDF. For instance, if the Solid server is an LDP server and does not support TriG, a client can still create a TriG file as an ldp:NonRDFSource. I will emphasize that the ldp distinctions here are not important for Solid. The only difference between this and (a) is that you probably can’t PATCH to these resources and expect the RDF serialization to change in expected ways
    c. Everything else: JPEGs, TXT files, PDFs, etc, etc. These are not RDF and do not pretend to be.
Sarven Capadisli
@csarven
Folks approaching from LDP want to either (rightfully/naturally) fit Solid under LDP or maybe want to know why Solid is not full out LDP. I just don't know how significant that is right now.. but have considered adding a short "Relation to LDP" section somewhere - either in the protocol spec or in a primer.
Aaron Coburn
@acoburn
+1 to adding a note along those lines
Josh Collins
@joshdcollins
+1 as well
Justin Bingham
@justinwb
+1 - LDP shows up often enough in the text and in interactions that this clarification would be helpful
Vincent
@Vinnl_gitlab

@Vinnl_gitlab You said "not send Accept header" was recommended but I don't see it at the link you've provided.

:point_up: January 4, 2021 9:18 PM @csarven I asked whether I can be sure that I won't get a Content Type of Turtle or JSON+LD if I didn't send an Accept header in the follow-up message, to which @acoburn responded affirmatively.

Although given Aaron's excellent overview above, I'm inclined to think that looking for an Accept-Patch: application/sparql-update header rather than such a Content-Type might be more explicit - at least in my case, I want to know whether such a PATCH will have the desired effect.
Sarven Capadisli
@csarven

@Vinnl_gitlab RFC 7231:

A request without any Accept header field implies that the user agent
will accept any media type in response.

The Solid Protocol doesn't specify how servers should respond to requests without a Accept header. It is within server's right to reject or respond with an "appropriate" representation.

In the case of resources having an existing representation ie. can be represented with a concrete RDF syntax, then server must accept requests including Accept: text/turtle, application/ld+json. If no Accept header targeting those resources, server can indeed respond with something other than Turtle or JSON-LD.

Silent non-normative: servers might want to / maybe even encouraged to respond with Turtle or JSON-LD if it is "appropriate" (re RDFable resources) so that clients can presumably work with the response. But this is really edge-case territory because clients should indicate which media types they are able to accept.

There is no "default format" per se. Reasonable Variability.

Vincent
@Vinnl_gitlab
OK, that sounds like looking for the Accept-Patch header might indeed be more appropriate for us then.