American Standard Code for Information Interchange

[github-actions[bot]]

http://purl.org/np/RAG4lvGYEn3Q0b1FGZW9y4Ccf_FjUGexwnPZwT3YTJXYc

Review

Item	Detail
Person name	Robin Bramley
ORCID	0000-0002-8958-8087
FSR long name	American Standard Code for Information Interchange
FSR thing	http://purl.org/np/RAG4lvGYEn3Q0b1FGZW9y4Ccf_FjUGexwnPZwT3YTJXYc#ASCII
FSR np identifier	http://purl.org/np/RAG4lvGYEn3Q0b1FGZW9y4Ccf_FjUGexwnPZwT3YTJXYc
URI of duplicate(s) (multiple separated by ';')	N/A
Links correct	N
Proposed Links	https://standards.incits.org/apps/group_public/project/details.php?project_id=3624
Definition ok	Y
FSR types ok	N - should just be Knowledge-representation-language
FAIRSharing DOI to be added	N/A
FSR creator in pubinfo (yellow): FIP Wizard (F) or the ORCID	F
proposal: accept (A) / Improve (I) / Retract (R) / Disapprove (D)	I
Proposed changes:	Reduce types to just knowledge representation language; add URL for INCITS 4-1986 (R2022); change label to prefix with ASCII |

Revisions

Item	Action
actual changes: accept (A) / Improve (I) / Retract (R) / Disapprove (D),URI of updated FSR
if FSR is useless, check affected FIPs or SIPs (title)
Updated (U) /Deleted (D) entry in FIP/SIP

[rbramley]

@gofair-foundation/fsr_triage would welcome a review.

[rbramley]

@IseultLynch pointed out that the proposed URL was not working. It appears that it now requires authentication to access. I'll see if I can find an alternative resource.

[IseultLynch]

Hi Robin, the proposed link (https://standards.incits.org/apps/group_public/project/details.php?project_id=3624) say page not found

Agree that ASCII is not a Semantic Model, Provenance model or structured vocabulary.

Are you suggesting that ASCII itself is not a community protocol, but that we should add ASCII Transmission Control Protocol (or ASCII TCP) as a separate FER for the communication protocol? I know many people refer to ASCII as a communication protocol but I guess they mean the ASCII TCP...

[IseultLynch]

How about one of these: https://www.asciitable.com/ https://www.cs.cmu.edu/~pattis/15-1XX/common/handouts/ascii.html (although the website link in this doesn't work either)

[rbramley]

An alternative definition from the description of the standard (https://webstore.ansi.org/standards/incits/incits1986r2022) is: "Details information interchange among information processing systems, communication systems, and associated equipment. Specifies a set of 128 characters (control characters and graphics characters such as letters, digits, and symbols) with their coded representation."

Great idea to include an ASCII lookup table, how about linking to the one on wikipedia? https://simple.wikipedia.org/wiki/ASCII

[rbramley]

Are you suggesting that ASCII itself is not a community protocol, but that we should add ASCII Transmission Control Protocol (or ASCII TCP) as a separate FER for the communication protocol? I know many people refer to ASCII as a communication protocol but I guess they mean the ASCII TCP...

Yes I am saying that ASCII isn't a communication protocol.

Communication protocols are often layered (e.g. the prescriptive OSI 7 layer model: https://simple.wikipedia.org/wiki/OSI_model); a simpler TCP/IP "Internet" model (RFC 1122) has 4 abstraction layers (top down): Application, Transport, Internet, Link. An example of this would be HTTP over TCP/IP over Ethernet.

For FIPs, can we assume that the prevalence of the Internet means that we are only interested in the Application layer? So we would need FERs for HTTP, FTP, etc., plus the application-layer 'overlays' for REST, SOAP, ...

It might be nice if the FIP ontology could have decorator/mixins for Transport Layer Security (i.e. so that HTTPS wouldn't need to be a separate FER), content types and character sets. (@mabablue)

RFC 2277: IETF Policy on Character Sets and Languages starts with the introductory statement "The Internet is international." and declares UTF-8 as mandatory, with other character sets as optional.

ASCII can also be used to mean "plain text", so that could be added to a FER with a mixin; e.g. if we need to describe the case where data is available as a CSV from an HTTPS endpoint, we could model it as FER:HTTP + content-type:text/csv + security:tls.

Maybe it's worth further discussion next week?