Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jul 14 13:50
    RubenVerborgh commented #286
  • Jul 14 13:16
    dmitrizagidulin opened #287
  • Jul 14 13:16
    dmitrizagidulin opened #286
  • Jul 14 13:05
    dmitrizagidulin opened #285
  • Jul 12 12:52
    michielbdejong commented #281
  • Jul 11 21:22
    csarven labeled #284
  • Jul 11 21:22
    csarven labeled #284
  • Jul 11 21:22
    csarven opened #284
  • Jul 11 21:22
    csarven milestoned #284
  • Jul 11 21:02

    csarven on wac

    Init TR/wac Follows https://gi… (compare)

  • Jul 11 11:06
    csarven milestoned #281
  • Jul 11 11:05
    csarven milestoned #282
  • Jul 11 11:05
    csarven labeled #282
  • Jul 11 11:05
    csarven labeled #282
  • Jul 11 11:04
    csarven commented #283
  • Jul 11 10:49
    csarven milestoned #283
  • Jul 11 10:49
    csarven labeled #283
  • Jul 11 10:49
    csarven labeled #283
  • Jul 11 10:48
    csarven opened #283
  • Jul 11 10:43
    csarven edited #281
Dmitri Zagidulin
@dmitrizagidulin
@vinnl_gitlab yeah i just meant turtle being the default format
Vincent
@Vinnl_gitlab
If I can be sure that it's either text/turtle or application/ld+json and nothing else when doing a HEAD request on RDF Resources without an Accept header, that would solve my use case.
Martynas Jusevicius
@namedgraph_twitter
why though?
that's what the Accept header is for
Vincent
@Vinnl_gitlab
If it required the Accept header as well, that could work for me, assuming that I'm not suddenly getting an RDF representation of a PNG, for example
So I don't want to tell the server that I want some data in a particular format, I want to know if it's RDF or not (or when in doubt, assume that it's not)
Sarven Capadisli
@csarven
Accept header is useful. Client should make the effort to send something. No Accept is fine for legacy agents - so the server returning an appropriate representation is a way to handle that. Wildcard is fine if agent can really handle anything or just a fallback. Above all, preference (q-values) is useful. So, client should really let the server know what it can handle.
Martynas Jusevicius
@namedgraph_twitter
well, RDF representation of PNG is RDF, so you would get what you ask for
Sarven Capadisli
@csarven
Just to clarify "where applicable", I didn't mean that anything should have Turtle or JSON-LD in https://gitter.im/solid/specification?at=5eeb6607c4bdd83475efa5f8 . The context is really RDF as this was primarily about that. Of course the server will return the appropriate representation and not arbitrary weird serializations.
@namedgraph_twitter Well, it is not possible for a resource to have both RDF and non-RDF representations. We cooooould discuss that but rather invest energy elsewhere. I think LD/SW discussions moved forward on that matter.
That reminds me.. I was in the middle of a comment/PR or something on this topic. Need to find the tab :(
Tom Gallivan
@sideshowtom
Hi. Sorry, this is another topic...Don't know if this is the right place to ask, but is the ontology/vocabulary of Solid terms at http://www.w3.org/ns/solid/terms still in use and up to date with the specification work? We are talking at https://forum.solidproject.org/t/volunteers-needed-for-solidlov-app/3177/54 about an app to use the Linked Open Vocabularies dataset on Solid pods and the question came up in that context.
Sarven Capadisli
@csarven
@sideshowtom Was there something that I've overlooked in my response in solid/chat?
Sarven Capadisli
@csarven
@gatemezing Did we already talk about LOV having an inbox to receive notifications about new vocabs or updates to existing ones. You can have a shape for the notification so that can work as a way to register vocabs in LOV
Martynas Jusevicius
@namedgraph_twitter

@csarven

Well, it is not possible for a resource to have both RDF and non-RDF representations

if you show me a specification that states this, i will accept that

unless it's LDP which has no standing in my world
Sarven Capadisli
@csarven
Hmm, yea, I don't know if LDP will do that either.
Tom Gallivan
@sideshowtom
@csarven you said there "Feel free to raise spec questions in https://gitter.im/solid/specification or on GitHub with the same path. There is also https://github.com/solid/vocab that's intended as the place to request/register etc terms." so i asked here. So basically, any questions about it should go to issues on https://github.com/solid/vocab?
Sarven Capadisli
@csarven
@sideshowtom Right. Please see the subsequent messages.
Martynas Jusevicius
@namedgraph_twitter
@csarven I don't see anything in https://www.w3.org/TR/webarch/ that prevents a resource having both RDF and non-RDF representations
Sarven Capadisli
@csarven
@namedgraph_twitter I think URI Persistence would cover that.
Martynas Jusevicius
@namedgraph_twitter
where is that specified?
Sarven Capadisli
@csarven
@sideshowtom Yes, solid-terms is still in use. If it wasn't updated since 2018 that doesn't mean it is outdated either. Why would it be? Is there something missing that should be in there? We generally experiment with implementations first, raise issues in solid/vocab .. spec it in parallel, and then they'll get added to the vocab.
Tom Gallivan
@sideshowtom
ok
Sarven Capadisli
@csarven
@namedgraph_twitter What's the resource about? What information is it supposed to convey?
Information about a non-RDF resource (like an image) and an RDF resource (like a comment/annotation) are different things.
Hypothetically content-negotiation is possible but that's neither common or particularly sensible.
So, if there is a use case that would somehow require a resource to be in arbitrary representations, we can look into that.
Re AWWW, once you associate some information to a URI, you stick to it - most of the time. Updating that URI's representation eg. RDF to non-RDF (or vice-versa) is a change that should not happen.
Sarven Capadisli
@csarven
I don't think LDP encourages that. If anything, it leans on not being possible. It talks about the same AWWW principles, and also its interaction models are intended to be sticky ie. server honours client's request.
Solid spec has the same stance.
(I'm not saying this as authority.. just based on discussions/information on the table)
Sarven Capadisli
@csarven
Martynas Jusevicius
@namedgraph_twitter
@csarven lets say we're talking about an image, identified by a URI
if you request PNG or JPEG, you get a binary representation of the image
you can just as well request and get a different representation, including RDF

https://www.w3.org/TR/webarch/#dereference-details

If the URI owner has provided more than one representation (in different formats such as HTML, PNG, or RDF; in different languages such as English and Spanish; or transformed dynamically according to the hardware or software capabilities of the recipient), the resulting representation may depend on negotiation between the user agent and server.

Sarven Capadisli
@csarven
Besides the languages, what would be the actual use case to have RDF and non-RDF?
Martynas Jusevicius
@namedgraph_twitter
images have metadata encoded in them
so do PDFs
you could retrieve that metadata
Sarven Capadisli
@csarven
? Those are part of the same representation!
eg EXIF or XMP's RDF/XML are embedded in the host format.
I'm not aware of any server (yet alone a Solid server) extracting that information and making it available as RDF.
Although it'd be kind of cool.
Martynas Jusevicius
@namedgraph_twitter
so? RDFa is part of HTML, would it not make sense to serve its RDF?
in our case we have separate metadata about non-RDF resources in the triplestore, which gets served when RDF is requested
Sarven Capadisli
@csarven
RDFa in HTML/XML-family is recognised as an RDF Source.
Not true for EXIF in JPEG or XMP's RDF/XML in PDF.