Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 16:50
    csarven commented #352
  • 16:48
    csarven review_requested #352
  • 16:48
    csarven review_requested #352
  • 16:48
    csarven review_requested #352
  • 16:48
    csarven review_requested #352
  • 16:48
    csarven review_requested #352
  • 16:48
    csarven commented #352
  • 16:39
    csarven synchronize #352
  • 16:39

    csarven on authoritative-contained-resource-data

    Minor Add contained-resource-metadata… (compare)

  • 16:30
    NoelDeMartin commented #352
  • 15:12
    csarven synchronize #352
  • 15:12

    csarven on authoritative-contained-resource-data

    Use resource-metadata instead o… (compare)

  • Dec 03 19:28
    csarven synchronize #352
  • Dec 03 19:27

    csarven on authoritative-contained-resource-data

    Add dcterms-modified-correspond… (compare)

  • Dec 03 18:02
    csarven synchronize #352
  • Dec 03 18:02

    csarven on authoritative-contained-resource-data

    Remove contained-resource-state… (compare)

  • Dec 03 17:51
    csarven synchronize #352
  • Dec 03 17:51

    csarven on authoritative-contained-resource-data

    Remove advisement on omitting d… Add determining server-containe… (compare)

  • Dec 03 16:40
    csarven synchronize #352
  • Dec 03 16:40

    csarven on authoritative-contained-resource-data

    Mention date as part of dcterms… (compare)

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.
Sarven Capadisli
@csarven
It depends. Are you interested in writing?
Vincent
@Vinnl_gitlab
Yes
Sarven Capadisli
@csarven
Then the appearance of any of Accept-Patch, Accept-Put, Accept-Post can help. I'm not sure why Accept was part of this discussion though.
Sarven Capadisli
@csarven
@/all I've updated the current Solid CG's Work Items at https://solid.github.io/specification/ to include publication status (current, next), target (delivery), and expected dates. Please take this information as early draft - expect changes - for the next weeks until CG participants get a chance to review and provide feedback eg. panel members can decide for themselves on the dates (including the expected completion date). For the time being, I've noted down rough/desired expectation based on current progress. Looking good! For new work items, please go through the common process.
Jan Schill
@janschill
Great! Thanks, this is very helpful.
Sarven Capadisli
@csarven
And, reminder to all: we're in the process of transitioning to using solidproject.org for spec URLs. So, please mind how you share/use the current URLs. Don't hesitate to ask here.. or please provide feedback.
Sarven Capadisli
@csarven
Anyone have solutions/suggestions/preferences on what we should do with github.io URLs (driven by gh-pages) once we switch over to solidproject.org URLs for the technical reports? solid/specification#215
Sarven Capadisli
@csarven
I'd also suggest doing this in phases and only for documents that are reviewed+approved for the ecosystem. solidproject.org/TR/ is intended to be persistent space ( solid/solidproject.org#247 ) so need to take care what makes it there and stays put.
Fred Gibson
@gibsonf1
A note on TrinPod, we are standardizing on webid in the form https://user.trinpod.us/@ which can also be reached with https://user.trinpod.us/profile/card#me . We wanted a more user friendly webid that would be as easy to remember and use as an email address, but still stay compliant with the typical #me approach
elf Pavlik
@elf-pavlik
I think https://user.trinpod.us/@ could do HTTP 303 redirect to https://user.trinpod.us/profile/card
Fred Gibson
@gibsonf1
or wouldn't it be the other way around? I definitely like that idea. The card node itself is yet a different uri in the form of /node/radix , but I guess you can't redirect to a URI with fragment.
elf Pavlik
@elf-pavlik
https://www.w3.org/TR/cooluris/#r303gendocument If https://user.trinpod.us/@ gets used as user's WebID, than i should 303 redirect to https://user.trinpod.us/profile/card which would be document with statements describing that WebID
Fred Gibson
@gibsonf1
that makes sense, thanks @elf-pavlik
Matthias Evering
@ewingson
you are a pioneer, right, @gibsonf1 I mean if I follow right you just took the system and used it with Trinpod and made it productive...
Fred Gibson
@gibsonf1
Thanks @ewingson , we are enormous fans of Solid and are happy that we are able to use our AGI to leverage the protocol and also to give our apps the best user experience we can.
Fred Gibson
@gibsonf1
Thank you again @elf-pavlik , the 303 redirect short web id solution works very well: https://frederick.trinpod.us/@
elf Pavlik
@elf-pavlik
@gibsonf1 in https://frederick.trinpod.us/profile/card you should have statements about WebID with https://frederick.trinpod.us/@ as subject, with this approach https://frederick.trinpod.us/profile/card#me would not be used any more
Fred Gibson
@gibsonf1
@elf-pavlik So completely removing #me from the picture would still be spec compliant as long as profile/card is in use? (My worry was that devs would hard code /profile/card#me)
Martynas Jusevicius
@namedgraph_twitter
what are all these properties from <https://ontology.graphmetrix.com/node/>?
i get they are probably internal, but why expose them publicly?
Fred Gibson
@gibsonf1
They are state and attribute definitions that our app will leverage with good benefits as well as inferred types
4 replies
elf Pavlik
@elf-pavlik

@elf-pavlik So completely removing #me from the picture would still be spec compliant as long as profile/card is in use? (My worry was that devs would hard code /profile/card#me)

if devs hardcode something like that their application wouldn't comply with the spec, /profile/card#me is just convention specific to internal choice of one implementation, clients have to "follow their nose"

Fred Gibson
@gibsonf1
sounds good
Ghost
@ghost~5bfd3ed4d73408ce4fb0367e
I like how you put the code on the URL and the databrowser just loads the code on the page @ /profile/card#me because the databrowser loads it up like this https://portal.inrupt.net/?uri=https%3A%2F%2Ffrederick.trinpod.us%2Fprofile%2Fcard%23me
Fred Gibson
@gibsonf1
image.png
@mikeadams1 How does the databrowser work, I just see this and can't get anything else from that link:
Martynas Jusevicius
@namedgraph_twitter
tried to load https://frederick.trinpod.us/profile/card, got this error
InvalidPropertyURIException: https://ontology.graphmetrix.com/node/2
RDF/XML writer cannot figure out out to split such URI
it attempts to use https://ontology.graphmetrix.com/node/ as the base URI, but then 2 is not a valid XML local name (needs to start with a letter)
Fred Gibson
@gibsonf1
Oh, thats not good
we have a simple solution in that all of our ontology, including that 2, has a conceptual tag that is compliant, so instead of 2, it would be m_tag
will add that translation in
We are also looking at releasing the neo lower ontology to the public as well, which captures states/attributes/events/process/function/result, in which case the turtle for https://ontology.graphmetrix.com/node/1bpk would be neo:i_attribute or https://neo.graphmetrix.net/node/i_attribute
Ghost
@ghost~5bfd3ed4d73408ce4fb0367e
it shows me your profile/card#me page
not the code you have on /card#me but the actual page it should produce
Fred Gibson
@gibsonf1
can you screen shot it?
It doesn't seem to work when I try
Ghost
@ghost~5bfd3ed4d73408ce4fb0367e
Screen Shot 2021-01-11 at 10.35.49 AM.png
what browser do you use?
Fred Gibson
@gibsonf1
Ahh, that was it, I typically use Firefox and it doesn't work there - fine on chrome - thanks Mike
Ghost
@ghost~5bfd3ed4d73408ce4fb0367e
your welcome