Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • May 10 14:01
    laurensdeb commented #258
  • May 10 13:52
    elf-pavlik edited #258
  • May 10 13:51
    elf-pavlik opened #258
  • Apr 19 16:32
    justinwb commented #253
  • Apr 14 20:43

    github-actions[bot] on gh-pages

    deploy: f6b422e59a082d1b3e3a577… (compare)

  • Apr 14 20:42
    elf-pavlik closed #201
  • Apr 14 20:42
    elf-pavlik commented #201
  • Apr 14 20:42

    elf-pavlik on main

    primer: updated some snippets … primer: updated names of scopes primer: updated some snippets … and 4 more (compare)

  • Apr 14 17:28
    elf-pavlik commented #241
  • Apr 12 12:57
    elf-pavlik edited #257
  • Apr 12 12:43
    elf-pavlik edited #257
  • Apr 12 12:43
    elf-pavlik edited #257
  • Apr 12 12:42
    elf-pavlik review_requested #257
  • Apr 12 12:42
    elf-pavlik opened #257
  • Apr 10 23:29
    elf-pavlik assigned #201
  • Apr 10 23:07
    elf-pavlik closed #108
  • Apr 10 21:48
    elf-pavlik labeled #256
  • Apr 10 21:48
    elf-pavlik opened #256
  • Apr 10 21:37
    elf-pavlik closed #113
  • Apr 10 21:33
    elf-pavlik closed #242
elf Pavlik
@elf-pavlik
@justinwb I think we should change default branch to main and prune branches in the repo https://github.com/solid/data-interoperability-panel/branches
I could help with this chore, I would just need higher permission on the repo.
Actually I have rights to delete branches from merged PRs so I did it. You still have some old branches which never got PR https://github.com/solid/data-interoperability-panel/branches/all
elf-pavlik @elf-pavlik just realized that HackMD has build in mermaid diagrams support https://hackmd.io/YB1QIm9lS3OEVW5KUFDz2g?view
elf Pavlik
@elf-pavlik

@justinwb @ericprud I've been looking at Data Grant and it's flavors Referenced Data Grant, Remote Data Grant, Referenced Remote Data Grant

As I understand it, depending on value of interop:scopeOfGrant one of other properties is expected to be set on the Grant itself.

For example interop:scopeOfGrant interop:SelectedInstances ; would require setting hasDataInstance

Now looking at shape

<#DataGrantShape> {
  a [ interop:DataGrant ] ;
  interop:hasAccessGrant @<#:AccessGrantShape> ;
  interop:satisfiesAccessNeed @<#:AccessNeedShape> ;
  interop:registeredShapeTree IRI ;
  interop:hasDataRegistration IRI ;  
  interop:accessMode @<#:AccessModes>+ ;
  interop:scopeOfGrant @<#:DataGrantScopes> ;  
  interop:hasDataInstance IRI* ;  
  interop:hasReferencedDataGrant @<#:ReferencedDataGrantShape> 
}

zero or more hasDataInstance are valid, no matter value of scopeOfGrant

Would it make sense to create more specific shapes (one per data grant scope), which would have stricter definitions? eg.

<#DataGrantShapeSelectedInstances> {
  a [ interop:DataGrant ] ;
  interop:hasAccessGrant @<#:AccessGrantShape> ;
  interop:satisfiesAccessNeed @<#:AccessNeedShape> ;
  interop:registeredShapeTree IRI ;
  interop:hasDataRegistration IRI ;  
  interop:accessMode @<#:AccessModes>+ ;
  interop:scopeOfGrant [  interop:SelectedInstances ] ;  
  interop:hasDataInstance IRI+ ;  
  interop:hasReferencedDataGrant @<#:ReferencedDataGrantShape> 
}

etc.

elf Pavlik
@elf-pavlik
I'm afraid that with just one liberal shape, invalid data grants would still validate.
elf Pavlik
@elf-pavlik
I would even consider defining specific sub classes of DataGrant instead of using interop:scopeOfGrant.
<#DataGrantForSelectedInstancesShape> {
  a [ interop:DataGrantForSelectedInstances ] ;
  interop:hasAccessGrant @<#:AccessGrantShape> ;
  interop:satisfiesAccessNeed @<#:AccessNeedShape> ;
  interop:registeredShapeTree IRI ;
  interop:hasDataRegistration IRI ;  
  interop:accessMode @<#:AccessModes>+ ;
  interop:hasDataInstance IRI+ ;  
  interop:hasReferencedDataGrant @<#:ReferencedDataGrantShape> 
}
BTW while referencing specific instances why do we also reference the Data Registration? Grantee won't be able to list all the instances, so I assume it won't even have read access to that Data Registration. Possibly we would just have
<#DataGrantForSelectedInstancesShape> {
  a [ interop:DataGrantForSelectedInstances ] ;
  interop:hasAccessGrant @<#:AccessGrantShape> ;
  interop:satisfiesAccessNeed @<#:AccessNeedShape> ;
  interop:registeredShapeTree IRI ;
  interop:accessMode @<#:AccessModes>+ ;
  interop:hasDataInstance IRI+ ;  
  interop:hasReferencedDataGrant @<#:ReferencedDataGrantShape> 
}
elf Pavlik
@elf-pavlik
I captured above in solid/data-interoperability-panel#109 which now would be preferable place to follow up.
elf Pavlik
@elf-pavlik
@justinwb when someone would create ReferencedDataGrant with scope AllInstancesfor DataRegistration xyz, rather thatn creating regular Data Grant for xyz?
I understand ReferencedDataGrant with scope InheritInstances since it relies on which instances are selected in "parent" grant. Actually I don't see reason to use ReferencedDataGrant in any other case other than with InheritInstances.
Justin Bingham
@justinwb
@elf-pavlik yeah i think would could probably tighten the scope of those shapes up more
they were a bit fluid as we kept optimizing the grant structure which is why we probably had a more liberal schema
elf Pavlik
@elf-pavlik

