Questions on Use Cases

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?

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?

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

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.

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.

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

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.

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.

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).

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



-- 
Karen Coyle
kcoyle@kcoyle.net http://kcoyle.net
m: 1-510-435-8234
skype: kcoylenet/+1-510-984-3600

Received on Wednesday, 20 January 2016 18:49:09 UTC