Profiles of and Profiling with starts

[nicholascar]

A start on the two main Profiling sections.

See https://raw.githack.com/w3c/data-shapes/pro-of-sh-sects/shacl12-profiling/index.html

[ajnelson-nist]

A few nits:

Suggested change

An example of a non-SHACL validator for RDF data that acts as a null profile is the W3C's [[[prov-constraints]]] which provides a list of constraints that apply to provenance data formulated according to the [[[prov-o]]]. [[[prov-constraints]]] implements no constraints beyond those stated or implied in [[[prov-o]]] and the conceptual [[[prov-dm]]], however it does include tests for things that the models do not explicitly model but whose proper use requires, for ordering of temporal entities. Implementations of those constrains <a href="https://github.com/pgroth/prov-check/tree/master">have been made</a> as Python scripts that execute SPARQL allowing for RDF data validation. It would be possible to implement these constrains in SHACL too.

An example of a non-SHACL validator for RDF data that acts as a null profile is the W3C's [[[prov-constraints]]] which provides a list of constraints that apply to provenance data formulated according to [[[prov-o]]]. [[[prov-constraints]]] implements no constraints beyond those stated or implied in [[[prov-o]]] and the conceptual [[[prov-dm]]], however it does include tests for things that the models do not explicitly model but whose proper use requires, for ordering of temporal entities. Implementations of those constraints <a href="https://github.com/pgroth/prov-check/tree/master">have been made</a> as Python scripts that execute SPARQL allowing for RDF data validation. It would be possible to implement those constraints in SHACL too.

[ajnelson-nist]

Separate from the grammar nits, I think this sentence at the end should be dropped:

It would be possible to implement those constraints in SHACL too.

I've been doing work around PROV-CONSTRAINTS for a while, and my current thinking is that not all of the time logic available to PROV-CONSTRAINTS and PROV-O can be done in SHACL or SPARQL alone. One matter is, PROV-O uses xsd:dateTime in its literals, not xsd:dateTimeStamp. Time zones are optional. So, this leads to cases that can't be checked without supplemental information, such as the second example below:

kb:Entity-1
  prov:generatedAtTime "2020-01-01T14:00"^^xsd:dateTime ;
  prov:invalidatedAtTime "2020-01-20T13:59"^^xsd:dateTime ;
  .
kb:Entity-2
  prov:generatedAtTime "2020-01-01T14:00"^^xsd:dateTime ;
  prov:invalidatedAtTime "2020-01-01T13:59"^^xsd:dateTime ;
  .

kb:Entity-1 can be seen as consistent with PROV-CONSTRAINTS because no time zone situation lets the prov:Generation happen after the prov:Invalidation. kb:Entity-2 can be seen as consistent if the context outside these triples happens to include that the generation happened in one time zone and the invalidation happened 59 minutes later the next time zone over. E.g., borrowing from the examples of prov:atLocation:

kb:Entity-2
  prov:qualifiedGeneration [
    prov:atlocation <http://example.org/kb/Denver> ;  # UTC-7 in January
  ] ;
  prov:qualifiedInvalidation [
    prov:atlocation <http://example.org/kb/Seattle> ;  # UTC-8 in January
  ] ;
  .

I'm not sure how feasible it is to implement this in SHACL alone, even with the current working-group's development. Some application logic would need to know PROV's vocabulary well enough to interpret locations, time zones for locations, and timezone-aware timestamps to compute temporal ordering. Temporal ordering would provide an alternative implementation (or a source for imputed :precedes triples) of the constraint-in-English "Generation of an entity precedes its invalidation," supplementing the link-based implementation in Constraint 36.

[ajnelson-nist]

Unresolving conversation. It was probably a technical accident waiting to happen from me putting two unrelated discussions atop one suggestion. Apologies for the confusion.
I still think we should work through whether the last sentence should be dropped.

[nicholascar]

I've removed the problematic sentence. It's not required

[ajnelson-nist]

Not ACKing or NACKing yet - this mostly looks good, but there is one sentence I think should be dropped, and a document-relationship to dx-prof worth clarifying.

[YoucTagh]

I believe this is a good starting point. I will validate it once we have discussed the concerns raised by @ajnelson-nist above.