Re: Questions on Use Cases

On 01/20/2016 10:48 AM, Karen Coyle wrote:
> The list of Use Cases that I wasn't sure about got pretty long - sorry. Simon
> helped me cut it down some, and in some cases I've left in the UC but added
> his comment as a starting point. Since the list is long, it might make sense
> only to point out those that you think
> 1) should be covered but are not
> 2) are out of scope
> 
> I'll work next on the document for suggested tests. Unless others think this
> isn't a good idea, I will create a template in markdown to use as the markup,
> since I figure we'll be looking at it online in github. Other options are text
> or html -- let me know if you have a strong preference.
> 
> -----------------
> 
> 
> UC10 Requires the possibility to specify default values. Open issue - was 111
> http://w3c.github.io/data-shapes/data-shapes-ucr/#uc10-cardinality-0
>     KC: Is this satisfied with sh:hasValue?

The parts of this that are not UI-related are covered by sh:valueClass (or
whatever it is called now).

> UC17 Specifying subsets of data
> http://w3c.github.io/data-shapes/data-shapes-ucr/#uc17-specifing-subsets-of-data
> Summary: Defines a use case, where shape definitions could be used to
> partition a data set (i.e. one could query for individuals that are compliant
> to a specific shape).
>     KC: is this sh:filter, or Arthur's sh:partition?

Shapes can be used to partition an RDF graph.  That is sufficient for this use
case.  Filters are irrelevant.

> UC21: SKOS constraints
> http://w3c.github.io/data-shapes/data-shapes-ucr/#uc21-skos-constraints
> Summary: Requires the possibility to define complex constraints similar to
> those defined in the SKOS vocabulary

I don't know all the constraints in SKOS.  Disjointness between property
values (mentioned in the user case) is not covered so far, I think.  Any use
of subproperties in SKOS is not covered.

> UC25: Primary Keys with URI patterns
> http://w3c.github.io/data-shapes/data-shapes-ucr/#uc25-primary-keys-with-uri-patterns
> 
> It is very common to have a single property that uniquely identifies instances
> of a given class. For example, when you import legacy data from a spreadsheet,
> it should be possible to automatically produce URIs based on a given primary
> key column. The proposed solution here is to define a standard vocabulary to
> represent the primary key and a suitable URI pattern. This information can
> then be used both for constraint checking of existing instances, and to
> construct new (valid) instances. One requirement here is advanced string
> processing, including the ability to turn a partial URI and a literal value
> into a new URI.
>     Simon: One could use sh:derivedValues to specify that the value of a
> particular property must comply to a certain URI which is defined&returned by
> sh:derivedValue's SPARQL snippet.

I believe that sh:pattern handles this.

> UC26: rdf:Lists and ordered data
> http://w3c.github.io/data-shapes/data-shapes-ucr/#uc26-rdf-lists-and-ordered-data
> Summary: Requires the possibility to check whether all members of a list have
> certain characteristics.

This can be done in the SPARQL extension.

> UC28: Self-Describing Linked Data resources
> http://w3c.github.io/data-shapes/data-shapes-ucr/#uc28-self-describing-linked-data-resources
> 
> Summary: The constraint language must be able to validate information received
> from dereferencing the value IRI, e.g. check whether the value is a member of
> a skos:ConceptScheme
>     Simon: Out of scope

Agreed.

> UC30: PROV constraints
> http://w3c.github.io/data-shapes/data-shapes-ucr/#uc30-prov-constraints
> Requires the possibility to express constraints as defined in PROV's library
> of constraints.

If it can be done in SPARQL then it should be OK in SHACL, so the SPARQL
extension is relevant.

> UC35: Describe disconnected graphs
> http://w3c.github.io/data-shapes/data-shapes-ucr/#uc35-describe-disconnected-graphs
> 
> Summary: States the requirement, that constraints over RDF graphs must be
> describable for both disconnected and connected graphs.

The part of this that seems to be actionable works in SHACL as is.  Relevant
portions of SPARQL as scopes (both node-based and class-based) as they allow
starting from multiple parts in a graph.

> UC38: Describing and validating LDP
> http://w3c.github.io/data-shapes/data-shapes-ucr/#uc38-describing-and-validating-ldp

> Summary: Define RDF graphs to be generated from spread sheet software and made
> available through a LDP.
> Provide a comparison function for RDF graphs.
>     Simon: Covered, although SHACL does not define any built-in constructs
> that compare entire RDF graphs though (out of scope).

As far as I can tell this most of this is standard SHACL. Number constraints
on roles, .... One wrinkle is if the UC requires one float value overall, but
this doesn't seem like it is what is really wanted. Language-specific
cardinality constraints is not currently covered, as far as I know, but maybe
should be.

> UC40: Describing inline content versus references
> http://w3c.github.io/data-shapes/data-shapes-ucr/#uc40-describing-inline-content-versus-references
> 
> Summary: The constraint language must make it possible to indicate IRIs that
> must be de-referenced.
>     Simon: Out of scope

Agreed.

peter

Received on Thursday, 21 January 2016 20:32:57 UTC