wording changes re normalization

It is easy to forget that in general RDF canonicalization is Graph-Isomorphism complete, and hence too difficult for production use at scale. [1]

On the other hand, within any particular application domain, which is the scope of the users of the proposed working group, normalizing an RDF graph tends to be fairly straightforward.

Mindful of this I suggest:

Section 1
Replace;
[[
In addressing these issues, the WG will consider whether it is necessary, practical or desireable to normalize a graph prior to validation. That is, whether an algorithm can and should be defined that creates a canonical form of a given graph.
]]
With
[[
In addressing these issues, the WG will consider whether it is necessary, practical or desireable to normalize a graph as part of validation. That is, whether an algorithm can and should be defined that creates a representation of a given graph, or an equivalent graph, that is canonical for the purpose of processing with respect to a specific machine-readable interface definition.
]]

Rationale: the answer to the current question "should such an algorithm be defined" is simply "no, it should not"
I weaken the question to indicate that the algorithm is part of validation, not prior, and that the canonicalization is not independent of the application but application dependent.

Section 3:
Replace:
[[
The WG MAY produce a Recommendation for graph normalization.
]]
With
[[
3. OPTIONAL - A graph normalization method, suitable for  the use cases determined by the group. This should not be a general purpose RDF canonicalization algorithm, see [1].
]]
Rationale: consistent styling with other deliverables; restricting scope to avoid the impossible.


[1]
http://www.hpl.hp.com/techreports/2003/HPL-2003-142.pdf