Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Dec 08 15:26
    TallTed commented #244
  • Dec 08 14:02
    elf-pavlik commented #244
  • Dec 06 00:07
    csarven synchronize #346
  • Dec 06 00:07

    csarven on n3-patch

    Stabilise n3-patch spec:require… (compare)

  • Dec 05 23:02
    csarven synchronize #346
  • Dec 05 23:02

    csarven on n3-patch

    Minor (compare)

  • Dec 05 22:47
    csarven synchronize #346
  • Dec 05 22:47

    csarven on n3-patch

    Minor (compare)

  • Dec 05 20:52
    csarven synchronize #352
  • Dec 05 20:52

    csarven on authoritative-contained-resource-data

    Update protocol.html Co-author… (compare)

  • Dec 05 20:48
    csarven synchronize #352
  • Dec 05 20:48

    csarven on authoritative-contained-resource-data

    Update protocol.html Co-author… (compare)

  • Dec 05 20:01
    RubenVerborgh commented #352
  • Dec 05 16:50
    csarven commented #352
  • Dec 05 16:48
    csarven review_requested #352
  • Dec 05 16:48
    csarven review_requested #352
  • Dec 05 16:48
    csarven review_requested #352
  • Dec 05 16:48
    csarven review_requested #352
  • Dec 05 16:48
    csarven review_requested #352
  • Dec 05 16:48
    csarven commented #352
Martynas Jusevicius
@namedgraph_twitter
multiple bases are also allowed
try to get in touch with @afs in linkeddata/chat
he’s the one writing Jena’s parsers
i wouls use N-Triples for streaming though
Martynas Jusevicius
@namedgraph_twitter
@base <http://base1> .
<a> <b> <c> .
@base <http://base2> .
<d> <e> <f> .
<g> <h> <i> .
validates fine on http://ttl.summerofcode.be/ and also using Jena's turtle CLI
result:
<http://base1/a> <http://base1/b> <http://base1/c> .
<http://base2/d> <http://base2/e> <http://base2/f> .
<http://base2/g> <http://base2/h> <http://base2/i> .
Andy Seaborne
@afs
Yes - @base and @prefix can be anywhere. Grammar rules [1] and [2]. They take effect from that point onwards. Turtle processes in order. Stream - not parallel though. The concat things works. @base can take a relative IRI! resolve rel old base, then use new base from that point (until the next set). Prefix must be defined before use but there is always a base - the external context if no @base encountered yet.
Test suite: https://github.com/w3c/rdf-tests/tree/gh-pages/turtle ==> IRI-resolution.ttl, turtle-subm-27.ttl
Andy Seaborne
@afs
The only thing about appending Turtle files is whether any blank node labels are the same.
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.