Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Oct 19 20:10
    jeff-zucker commented #209
  • Oct 19 20:05
    csarven commented #209
  • Oct 19 20:04
    csarven commented #209
  • Oct 19 19:53
    bourgeoa commented #209
  • Oct 19 19:31
    csarven commented #209
  • Oct 19 19:10
    jeff-zucker commented #209
  • Oct 19 18:38
    justinwb commented #209
  • Oct 19 16:37
    jeff-zucker commented #209
  • Oct 19 15:40
    jeff-zucker commented #209
  • Oct 19 15:30
    jeff-zucker commented #209
  • Oct 19 11:14
    justinwb commented #209
  • Oct 19 10:56
    justinwb opened #210
  • Oct 19 08:26
    Vinnl commented #209
  • Oct 19 08:26
    Vinnl commented #209
  • Oct 19 08:24
    Vinnl commented #209
  • Oct 17 18:28
    jeff-zucker commented #209
  • Oct 17 18:18
    jeff-zucker commented #209
  • Oct 17 17:29
    angelo-v commented #209
  • Oct 17 17:29
    angelo-v commented #209
  • Oct 17 17:11
    jeff-zucker opened #209
Justin Bingham
@justinwb
@elf-pavlik #122 merged / #121 approved/merged!
elf Pavlik
@elf-pavlik
thank you @justinwb, i made new PR for running validation on turtle snippets solid/data-interoperability-panel#123
matthieu-fesselier
@matthieu-fesselier
Hello here! Does anyone know if there has been some work already to implement the spec in the community solid server?
elf Pavlik
@elf-pavlik
Hi, current spec shouldn't require additions to the storage servers. Applications and Authorization Agent should be able to handle everything.
Personally I find it a very interesting options to explore for storage servers to directly support Data Grants rather than require Authorization Agent to generate something like ACP or WAC based on them. But as the spec currently stands it assumes that Authorization Agent would set access policies on the storage server based on data grants.
To be clear, I meant Solid Application Interoperability spec. The https://shapetrees.org/TR/specification/ most likely can benefit from support on the solid storage.
Justin Bingham
@justinwb
@matthieu-fesselier there is work underway to add shape tree / shape validation to CSS which isn’t fully necessary but pretty important for interoperability in practical use
to coincide with a fresh new updated shape trees spec at https://shapetrees.org/TR/specification/index.html
:slight_smile:
elf Pavlik
@elf-pavlik
:tada: :clap:
elf Pavlik
@elf-pavlik
It would be great to have some conversations in https://github.com/solid/data-interoperability-panel/issues before our call tomorrow
matthieu-fesselier
@matthieu-fesselier
Ok thanks for the informations!
elf Pavlik
@elf-pavlik
q+
Justin Bingham
@justinwb
elf Pavlik
@elf-pavlik
Eric Prud'hommeaux
@ericprud
Eric Prud'hommeaux
@ericprud
@elf-pavlik , hackmd schema and data validate (see [try it] link at bottom)
elf Pavlik
@elf-pavlik
thanks will try it out today in the evening
elf Pavlik
@elf-pavlik
my local version of sai-js already tests implementation using snippets from that branch
elf Pavlik
@elf-pavlik
@justinwb if you get a chance to merge two open pull requests I will make another one right away for #125
It might also be a good time to start working on #63 so we can start validating all the snippets in the spec as well
elf Pavlik
@elf-pavlik

@ericprud looking at https://shapetrees.org/TR/specification/index.html#shapetree-virtual

st:viaShapePath "@ex:ProjectShape/ex:hasMilestone"

the object is a Literal. Once we run turtle parser and get RDFJS DatasetCore we will lose all the prefixes. How are we supposed to use that Shape Path once the prefixes are gone?

elf Pavlik
@elf-pavlik
<#VirtualProjectTree>
  a st:ShapeTree ;
  st:expectsType st:Resource ;
  st:shape ex:ProjectShape ;
  st:references [
    st:hasShapeTree <#VirtualMilestoneTree> ;
    st:viaShapePath "@ex:ProjectShape/ex:hasMilestone"
  ] .
if we only do direct references, we only need the predicate ex:hasMilestone
we get ex:ProjectShape from 'the parent' anyways
<#VirtualProjectTree>
  a st:ShapeTree ;
  st:expectsType st:Resource ;
  st:shape ex:ProjectShape ;
  st:references [
    st:hasShapeTree <#VirtualMilestoneTree> ;
    st:viaPredicate ex:hasMilestone
  ] .
here ex:hasMilestone would get properly expanded by the parser
Eric Prud'hommeaux
@ericprud
@elf-pavlik , that depends how high we want to raise the usability bar
in the ShEx manifest format, which a few implementations support, the impl is expected to preserve prefixes from the schema and data (with the most recently-parsed data overriding prefixes from previous data, and likewise with schema
likewise, these implementations preserve BASE URLs
elf Pavlik
@elf-pavlik
@ericprud I made draft PR (which possibly will not need to be merged) just to get snippets I can implement against today: https://github.com/solid/data-interoperability-panel/pull/130/files
Both shape tree and references list are serialized as plain turtle
in that case we can't expect that we will have prefixes available when we use values from literals
As I mention in this draft PR we can take time to discuss it via chat and during two meetings this week without me staying blocked from implementing something already
Eric Prud'hommeaux
@ericprud
i forget, does RDFJS provide a parser API? if so, does N3.js conform to it?
elf Pavlik
@elf-pavlik
Eric Prud'hommeaux
@ericprud
'cause that's what i use in shex-simple and if you peek at https://tinyurl.com/34ae9bwk , you'll see that the QueryMap accesses BASE and PREFIXes from the schema and DATA
without that, you just end up writing ShapePaths like "@http://a.example/schema/ProjectShape.http://a.exmaple/schema/hasMilestone"
elf Pavlik
@elf-pavlik
So far we were hoping that we can just pass instances of DatasetCore https://rdf.js.org/dataset-spec/#datasetcore-interface which doesn't include any prefix information
Eric Prud'hommeaux
@ericprud
biab
Eric Prud'hommeaux
@ericprud
b
at some point, i think we should have a discussion of A. what usability environment do we want to aspire to and B., if it's different than today, how do we get there
elf Pavlik
@elf-pavlik
Yesterday, while implementing InheritInstances Data Grant, I found very inconvenient how ldp:contains points to the resource and not its focus node. Actually I changed it to point to focus node https://github.com/solid/data-interoperability-panel/pull/130/files#diff-be21cbad4d5d3b9a5414aa3455ee8527d0d21ae6f0b625aecf1dab1688461281R14 but that's most likely incorrect use of ldp:contains
I would like to consider using a different property which can point to a focus node rather than just the document (if they differ)
hRicklefs
@hRicklefs
will be 30min late
Justin Bingham
@justinwb
elf Pavlik
@elf-pavlik
@ericprud your mic is pretty bad
sai-js commit working over data from #130 elf-pavlik/sai-js@0cdb070
elf Pavlik
@elf-pavlik