[Standards] URGENT: namespace strings, vote on whether I can forward the proposal to the BoD

[Piotr Banski]

Dear Dieter,

Thanks for the quick reaction, and especially for a possible 
interpretation of your question that you surely didn't intend, but that 
made me reflect on the possible strategies of the CSC towards the 
"requesting agencies" in cases like the hopefully upcoming one 
concerning ISO. Maybe we can come up with a sensible policy together.

In the first step, let me shove ISO aside, because the ballot I'm asking 
for right now does not concern ISO (although the direct motivation for 
my message came from what happened in a DIN telco). It concerns the 
general policy of whether we want to have a mechanism by which CLARIN 
regulates the use of "clarin.eu"-based namespace strings.

(first remark: if I said "allow" anywhere before, I think we should 
replace that word with "regulate", because I don't think that this is a 
matter of _permission_ unless "CLARIN" is a registered trademark and 
there is a battery of lawyers ready to be paid for fighting to enforce 
that trademark in obscure namespace strings; "regulate" would work great 
especially in connection with a policy that requires an informative web 
page to be associated with the requested namespace URI)

In the second step, I am now wondering if we should by policy 
distinguish between (a) expert bodies such as ISO committees, and 
especially a committee with which a formal liaison exists, hence an 
implied measure of trust that precludes the CSC from playing a role of a 
potential bottleneck in the ISO process, and (b) "other bodies", where 
we might actually be entitled or maybe even expected to play an expert 
role. I'm wondering if such a distinction should be made formally, or 
rather come up in the discussion of individual cases, as in:

Case (a):
reporter: "TC37SC4 has requested a new namespace, with the postfix 'maf/n1'"
committee: "have they submitted text for the corresponding web page? is 
it readable? if so, proceed"

Case (b):
reporter: "Project XY has requested a namespace for their XML 
vocabulary, with the postfix 'xy/fluff/n1'"
committee: "What is Project XY? What centre is it located in? Let's have 
a look at their suggested info text, let's have a look at the project, 
and then decide"

It seems to me that leaving this kind of issues for discussion might be 
a friendlier, and first of all, a more flexible strategy than 
categorizing the "requesting agencies" into "expert bodies" and 
"non-expert bodies", because I am sure we could stumble upon cases where 
even an act of such pre-categorization could unnecessarily cause bad blood.

I would love to know the members' thoughts on that.

---------------------
I shoved ISO aside at first, and now I'm reaching into my hat again to 
pull it back out and address the question on whether the CSC can look at 
the specification that urgently needs a new namespace. The answer is, to 
my mind, standard: ISO documents at late stages in the ISO process can 
only be shared within the ISO committee where they were produced or its 
national mirror committees. When preparing the liaison between 
CLARIN-ERIC and ISO TC37SC4, Andreas Witt tried to bargain for a 
modification of this rule, but as far as I recall, there was no way to 
change this within category-A liaison. Now that I'm looking at the 
relevant section of ISO directives [1], I am wondering what the 
beautifully vague statement that "Technical committees and subcommittees 
shall seek the full and, if possible, formal backing of the 
organizations having liaison status for each document in which the 
latter is interested" can possibly entail. I don't think this is an 
escape hatch (or a hidden lever), but maybe Andreas can shed more light 
on this, at some point. For practical purposes, however, it would seem 
strange to me if we were to in a way challenge ISO to give up its 
principles for the sake of a namespace string in a standard produced by 
one subcommittee. In my glass ball, I see ISO shrugging this request 
away and allowing the standard to drop from the publication process -- 
we wouldn't be hitting ISO but rather SC4 experts, whose work would 
simply turn out to have been in vain.

The SC4 specification that is for sure affected by the namespace issue 
is "SynAF Part 2" a.k.a "the standard formerly known as ISO Tiger" [2], 
which would probably be in print right now if not for this last-minute 
hiccup. Another proposed standard that may be at some point subject to 
this predicament is... CMDI part 2 [3], and Thorsten Trippel would 
surely be able to say if this particular item would need a CLARIN-based 
namespace -- but even if it doesn't require one, what's important is 
that some of the affected specifications are or may be rather important 
to CLARIN itself, so we certainly want to be accommodating and flexible 
here, rather than risk creating a bottleneck.

Apologies for this lengthy reply to a short question :-) But I felt that 
there was a need to tease two things apart at first, and that a space 
was opening for a policy discussion concerning the potential regulatory 
role of the CSC in the namespace business.

Best regards,

    Piotr

[1]: http://www.iso.org/sites/directives/directives.html#Section-sec_1.17.5
[2]: https://www.iso.org/standard/62491.html
[3]: https://www.iso.org/standard/64579.html



On 20/10/17 18:11, Dieter Van Uytvanck wrote:
> On 20/10/2017 17:12, Piotr Banski wrote:
>> the need for potential clarin.eu-based namespace strings has become very
>> urgent and the ISO process will automatically delete the standards in
>> question (among them SynAF part 2, up till recently called "ISO Tiger"
>> but now rebranded not to use the "ISO" in the name)
> Thank you for this proposal Piotr. Can you tell us where we can find a
> copy of the standard specification or proposal? Would be nice to know in
> detail to which standard we are assigning the clarin.eu namespace.
>
> best,


-- 
Piotr Bański, Ph.D.
Senior Researcher,
Institut für Deutsche Sprache,
R5 6-13
68-161 Mannheim, Germany

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clarin.eu/pipermail/standards/attachments/20171021/eb67f28a/attachment.html>