{ "model": { "rank": 3732, "code": "thing-q42283", "model_id": "vr.tr.file-transfer-protocol", "name": "File Transfer Protocol", "purpose": "Enable an agent to recognise File Transfer Protocol (FTP), assess an implementation or session, and determine which file operations are supported, authorised and safe.", "family": "Thing Registry", "category": "Information and virtual systems", "status": "research-draft", "kind": "thing", "plane": "INF", "domain": "INF.KNW", "industry": "", "version": "", "url": "/models/thing/q42283/", "tier": 2, "score": 82, "payload": { "layer": "wikidata", "aliases": [ "WebFTP", "anonymous FTP" ], "aliasCount": 2, "merged": 2, "knownIn": 82, "facets": null, "markers": [], "lexicalClass": "", "senseRank": null, "alsoRegisteredAs": null, "source": { "dataset": "wikidata", "item": "Q42283", "url": "https://www.wikidata.org/wiki/Q42283", "license": "CC0 1.0" } }, "research": { "vercy": "1.0-draft", "publication": { "status": "research-draft", "adjudicationStatus": "unreviewed", "publishableCanonical": false, "generatedAt": "2026-09-07T15:01:47Z", "providers": [ "Codex" ], "breadth": "recalled by Codex without web access - no source was read", "missingProviders": [], "pass": 2, "cost": { "grok": { "seconds": 24.4, "error": "Reading additional input from stdin...\nOpenAI Codex v0.153.3\n--------\nworkdir: R:\\02_PROJECTS\\02_Meta_Models_Platforms\\Ver.cy\\current\\thing-registry-backlog\nmodel: gpt-6-astra\nprovider: openai\napproval: never\nsandbox: read-only\nreasoning effort: none\nreasoning summaries: none\nsession id: 01a07c61-a5d2-71d1-a31c-5253845dab6c\n--------\nuser\nDescribe what is already known about one registered thing. Answer as JSON only, no prose around it.\n\nThing: File Transfer Protocol\nSense to describe: (none recorded)\nDomain code: INF.KNW\nAlso known as: (none)\n\n\nContext for this batch of 801 things:\n# Batch 004", "usd": 0, "recall": true }, "codex": { "seconds": 139, "error": "Reading additional input from stdin...\nOpenAI Codex v0.153.3\n--------\nworkdir: R:\\02_PROJECTS\\02_Meta_Models_Platforms\\Ver.cy\\current\\thing-registry-backlog\nmodel: gpt-6-astra\nprovider: openai\napproval: never\nsandbox: read-only\nreasoning effort: none\nreasoning summaries: none\nsession id: 01a07c61-a5dd-7661-917b-4d386974e3ac\n--------\nuser\nYou are drafting a Vercy meta-model for one registered thing. Answer as JSON only, no prose around it.\n\nThing: File Transfer Protocol\nRegistry id: vr.tr.file-transfer-protocol\nPlane / domain: INF / INF.KNW\nRegistry definition: (none recorded)\nNames folded into" } } }, "metaModel": { "id": "THING-Q42283", "registryId": "vr.tr.file-transfer-protocol", "name": "File Transfer Protocol", "version": "0.1.0-research.1", "entryKind": "thing", "family": "Thing Registry", "domain": [ "INF.KNW" ], "status": "research-draft" }, "canonicalUrl": "https://ver.cy/models/thing/q42283/", "model": { "registry_id": "vr.tr.file-transfer-protocol", "name": "File Transfer Protocol", "purpose": "Enable an agent to recognise File Transfer Protocol (FTP), assess an implementation or session, and determine which file operations are supported, authorised and safe.", "definition": "File Transfer Protocol (FTP) is an application-layer protocol for transferring files between a client and a server over TCP, using a control connection and separate data connections for file contents and directory listings.", "scope_statement": "This model owns FTP as an application-layer protocol and the protocol-specific evidence needed to assess implementations, endpoints and sessions; it does not treat FTP as a discipline or own the transferred content.", "in_scope": [ "FTP identity, specifications and negotiated extensions", "Control-channel commands, replies and session state", "Separate data connections and active or passive operation", "File-transfer representations, directory operations and restart behaviour", "Authentication, transport protection and operation permissions", "Protocol-specific interoperability and transfer-outcome evidence" ], "out_of_scope": [ "SFTP, which is a separate protocol associated with SSH", "HTTP file delivery and other neighbouring transfer protocols", "General TCP/IP routing, firewall administration and network infrastructure", "File contents, business meaning and document lifecycle", "General filesystem design, storage durability and backup policy", "FTP client and server product management beyond protocol behaviour" ], "distinguishing_features": [ "An FTP exchange uses a command-and-reply control connection and separate connections for directory listings or file data.", "FTP control exchanges include commands such as USER, TYPE, RETR and STOR, with structured three-digit replies.", "Active and passive FTP differ in which peer initiates the data connection; this is distinct from the direction in which a file is transferred.", "FTPS applies TLS protection to FTP; SFTP does not use FTP's command and separate-data-connection model.", "FTP transfer settings can affect representation, so a successful text-mode transfer does not necessarily imply byte-for-byte identity." ], "characteristics": [ { "name": "Protocol specification and extension profile", "kind": "relation", "unit_or_values": "Applicable FTP specifications, extensions and implementation documentation", "why_it_matters": "Determines which behaviours are required, optional or implementation-specific." }, { "name": "Advertised and observed capabilities", "kind": "category", "unit_or_values": "Advertised features; commands accepted, rejected or untested", "why_it_matters": "Capability advertisements and demonstrated support provide different evidence." }, { "name": "Control-session state", "kind": "state", "unit_or_values": "Disconnected, connected, authenticating, authenticated, transfer pending, closing", "why_it_matters": "Command validity and the interpretation of replies depend on session state." }, { "name": "Data-connection mode", "kind": "category", "unit_or_values": "Active or passive; PORT, EPRT, PASV or EPSV where supported", "why_it_matters": "Determines connection initiation and influences reachability through network boundaries." }, { "name": "Transfer representation", "kind": "category", "unit_or_values": "Negotiated TYPE, including ASCII or image/binary", "why_it_matters": "Representation affects transformations and the meaning of size or identity comparisons." }, { "name": "Authentication context", "kind": "relation", "unit_or_values": "Session identity, authentication mechanism and applicable authorisation policy", "why_it_matters": "Establishes whose permissions govern requested operations." }, { "name": "Channel protection", "kind": "state", "unit_or_values": "Control and data protection recorded separately, including TLS negotiation and peer-validation results", "why_it_matters": "A protected control connection alone does not establish that file data is protected." }, { "name": "Requested file operation", "kind": "category", "unit_or_values": "Retrieve, store, append, list, inspect metadata, rename, delete or manage directories", "why_it_matters": "Different operations require different permissions and carry different mutation risks." }, { "name": "Transferred data volume", "kind": "measurement", "unit_or_values": "Bytes, with whether counted on the connection or in the local representation", "why_it_matters": "Supports progress and outcome assessment without assuming counts prove integrity." }, { "name": "Transfer outcome", "kind": "state", "unit_or_values": "Not started, in progress, protocol-reported success, independently verified, failed or indeterminate", "why_it_matters": "Separates successful protocol completion from verified content and uncertain partial effects." } ], "affordances": [ "Identify whether an endpoint speaks FTP and determine its supported extension profile.", "Establish an authorised session with the required peer validation and channel protection.", "Select and test a compatible active or passive data-connection method.", "List, retrieve or modify remote files within explicit operation permissions.", "Assess whether an interrupted transfer can be resumed or retried without unacceptable duplication or overwrite.", "Interpret replies and verification evidence to report successful, failed or indeterminate outcomes." ] }, "sources": [], "structure": { "bundles": [ { "id": "ftp-identity-and-profile", "name": "FTP identity and profile", "description": "Establishes the protocol boundary and the capabilities applicable to a particular implementation.", "rationale": "An agent must distinguish FTP from similarly named protocols and avoid assuming every FTP endpoint supports the same extensions.", "layers": [ { "id": "protocol-boundary", "name": "Protocol boundary", "description": "Identifies the FTP sense and its relationship to protected variants.", "findings": [ { "id": "ftp-identification-evidence", "name": "FTP identification evidence", "description": "Record evidence of FTP command-and-reply behaviour rather than relying solely on a service label or port.", "questions": [ { "text": "What observed exchange or authoritative documentation identifies this service as FTP?", "kind": "definition", "id": "ftp-identification-evidence-q01" }, { "text": "Does the service use FTP, FTP with TLS, or a separate protocol such as SFTP?", "kind": "boundary", "id": "ftp-identification-evidence-q02" } ] } ] }, { "id": "extension-profile", "name": "Extension profile", "description": "Separates specified, advertised and demonstrated capabilities.", "findings": [ { "id": "capability-evidence", "name": "Capability evidence", "description": "Record the applicable specifications and evidence for individual supported commands or extensions.", "questions": [ { "text": "Which specifications and implementation documents define this endpoint's claimed FTP profile?", "kind": "provenance", "id": "capability-evidence-q01" }, { "text": "Which capabilities are advertised through FEAT or documentation, and which have been confirmed by permitted use?", "kind": "measurement", "id": "capability-evidence-q02" } ] } ] } ] }, { "id": "control-session-and-replies", "name": "Control session and replies", "description": "Models command sequencing, session context and interpretation of server responses.", "rationale": "FTP replies can indicate intermediate progress, a request for further input or final completion; confusing these leads to incorrect actions.", "layers": [ { "id": "session-context", "name": "Session context", "description": "Tracks the protocol context in which a command will execute.", "findings": [ { "id": "command-preconditions", "name": "Command preconditions", "description": "Record authentication state, working directory and negotiated settings relevant to the next command.", "questions": [ { "text": "What identity, working directory and transfer settings currently apply to this control session?", "kind": "measurement", "id": "command-preconditions-q01" }, { "text": "What state transitions or preceding commands are required before the requested operation?", "kind": "action", "id": "command-preconditions-q02" } ] } ] }, { "id": "reply-interpretation", "name": "Reply interpretation", "description": "Connects replies to pending commands and their completion state.", "findings": [ { "id": "preliminary-and-final-replies", "name": "Preliminary and final replies", "description": "Distinguish acceptance or progress from final success and classify failures without treating reply text as a substitute for reply structure.", "questions": [ { "text": "Does the received reply report preliminary progress, completion, a need for further information or failure?", "kind": "definition", "id": "preliminary-and-final-replies-q01" }, { "text": "Which final reply is still required before the agent may report the pending operation as complete?", "kind": "action", "id": "preliminary-and-final-replies-q02" } ] } ] } ] }, { "id": "data-connection-establishment", "name": "Data connection establishment", "description": "Models the separate connections used for file data and directory listings.", "rationale": "A working FTP control session does not prove that a data connection can be established or that its destination is acceptable.", "layers": [ { "id": "active-passive-negotiation", "name": "Active and passive negotiation", "description": "Records connection initiation, addressing and supported negotiation commands.", "findings": [ { "id": "data-endpoint-selection", "name": "Data endpoint selection", "description": "Identify which peer opens the data connection and how its destination is obtained.", "questions": [ { "text": "Will the client or server initiate the data connection, and which of PORT, EPRT, PASV or EPSV establishes its parameters?", "kind": "definition", "id": "data-endpoint-selection-q01" }, { "text": "Which supported method is compatible with the observed address family and network restrictions?", "kind": "action", "id": "data-endpoint-selection-q02" } ] } ] }, { "id": "data-path-validation", "name": "Data path validation", "description": "Assesses reachability and the acceptability of the negotiated peer.", "findings": [ { "id": "reachable-and-authorised-peer", "name": "Reachable and authorised peer", "description": "Treat the negotiated data destination as something to validate, including when addressing is affected by NAT.", "questions": [ { "text": "What evidence shows that the negotiated data connection can open and carry the requested listing or transfer?", "kind": "measurement", "id": "reachable-and-authorised-peer-q01" }, { "text": "Does the proposed data peer satisfy policy, or would it cause an unauthorised third-party connection?", "kind": "boundary", "id": "reachable-and-authorised-peer-q02" } ] } ] } ] }, { "id": "file-semantics-and-recovery", "name": "File semantics and recovery", "description": "Defines how FTP operations address files, represent data and handle incomplete effects.", "rationale": "Transfer completion alone does not settle byte preservation, overwrite behaviour or whether retrying an operation is safe.", "layers": [ { "id": "paths-metadata-and-representation", "name": "Paths, metadata and representation", "description": "Records the remote namespace and transfer settings needed to interpret an operation.", "findings": [ { "id": "target-and-content-interpretation", "name": "Target and content interpretation", "description": "Establish how a pathname resolves, how metadata is interpreted and whether the selected representation preserves the required content.", "questions": [ { "text": "How do the current directory, pathname encoding and server conventions determine the target file?", "kind": "definition", "id": "target-and-content-interpretation-q01" }, { "text": "Are directory facts obtained through MLST or MLSD, an implementation-specific LIST format, or another supported mechanism?", "kind": "provenance", "id": "target-and-content-interpretation-q02" }, { "text": "Which TYPE setting matches the required text conversion or byte-preservation behaviour?", "kind": "action", "id": "target-and-content-interpretation-q03" } ] } ] }, { "id": "completion-and-restart", "name": "Completion and restart", "description": "Tracks partial files, final replies and the evidence needed for recovery.", "findings": [ { "id": "verified-outcome-and-safe-retry", "name": "Verified outcome and safe retry", "description": "Separate protocol-reported completion from content verification and assess the effects of restart, append or replacement.", "questions": [ { "text": "What final reply, size comparison or independently available integrity evidence supports the reported outcome?", "kind": "measurement", "id": "verified-outcome-and-safe-retry-q01" }, { "text": "Does the endpoint support REST for this operation and representation, and what identifies a valid restart position?", "kind": "boundary", "id": "verified-outcome-and-safe-retry-q02" }, { "text": "After interruption, should the agent resume, restart, inspect a partial target or seek a decision because retry could overwrite or duplicate data?", "kind": "action", "id": "verified-outcome-and-safe-retry-q03" } ] } ] } ] }, { "id": "authentication-protection-and-authority", "name": "Authentication, protection and authority", "description": "Establishes the session's identity, channel protections and permitted file effects.", "rationale": "FTP capability, successful authentication and permission to perform a particular operation are separate conditions.", "layers": [ { "id": "identity-and-channel-protection", "name": "Identity and channel protection", "description": "Records authentication and protection of control and data traffic independently.", "findings": [ { "id": "protected-authenticated-session", "name": "Protected authenticated session", "description": "Assess credential exposure, TLS establishment, peer validation and data-channel protection without assuming that FTPS secures every channel automatically.", "questions": [ { "text": "How is the session authenticated, and are credentials sent only under the protection required by policy?", "kind": "measurement", "id": "protected-authenticated-session-q01" }, { "text": "How is TLS established, how is the server identity validated, and what protection applies to each data connection?", "kind": "measurement", "id": "protected-authenticated-session-q02" } ] } ] }, { "id": "operation-authorisation", "name": "Operation authorisation", "description": "Connects requested protocol actions to allowed effects on remote files.", "findings": [ { "id": "permitted-file-effects", "name": "Permitted file effects", "description": "Record authority to read, create, replace, append, rename or delete the specific target, including anonymous-session restrictions.", "questions": [ { "text": "Which target-specific operations are authorised for this identity and the agent's task?", "kind": "boundary", "id": "permitted-file-effects-q01" }, { "text": "Before issuing a mutating command, what evidence establishes its overwrite, append or deletion effect and whether that effect is permitted?", "kind": "action", "id": "permitted-file-effects-q02" } ] } ] } ] }, { "id": "evidence-and-external-alignment", "name": "Evidence and external alignment", "description": "What the world already says about this thing, gathered so the model can be checked against it.", "rationale": "A model that cannot be lined up against existing standards, identifiers and practice cannot be adopted by anyone who already uses them.", "layers": [ { "id": "reported-evidence", "name": "Reported evidence", "description": "Findings from the breadth pass, kept separate from the structural claims.", "findings": [ { "id": "evidence-confidence-notes", "name": "Check these first", "description": "Recalled without web access and unsourced; every item is a lead to verify.", "evidence": [ "This describes the network protocol, not a discipline or field of knowledge.", "The listed kinds overlap: connection mode, authentication policy, and TLS protection are independent distinctions.", "Standards and identifiers are recalled without source inspection; implementation support and deployment prevalence require verification." ], "questions": [ { "id": "evidence-confidence-notes-q01", "text": "Which of these check these first hold for the sense of File Transfer Protocol this model covers, and on what evidence?", "kind": "provenance" } ] }, { "id": "evidence-kinds", "name": "Kinds and varieties", "description": "Recalled without web access and unsourced; every item is a lead to verify.", "evidence": [ "Active-mode FTP", "Passive-mode FTP", "Anonymous FTP", "Authenticated FTP", "FTP secured with TLS (FTPS)" ], "questions": [ { "id": "evidence-kinds-q01", "text": "Which of these kinds and varieties hold for the sense of File Transfer Protocol this model covers, and on what evidence?", "kind": "provenance" } ] }, { "id": "evidence-identifiers", "name": "Identifiers and schemes", "description": "Recalled without web access and unsourced; every item is a lead to verify.", "evidence": [ { "scheme": "IANA service names and port numbers", "value_or_pattern": "ftp: TCP 21; ftp-data: TCP 20", "note": "Port 21 is the conventional control port; port 20 is the conventional server-side source port for active-mode data connections, not a universal data-transfer port." }, { "scheme": "URI scheme", "value_or_pattern": "ftp", "note": "Identifies FTP resources." }, { "scheme": "FTP reply codes", "value_or_pattern": "Three decimal digits, with the first digit from 1 through 5", "note": "The first digit distinguishes preliminary, completion, intermediate, transient failure, and permanent failure replies." } ], "questions": [ { "id": "evidence-identifiers-q01", "text": "Which of these identifiers and schemes hold for the sense of File Transfer Protocol this model covers, and on what evidence?", "kind": "provenance" } ] }, { "id": "evidence-standards-and-regulation", "name": "Standards and regulation", "description": "Recalled without web access and unsourced; every item is a lead to verify.", "evidence": [ "RFC 959, File Transfer Protocol (FTP), published in the Internet RFC series and designated Internet Standard STD 9.", "IETF RFC 2428, FTP Extensions for IPv6 and NATs, specifies EPRT and EPSV.", "IETF RFC 3659, Extensions to FTP, specifies additional capabilities including machine-readable directory listings.", "IETF RFC 4217, Securing FTP with TLS, specifies TLS protection for FTP.", "IETF RFC 2577, FTP Security Considerations, documents security concerns." ], "questions": [ { "id": "evidence-standards-and-regulation-q01", "text": "Which of these standards and regulation hold for the sense of File Transfer Protocol this model covers, and on what evidence?", "kind": "provenance" } ] }, { "id": "evidence-real-world-use", "name": "Real-world use", "description": "Recalled without web access and unsourced; every item is a lead to verify.", "evidence": [ "Uploading and downloading files on managed servers.", "Distributing files through anonymous public archives.", "Moving files in scheduled enterprise data-exchange workflows.", "Transferring files to and from equipment with embedded FTP clients or servers." ], "questions": [ { "id": "evidence-real-world-use-q01", "text": "Which of these real-world use hold for the sense of File Transfer Protocol this model covers, and on what evidence?", "kind": "provenance" } ] }, { "id": "evidence-measurements", "name": "Typical measurements", "description": "Recalled without web access and unsourced; every item is a lead to verify.", "evidence": [ { "quantity": "File-transfer throughput", "typical_range": "No protocol-defined typical range; depends on network capacity, latency, storage, and implementation.", "unit": "bytes per second" } ], "questions": [ { "id": "evidence-measurements-q01", "text": "Which of these typical measurements hold for the sense of File Transfer Protocol this model covers, and on what evidence?", "kind": "provenance" } ] }, { "id": "evidence-failure-modes-and-hazards", "name": "Failure modes and hazards", "description": "Recalled without web access and unsourced; every item is a lead to verify.", "evidence": [ "Unprotected FTP exposes passwords, commands, and transferred contents to interception or modification.", "Separate data connections can fail because of firewalls, NAT configuration, or incorrectly advertised passive-mode addresses.", "Overly permissive anonymous access or server permissions can expose files or permit unauthorized uploads.", "Interrupted transfers can leave partial files; restart support and safe publication of completed files depend on implementation and workflow.", "ASCII transfer mode can alter binary files through text representation conversion." ], "questions": [ { "id": "evidence-failure-modes-and-hazards-q01", "text": "Which of these failure modes and hazards hold for the sense of File Transfer Protocol this model covers, and on what evidence?", "kind": "provenance" } ] }, { "id": "evidence-neighbours", "name": "Neighbouring kinds and how to tell them apart", "description": "Recalled without web access and unsourced; every item is a lead to verify.", "evidence": [ { "name": "FTPS", "difference": "FTPS applies TLS security to FTP while retaining its control and data connection architecture." }, { "name": "SSH File Transfer Protocol (SFTP)", "difference": "SFTP is a distinct file-access and transfer protocol normally carried over SSH; it does not use FTP commands or connection architecture." }, { "name": "Trivial File Transfer Protocol (TFTP)", "difference": "TFTP is a simpler, separate protocol using UDP and lacks FTP's authenticated control session." }, { "name": "Hypertext Transfer Protocol (HTTP)", "difference": "HTTP transfers resource representations through request-response exchanges and does not use FTP's separate control and data connections." } ], "questions": [ { "id": "evidence-neighbours-q01", "text": "Which of these neighbouring kinds and how to tell them apart hold for the sense of File Transfer Protocol this model covers, and on what evidence?", "kind": "provenance" } ] } ] } ] } ] }, "openQuestions": [ "Does the existing Vercy catalogue already contain an authoritative FTP model that this registry entry should reference?", "Which FTP specifications and extension documents should define the model's supported conformance profiles?", "Should legacy transfer modes, record structures and third-party server-to-server transfers be represented in the core model or optional layers?", "Which implementation-specific pathname, listing, timestamp and restart behaviours require explicit interoperability profiles?", "What deployment policy should govern anonymous access, unprotected sessions, TLS requirements and acceptable transfer-verification evidence?" ], "statistics": { "bundles": 6, "layers": 11, "findings": 18, "questions": 30 } }, "draft": { "generator": "vr.draft.v3", "status": "draft-generated", "researched": false, "archetype": "discipline or field of knowledge", "method": "Written from the archetype playbook - what this kind of thing needs beyond identity and provenance - and from the structure that recurred across 6,333 models already researched by two engines. Applied to this entry by rule. No source was read for this thing and no claim here is researched. This entry carries no facets of its own, so they were inferred from its domain - a guess about a whole domain applied to one thing.", "facetsInferred": true, "nextPass": "A researcher replaces this draft with a sourced specification. Treat every sentence below as a proposal to argue with.", "purpose": "Give an agent a durable, checkable way to recognise a File Transfer Protocol, record what state it is in, and decide what may be done with it.", "whatItIs": "Enable an agent to recognise File Transfer Protocol (FTP), assess an implementation or session, and determine which file operations are supported, authorised and safe.", "characteristics": { "substance": "information", "origin": "conceptual", "agency": "inert" }, "whatYouCanDoWithIt": [ "read and interpreted" ], "distinguishingFeatures": [ "Names folded into this entry, which a task may need to split apart again: WebFTP, anonymous FTP.", "2 finer distinctions are held as aliases rather than separate entries, because telling them apart needs a task that asks for it.", "Described in 82 Wikipedia languages, which is a measure of how widely the thing is known, not of how important it is." ], "openQuestionsForResearch": [ "Which of the bundles below does a real task actually need, and which are ceremony?", "What does this thing have that the facets do not capture at all?", "Which neighbouring kind is most often confused with a File Transfer Protocol, and on what evidence are they told apart?" ], "whatItIsMadeOf": "content that has to be carried by something else", "physicalCharacter": [ "Does nothing on its own; everything it does, something else did to it.", "These come from the domain this entry sits in rather than from the entry itself, so treat them as a first guess about the whole domain applied to one thing." ], "whatCanBeDoneWithIt": [ "read it and act on what it says" ], "howItIsRecognised": [], "relatedModels": [ { "relation": "covers", "note": "Finer kinds folded into this entry because telling them apart needs a task that asks for it. Each is a model waiting to be split out when one does.", "targets": [ "WebFTP", "anonymous FTP" ] } ], "standing": "Described in 82 Wikipedia languages, which measures how widely it is written about rather than how important or how common it is. 2 finer distinctions are held inside this entry as names rather than as separate models.", "structure": { "bundles": [ { "id": "identity-and-classification", "name": "Identity, naming and classification", "description": "How an agent tells one File Transfer Protocol from another, and a File Transfer Protocol from things that resemble it.", "rationale": "Recognition comes before every other claim. Without stable identity nothing else in the model can be trusted to be about the same thing twice.", "layers": [ { "id": "naming-and-identifiers", "name": "Names and identifiers", "description": "The names this thing goes by and the identifiers that survive translation and time.", "findings": [ { "id": "preferred-name-and-aliases", "name": "Preferred name, aliases and local names", "description": "Which name to use, which names mean the same thing, and which merely sound similar.", "questions": [ { "id": "preferred-name-and-aliases-q01", "text": "What identifies and describes the name of a File Transfer Protocol, and in what units or vocabulary?", "kind": "definition", "answer_data": [ "identifiers", "types and classes", "values with units", "explicit unknowns" ] }, { "id": "preferred-name-and-aliases-q02", "text": "Who or what asserted this about the name of a File Transfer Protocol, by which method, and when was it true?", "kind": "provenance", "answer_data": [ "authority", "method", "evidence", "event time", "knowledge time" ] }, { "id": "preferred-name-and-aliases-q03", "text": "What may an agent decide or do once the name of a File Transfer Protocol is known, and what must it refuse?", "kind": "action", "answer_data": [ "permitted actions", "preconditions", "refusals", "escalation" ] } ] }, { "id": "stable-identifiers", "name": "Stable identifiers and external keys", "description": "Identifiers that keep pointing at this kind of thing across systems and languages.", "questions": [ { "id": "stable-identifiers-q01", "text": "What identifies and describes an identifier for a File Transfer Protocol, and in what units or vocabulary?", "kind": "definition", "answer_data": [ "identifiers", "types and classes", "values with units", "explicit unknowns" ] }, { "id": "stable-identifiers-q02", "text": "Who or what asserted this about an identifier for a File Transfer Protocol, by which method, and when was it true?", "kind": "provenance", "answer_data": [ "authority", "method", "evidence", "event time", "knowledge time" ] }, { "id": "stable-identifiers-q03", "text": "What may an agent decide or do once an identifier for a File Transfer Protocol is known, and what must it refuse?", "kind": "action", "answer_data": [ "permitted actions", "preconditions", "refusals", "escalation" ] } ] } ] }, { "id": "classification-and-granularity", "name": "Classification and granularity", "description": "Where a File Transfer Protocol sits among kinds, and how finely a task needs to cut it.", "findings": [ { "id": "kind-and-parents", "name": "Kind, parents and neighbouring kinds", "description": "The classes this thing belongs to and the ones it is next to.", "questions": [ { "id": "kind-and-parents-q01", "text": "What identifies and describes the kind of a File Transfer Protocol, and in what units or vocabulary?", "kind": "definition", "answer_data": [ "identifiers", "types and classes", "values with units", "explicit unknowns" ] }, { "id": "kind-and-parents-q02", "text": "Who or what asserted this about the kind of a File Transfer Protocol, by which method, and when was it true?", "kind": "provenance", "answer_data": [ "authority", "method", "evidence", "event time", "knowledge time" ] }, { "id": "kind-and-parents-q03", "text": "What may an agent decide or do once the kind of a File Transfer Protocol is known, and what must it refuse?", "kind": "action", "answer_data": [ "permitted actions", "preconditions", "refusals", "escalation" ] } ] }, { "id": "distinguishing-features", "name": "Distinguishing features", "description": "What separates a File Transfer Protocol from the things most often confused with it.", "questions": [ { "id": "distinguishing-features-q01", "text": "What identifies and describes what distinguishes a File Transfer Protocol, and in what units or vocabulary?", "kind": "definition", "answer_data": [ "identifiers", "types and classes", "values with units", "explicit unknowns" ] }, { "id": "distinguishing-features-q02", "text": "Who or what asserted this about what distinguishes a File Transfer Protocol, by which method, and when was it true?", "kind": "provenance", "answer_data": [ "authority", "method", "evidence", "event time", "knowledge time" ] }, { "id": "distinguishing-features-q03", "text": "What may an agent decide or do once what distinguishes a File Transfer Protocol is known, and what must it refuse?", "kind": "action", "answer_data": [ "permitted actions", "preconditions", "refusals", "escalation" ] } ] } ] } ] }, { "id": "state-and-lifecycle", "name": "State and lifecycle", "description": "The states a File Transfer Protocol passes through and the events that move it between them.", "rationale": "Most decisions about a thing depend on what state it is in now, which is a claim with a time on it, not a property.", "layers": [ { "id": "lifecycle-stages", "name": "Lifecycle stages", "description": "From coming into existence to ceasing to be one of these.", "findings": [ { "id": "stages-and-transitions", "name": "Stages and transitions", "description": "The stages worth naming and what moves a File Transfer Protocol between them.", "questions": [ { "id": "stages-and-transitions-q01", "text": "What identifies and describes the lifecycle of a File Transfer Protocol, and in what units or vocabulary?", "kind": "definition", "answer_data": [ "identifiers", "types and classes", "values with units", "explicit unknowns" ] }, { "id": "stages-and-transitions-q02", "text": "Who or what asserted this about the lifecycle of a File Transfer Protocol, by which method, and when was it true?", "kind": "provenance", "answer_data": [ "authority", "method", "evidence", "event time", "knowledge time" ] }, { "id": "stages-and-transitions-q03", "text": "What may an agent decide or do once the lifecycle of a File Transfer Protocol is known, and what must it refuse?", "kind": "action", "answer_data": [ "permitted actions", "preconditions", "refusals", "escalation" ] } ] } ] }, { "id": "observations-and-status", "name": "Observations and current status", "description": "What is observed about a File Transfer Protocol, how often and by whom.", "findings": [ { "id": "observation-record", "name": "Observation record", "description": "How an observation of a File Transfer Protocol is recorded so that it can be superseded rather than overwritten.", "questions": [ { "id": "observation-record-q01", "text": "What identifies and describes an observation of a File Transfer Protocol, and in what units or vocabulary?", "kind": "definition", "answer_data": [ "identifiers", "types and classes", "values with units", "explicit unknowns" ] }, { "id": "observation-record-q02", "text": "Who or what asserted this about an observation of a File Transfer Protocol, by which method, and when was it true?", "kind": "provenance", "answer_data": [ "authority", "method", "evidence", "event time", "knowledge time" ] }, { "id": "observation-record-q03", "text": "What may an agent decide or do once an observation of a File Transfer Protocol is known, and what must it refuse?", "kind": "action", "answer_data": [ "permitted actions", "preconditions", "refusals", "escalation" ] } ] } ] } ] }, { "id": "content-and-access", "name": "Content, encoding and access", "description": "What a File Transfer Protocol says, how it is encoded and who may read it.", "rationale": "An informational thing carries content that can be copied, versioned and withheld, none of which its physical carrier explains.", "layers": [ { "id": "content-and-encoding", "name": "Content and encoding", "description": "The content itself, its format and its language.", "findings": [ { "id": "content-and-format", "name": "Content, format and language", "description": "What a File Transfer Protocol contains and in what form it is held.", "questions": [ { "id": "content-and-format-q01", "text": "What identifies and describes the content of a File Transfer Protocol, and in what units or vocabulary?", "kind": "definition", "answer_data": [ "identifiers", "types and classes", "values with units", "explicit unknowns" ] }, { "id": "content-and-format-q02", "text": "Who or what asserted this about the content of a File Transfer Protocol, by which method, and when was it true?", "kind": "provenance", "answer_data": [ "authority", "method", "evidence", "event time", "knowledge time" ] }, { "id": "content-and-format-q03", "text": "What may an agent decide or do once the content of a File Transfer Protocol is known, and what must it refuse?", "kind": "action", "answer_data": [ "permitted actions", "preconditions", "refusals", "escalation" ] } ] } ] }, { "id": "access-and-rights", "name": "Access, rights and retention", "description": "Who may read, copy or change it, and for how long it is kept.", "findings": [ { "id": "access-rules", "name": "Access rules and retention", "description": "The permissions attached to a File Transfer Protocol and the period it survives.", "questions": [ { "id": "access-rules-q01", "text": "What identifies and describes access to a File Transfer Protocol, and in what units or vocabulary?", "kind": "definition", "answer_data": [ "identifiers", "types and classes", "values with units", "explicit unknowns" ] }, { "id": "access-rules-q02", "text": "Who or what asserted this about access to a File Transfer Protocol, by which method, and when was it true?", "kind": "provenance", "answer_data": [ "authority", "method", "evidence", "event time", "knowledge time" ] }, { "id": "access-rules-q03", "text": "What may an agent decide or do once access to a File Transfer Protocol is known, and what must it refuse?", "kind": "action", "answer_data": [ "permitted actions", "preconditions", "refusals", "escalation" ] } ] } ] } ] }, { "id": "subject-and-method", "name": "Subject matter and method", "description": "What File Transfer Protocol studies and how it establishes anything.", "rationale": "A field is identified by its questions and its methods, and those are what distinguish it from the fields next to it.", "layers": [ { "id": "subject", "name": "Subject matter", "description": "The questions it takes as its own.", "findings": [ { "id": "subject-record", "name": "Questions and objects of study", "description": "What it is about, stated so a neighbouring field can be told apart.", "questions": [ { "id": "subject-record-q01", "text": "What questions and objects does File Transfer Protocol take as its own?", "kind": "definition" }, { "id": "subject-record-q02", "text": "Which questions does it share with a neighbouring field, and who claims them?", "kind": "boundary" } ] } ] }, { "id": "method", "name": "Method and evidence", "description": "How claims are established and what counts as evidence.", "findings": [ { "id": "method-record", "name": "Methods and standards of evidence", "description": "The methods used and what they are taken to establish.", "questions": [ { "id": "method-record-q01", "text": "By what methods does File Transfer Protocol establish claims, and what counts as sufficient evidence?", "kind": "provenance" }, { "id": "method-record-q02", "text": "What kind of claim can this field not settle, and where should an agent look instead?", "kind": "action" } ] } ] } ] }, { "id": "institutions-and-classification", "name": "Institutions and classification", "description": "Where File Transfer Protocol is practised and how catalogues place it.", "rationale": "The institutional footprint is the evidence that a field exists as a field rather than as a topic.", "layers": [ { "id": "institutions", "name": "Institutional markers", "description": "Societies, journals, degrees and departments.", "findings": [ { "id": "institution-record", "name": "Bodies and venues", "description": "Where the field organises itself.", "questions": [ { "id": "institution-record-q01", "text": "Which societies, journals or degrees mark File Transfer Protocol as an established field?", "kind": "provenance" }, { "id": "institution-record-q02", "text": "What would show that it is emerging or dissolving rather than established?", "kind": "boundary" } ] } ] }, { "id": "classification", "name": "Classification schemes", "description": "Where library and research classifications put it.", "findings": [ { "id": "classification-record", "name": "Codes and their disagreements", "description": "The classification codes that place it, and where they differ.", "questions": [ { "id": "classification-record-q01", "text": "Which classification schemes place File Transfer Protocol, under what codes?", "kind": "definition" }, { "id": "classification-record-q02", "text": "Where do those schemes disagree about its scope?", "kind": "boundary" } ] } ] } ] }, { "id": "provenance-and-evidence", "name": "Provenance, evidence and time", "description": "Where every claim about a File Transfer Protocol came from and when it held.", "rationale": "A claim without a source and a time cannot be superseded, only overwritten, and an agent that overwrites loses the ability to explain itself.", "layers": [ { "id": "source-and-authority", "name": "Source and authority", "description": "Who said it, on what evidence, and how strongly.", "findings": [ { "id": "claim-provenance", "name": "Claim provenance and confidence", "description": "The authority behind each claim about a File Transfer Protocol and how confident it is.", "questions": [ { "id": "claim-provenance-q01", "text": "What identifies and describes a claim about a File Transfer Protocol, and in what units or vocabulary?", "kind": "definition", "answer_data": [ "identifiers", "types and classes", "values with units", "explicit unknowns" ] }, { "id": "claim-provenance-q02", "text": "Who or what asserted this about a claim about a File Transfer Protocol, by which method, and when was it true?", "kind": "provenance", "answer_data": [ "authority", "method", "evidence", "event time", "knowledge time" ] }, { "id": "claim-provenance-q03", "text": "What may an agent decide or do once a claim about a File Transfer Protocol is known, and what must it refuse?", "kind": "action", "answer_data": [ "permitted actions", "preconditions", "refusals", "escalation" ] } ] } ] }, { "id": "time-and-versions", "name": "Time, versions and supersession", "description": "When a claim was true, when it was learnt, and what replaced it.", "findings": [ { "id": "validity-and-supersession", "name": "Validity period and supersession", "description": "How an old claim about a File Transfer Protocol is retired without being erased.", "questions": [ { "id": "validity-and-supersession-q01", "text": "What identifies and describes the validity of a claim about a File Transfer Protocol, and in what units or vocabulary?", "kind": "definition", "answer_data": [ "identifiers", "types and classes", "values with units", "explicit unknowns" ] }, { "id": "validity-and-supersession-q02", "text": "Who or what asserted this about the validity of a claim about a File Transfer Protocol, by which method, and when was it true?", "kind": "provenance", "answer_data": [ "authority", "method", "evidence", "event time", "knowledge time" ] }, { "id": "validity-and-supersession-q03", "text": "What may an agent decide or do once the validity of a claim about a File Transfer Protocol is known, and what must it refuse?", "kind": "action", "answer_data": [ "permitted actions", "preconditions", "refusals", "escalation" ] } ] } ] } ] } ] }, "statistics": { "bundles": 6, "layers": 12, "findings": 14, "questions": 38 } } } }