@justinwb when someone would create ReferencedDataGrant with scope AllInstancesfor DataRegistration xyz, rather thatn creating regular Data Grant for xyz?
I understand ReferencedDataGrant with scope InheritInstances since it relies on which instances are selected in "parent" grant. Actually I don't see reason to use ReferencedDataGrant in any other case other than with InheritInstances.

@justinwb and :point_up:

elf Pavlik
@elf-pavlik
I'm trying to visualize different data grants:
AllInstances
Screen Shot 2021-05-13 at 20.10.31.png
InheritSelected
Screen Shot 2021-05-13 at 20.12.01.png
elf Pavlik
@elf-pavlik
SelectedInstances
Screen Shot 2021-05-13 at 20.18.37.png
green - can access
gray - doesn't even know about
red - has link but can't access
tomorrow i'll play with remote data registrations
elf Pavlik
@elf-pavlik
I wonder how others feel about changing Referenced (shape trees, data grants) to Related? This would better fit established concepts like relational database, entity-relationships etc.
I know naming things is hard! I have impression that in this case someone used st:references in Shape Trees spec and it bubbled up from there.
Justin Bingham
@justinwb
yeah that’s exactly where it came from (that it was represented a reference / virtual tree)
main issue i would have with related is that there is still an implied (albeit) virtual hierarchy and i don’t know that related conveys that well enough.
Justin Bingham
@justinwb

@justinwb when someone would create ReferencedDataGrant with scope AllInstancesfor DataRegistration xyz, rather thatn creating regular Data Grant for xyz?
I understand ReferencedDataGrant with scope InheritInstances since it relies on which instances are selected in "parent" grant. Actually I don't see reason to use ReferencedDataGrant in any other case other than with InheritInstances.

InheritInstances is definitely the most important case, but even when presenting AllInstances, there’s a difference in how a root (e.g. project) grant and the behavior of types (like tasks) that inherit based on the root being selected.

we should walk through some examples on tuesday that i’ve got broken out in turtle
elf Pavlik
@elf-pavlik
Sounds great @justinwb. Let's take a look at your examples tomorrow. I'll start HackMD with agenda
Justin Bingham
@justinwb
:+1:
fyi - was a bit late getting last weeks minutes up - see here: solid/data-interoperability-panel#111
<#RemoteAgentDataRegistration> {
  a [interop:RemoteAgentDataRegistration] ;
  interop:registeredBy IRI ;
  interop:registeredWith IRI ;
  interop:registeredAt xsd:dateTime ;
  interop:updatedAt xsd:dateTime ;
  interop:hasDataRegistration IRI ;         
  interop:fromAgent IRI ;                   
  interop:registeredShapeTree IRI ;         
  interop:hasAccessReceipt IRI* ;           
  interop:satisfiesDataGrant IRI+           
}
elf Pavlik
@elf-pavlik
@justinwb sorry for interjecting i'll create issue describing it in detail
Justin Bingham
@justinwb
no worries!
q+ re: scopes other than InheritInstances
Dmitri Zagidulin
@dmitrizagidulin
(have to drop; thanks all!)
elf Pavlik
@elf-pavlik
@justinwb netlify needs to be updated to match how authentication-panel works - run build.sh
elf Pavlik
@elf-pavlik
I'm merging those old PRs into archive, @justinwb could you please take a look at those two stale branches? https://github.com/solid/data-interoperability-panel/branches/stale
elf Pavlik
@elf-pavlik

I'm merging those old PRs into archive

done https://github.com/solid/data-interoperability-panel/pulls

@justinwb I think we should change default branch to main and prune branches in the repo https://github.com/solid/data-interoperability-panel/branches

this repo seems to be one of the last ones still using master as the base branch

Justin Bingham
@justinwb
oh yeah lets switch it
sorry just seeing these other @ s
@elf-pavlik deleted both stale branches :white_check_mark:
elf Pavlik
@elf-pavlik
elf Pavlik
@elf-pavlik
q+
elf Pavlik
@elf-pavlik
hRicklefs
@hRicklefs
One for next week but I would be curious to understand how the conversation we just had relates to what you talk about in the authorisation panel.
1 reply
@elf-pavlik could you send me and @JulietteCarter an invite for the meeting you mentioned to talk about the interfaces.
elf Pavlik
@elf-pavlik
I'm going to send each one of you a direct message
elf Pavlik
@elf-pavlik
I hope we can merge this primer PR on Tuesday solid/data-interoperability-panel#119 -- rendered preview