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
Justin Bingham
@justinwb
Image from iOS.png
everything after “walking through it” were actually messages tim posted in a thread - but they’re being attributed to me on the mobile ui :laughing:
Fred Gibson
@gibsonf1
@namedgraph_twitter If @base is allowed anywhere, is there only one @base allowed in the file? Also, having it anywhere would preclude streaming which is not ideal
Fred Gibson
@gibsonf1
or I think @timbl was referring to a sentence by sentence parse as you read through the file, such that whatever is the state when reading a given line (the @prefix and @base prior to reading that line) apply to that line. Which means you could do streaming as how you interpret the sentence could vary as you read through the file. @timbl Is that what you are recommending?
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.