search

shapetrees / specification

Specification for Shape Trees
https://shapetrees.org
Other
13 stars 5 forks source link

can st:contains be just a special case of general st:references with ecosystem specific predicate #34

Open elf-pavlik opened 3 years ago

elf-pavlik commented 3 years ago

If for LDP ecosystem st:contains would be equivalent to st:references with ldp:contains, possibly we do not need to define st:contains. Possibly we could approach it by documenting (primer maybe) what st:contains provides that can not be acomplished by using st:contains with some ecosystem specific predicate.

justinwb commented 3 years ago

@elf-pavlik can you provide an example of a shape tree as defined with your suggestion?

elf-pavlik commented 3 years ago

https://solid.github.io/data-interoperability-panel/specification/#datareg-datamodel

<#DataRegistrySetTree>
  a st:ShapeTree;
  st:expectsType st:ShapeTreeResource ;
  st:validatedBy <interops#DataRegistrySetShape> .
<#DataRegistryTree>
  a st:ShapeTree;
  st:expectsType st:ShapeTreeContainer ;
  st:validatedBy <interops#DataRegistryShape> ;
  st:contains <#DataRegistrationTree> ,
              st:AllowNone .
<#DataRegistrationTree>
  a st:ShapeTree;
  st:expectsType st:ShapeTreeContainer ;
  st:validatedBy <interops#DataRegistrationShape> .

I wonder if it could look something like like:

<#DataRegistrySetTree>
  a st:ShapeTree;
  st:validatedBy <interops#DataRegistrySetShape> ;
  st:references [
    st:hasShapeTree <#DataRegistryTree> ;
    st:traverseViaShapePath
      "@<interops#DataRegistrySetShape>/interop:hasRegistry/@<interops#DataRegistryShape>" ;
  ] .
<#DataRegistryTree>
  a st:ShapeTree;
  st:validatedBy <interops#DataRegistryShape> .
  st:references [
    st:hasShapeTree <#DataRegistrationTree> ;
    st:traverseViaShapePath
      "@<interops#DataRegistryShape>/interop:hasRegistration/@<interops#DataRegistrationShape>" ;
  ] .
<#DataRegistrationTree>
  a st:ShapeTree;
  st:validatedBy <interops#DataRegistrationShape> .

In this case we have distinct properties defined in interop vocab and schemas defined in interops namespace. In specific properties and scheas don't exist, we could provide generic schemas for ldps:Container and ldps:Resource and reuse existing property ldp:contains getting generic reference:

<#DataRegistryTree>
  a st:ShapeTree;
  st:validatedBy <interops#DataRegistryShape> ;
  st:references [
    st:hasShapeTree <#DataRegistrationTree>;
    st:traverseViaShapePath
      "@<ldps:Container>/ldp:contains/@<ldps:Resource>" ;
  ] .

Possibly RegistrySet, Registry and Registration come bit confusing. During last call we were talking with @ericprud to use Project, Task and Comment and work with that in shapepath examples.

ericprud commented 3 years ago

I think that spec example should have a label (i.e. a directory name) so folks know not only that there's a Container for DataRegistryShapes, but where it is.

I haven't figured out how an app can look at that references construct and know that the DataRegistrationTree items go into a specific container, unless they ecosystem is supposed to provide that mapping. If so, I don't think that, in the case of nested hierarchies, you'd have a 1:1 mapping from ShapeTree to Container. Given that, you need additional info in order to know what container to POST a new DataRegistrationTree to.

BTW, the current ShapePath syntax for selecting TripleConstraint by predicate in some shape is @<Shape>.<predicate> (or with prefixes: @pre:Shape.pre:predicate (like SPARQL, you gotta escape trailing '.'s in localNames)).

elf-pavlik commented 3 years ago

Given that, you need additional info in order to know what container to POST a new DataRegistrationTree to.

Yeah, I would imagine some hypermedia control letting client know how to append to that collection. I wonder if we could first consider how we express the hierarchy and than look at explicit and implicit affordances.