Vocab Files Validation

[bardonelgen]

Might someone please run the reference files through a validator or linter ?

Thank you !!

[philarcher]

Er... we do. What's up @bardonelgen ? We don't want invalid stuff here so please don't be shy in pointing out errors!

[bardonelgen]

Hm. Just something I ran into during implementation (and all of my parsers refused to read it…):

There appears to be a somewhat unhappy asterisk at the end of gs1:defaultLink e.g. in line 14090 of the JSON.

Since I cannot find the respective term in the PDF version of the specification, I’m not completely sure, what the actual intention is here; probably more to create something like a list ? Or simple set of value-options as in https://www.w3.org/2001/sw/BestPractices/OEP/Lists-of-values-20040625/ ?

Do you want gs1:defaultLink to be provided as a list as soon as more than one instance ocurrs ?

At least I am not familiar with any asterisk-style syntax for this task… – or am I out-of-date ?

[bardonelgen]

The problem seems to arise from the fact, that while a "*" is indeed perfectly valid JSON, it becomes an issue as soon as you use it in a Linked Data context where the used keys are resolving into IRIs.

And according to HTTP the "*" then is a reserved character which always needs to be escaped.

[philarcher]

Indeed. @mgh128 has been screaming in my general direction on this one. I suspect we may need to rename that term in the coming months (perhaps literally to 'defaultLinkStar'). The reason I picked it in the first place is that it's a convention used in other places, that the suffix on the end of foo means something like 'a richer version of foo.' (RDF for instance!) But, OK, it was not a good idea here.

[mgh128]

Not exactly screaming, but politely questioning whether it was a good idea. I understand that it's inherited from the use of a trailing asterisk as proposed in https://tools.ietf.org/html/rfc8187, which appears also in https://datatracker.ietf.org/doc/draft-ietf-httpapi-linkset/?include_text=1 ( the Linkset draft by Erik Wilde and Herbert Van de Sompel ).

However, in a world of Linked Data, the use of a restricted URI character such as asterisk is a very bad idea, because it needs percent encoding. We should nowadays consider that for any attribute or property appearing in any data sharing standard, somebody is likely to want to construct a Web URI for it (if the original authors neglected to do so in the first place) - and therefore, it's better if the names of all attributes and properties only use safe URI characters, 0-9, A-Z a-z, hyphen and underscore. Use of any other character is just asking for trouble.

If we really wanted to fix this at the root cause, then perhaps one of us should have the courage to submit a polite constructive comment in response to RFC 8187 and point out that asterisk is problematic and that title etc. should be renamed titleMulti etc., in which the is replaced by something entirely alphabetic, unproblematic and more meaningful. At the same time, we should also provide this feedback to Erik and Herbert that asterisk is problematic and encourage them to adjust their Linkset draft before it reaches RFC status.

[philarcher]

Following this discussion:

1. We have defined gs1:defaultLinkMulti to replace gs1:defaultLink*
2. Turtle and JSON-LD files have been updated
3. This is being treated as an erratum in the underlying spec that is going through its final stages within the GS1 standardization process and so defaultLink* is unlikely ever to see the light of day again, except as a note in the vocabulary here with the status of 'withdrawn'.

[VladimirAlexiev]

@bardonelgen where is the PDF version of the specification that you mentioned?

[bardonelgen]

The PDF can be found at https://www.gs1.org/docs/gs1-smartsearch/GS1_Vocabulary_Standard.pdf — though, be cautious, this appears to be rather inconsistent and outdated compared to what you find here on GitHub…