Consider ordering of properties

[kcoyle]

Issue #14 relates to the ordering of the values of a property. There is also the question of the ordering of properties themselves, as this example (copied from #14) shows:

I want to add that I think we also have a case for ordering properties. Using Justin's example from #13 this could look like:

Ordered properties within a shape would be entered in different rows in the table or CSV. The CSV file would (always?) retain the order, which again could be carried forward. This, I believe, is your ISBN example where ISBN is a shape with various properties, like value, qualifier, note. If you desire a specific statement of order you could add a local column for order number which your applications would then use.

shapeID	shapeLabel	propertyID	propertyLabel	mandatory	repeatable	orderNo	valueNodeType	valueDataType	valueConstraint	valueConstraintType	valueShape	note
pcc:bf2:Identifiers:ISBN	Identifiers--ISBN	http://www.w3.org/1999/02/22-rdf-syntax-ns#type	Class	true	false	1		IRI	http://id.loc.gov/ontologies/bibframe/Isbn
pcc:bf2:Identifiers:ISBN	Identifiers--ISBN	http://sinopia.io/vocabulary/hasResourceTemplate	Profile ID	false	false	2		LITERAL	pcc:bf2:Identifiers:ISBN
pcc:bf2:Identifiers:ISBN	Identifiers--ISBN	http://www.w3.org/1999/02/22-rdf-syntax-ns#value	ISBN	false	false	3		LITERAL
pcc:bf2:Identifiers:ISBN	Identifiers--ISBN	http://id.loc.gov/ontologies/bibframe/qualifier	Qualifier	false	false	4		LITERAL
pcc:bf2:Identifiers:ISBN	Identifiers--ISBN	http://id.loc.gov/ontologies/bibframe/note	Note	false	true	5		BNODE		pcc:bf2:Note:GeneralNote
pcc:bf2:Identifiers:ISBN	Identifiers--ISBN	http://id.loc.gov/ontologies/bibframe/status	"Incorrect, Invalid or Canceled?"	false	true	6		LITERAL	IRI		sinopia:LabeledResource

A column of this nature could be added to the TAP, of course, but we hesitated because we had questions relating to ordering properties and ordering shapes, and we simply haven't thought that through. If we can limit to ordering only properties within each shape, then that may make the requirement more implementable. If we must order both shapes and properties that would require two separate columns.

[philbarker]

@kcoyle : by ordering properties within a shape in the CSV, do you mean the way that the TAP is presented?

SHACL allows an ordering of property shapes, but in that case I think the use case is to use these when building user-interfaces for data input--which may not be a CSV--rather than how the shacl file is presented. That might be an easy use case we could address, but we could just as easily leave it open to implementers to experiment.

On ordering of properties in the TAP, I would have thought that the order of rows is fixed? I mean, I would be pretty annoyed if the order of rows in an accounting spreadsheet got changed. So isn't the default that TAPs are ordered?

[kcoyle]

@philbarker Thanks! The request we've had is to define an order that would be enforced in the resulting RDF graphs. It wasn't mentioned but I can see a need for order in the input interface, similar to the SHACL features you allude to. I agree that the order of rows in the table itself is not a problem, but I can imagine that the table order may not be the same as the desired order for input interfaces or the eventual instance data. What I don't know is how complicated this can become, and if different columns would be needed for the ordering of properties vs ordering of shapes. My gut feeling is that this will be out of scope for TAP, however we should discuss and decide and document our reasoning. I would very much appreciate help in thinking this through.

[tombaker]

@philbarker

On ordering of properties in the TAP, I would have thought that the order of rows is fixed? I mean, I would be pretty annoyed if the order of rows in an accounting spreadsheet got changed. So isn't the default that TAPs are ordered?

That is my understanding as well. ShEx and JSON-LD retain ordering.

@kcoyle

The CSV file would (always?) retain the order,

+1 for "always" - at least that should be the expectation.

[kcoyle]

Just to leave here the information about SHACL, which can give an order to properties within a "group":

[kcoyle]

@philbarker

On ordering of properties in the TAP, I would have thought that the order of rows is fixed? I mean, I would be pretty annoyed if the order of rows in an accounting spreadsheet got changed. So isn't the default that TAPs are ordered?

tombaker: That is my understanding as well. ShEx and JSON-LD retain ordering.

I don't believe that we are talking of retaining the order of rows in output, just in input. The discussions we've had about allowing shapes to not be in intiguous rows but gathering all rows of a shape during processing, means that the output rows may not be in the same order as the input. We should decide where and when order matters on output, if at all.

By non-contiguous I mean:
Shape -- property
A -- propA
B -- propB
A -- propC

would result in
A
-- propA
-- probC
B
-- propB

[kcoyle]

Close. Added to cookbook (https://hackmd.io/V3LGdBdxTrOid57M2wJUlw0)