ZedAI Terminology

From zedwiki

This page collects commonly used terms in the Z39.86 Authoring and Interchange Framework (ZedAI, for short) context.

Contents 1 Final term set 201004 1.1 Terms changed 1.1.1 Core Module Pool → Core Modules 1.1.2 CURIE/RDF Property → Term 1.1.3 document instance → Z39.86-AI document 1.2 Terms pending decision 1.2.1 Z39.86-AI Framework 1.2.1.1 Decision 1.2.2 Abstract Document Model and Markup Model 1.2.2.1 Suggestion 1 (markus) 1.2.2.2 Decision 1.2.3 Abstract Definitions 1.2.3.1 Suggestion 1 (markus) 1.2.3.2 Decision 1.2.4 Trait 1.2.4.1 Suggestion 1 (James) 1.2.4.2 Decision 1.2.5 Initial vs Default in AbsDef traits 1.2.5.1 Suggestion 1 (markus) 1.2.5.2 Suggestion 2 (James/Boris) 1.2.5.3 Decision 1.2.6 Member and Default member 1.2.6.1 Decision 1.2.7 Specialization and Variant 1.2.7.1 Decision 1.2.8 Alterability and Optionality 1.2.8.1 Decision 1.2.9 Module activation 1.2.9.1 Decision 1.2.10 Attribute set vs Attribute collection 1.2.10.1 Decision 1.2.11 Z39.86 file sets 1.2.12 Information resource/publication 1.2.12.1 Decision 1.2.13 Public Components 1.2.13.1 Decision 1.3 Terms kept unchanged 1.3.1 →Class 1.3.2 →Feature 1.3.3 →Profile 1.3.4 →Z39.86-AI document 1.3.5 →Module 1.3.6 →Processing Agent 1.3.7 →Resource directory 1.3.8 →Layer 1.3.9 →Document Foundation 1.3.10 →Implicit value 1.3.11 →Module Component 2 Source definitions/usage 2.1 Terms defined in the specification 2.1.1 Abstract Definition 2.1.2 Class 2.1.3 Customization 2.1.4 Feature 2.1.5 Implicit value 2.1.6 Markup model 2.1.7 Module 2.1.8 Module Activation 2.1.9 Module Component 2.1.10 Processing Agent 2.1.11 Profile 2.1.12 RDF vocabulary 2.1.13 Resource directory 2.1.14 Specialization 2.1.15 Trait 2.1.16 Variant 2.1.17 Z39.86-AI document 2.2 Other terms 2.2.1 Core Module Pool * 2.2.2 Abstract Document Model * 2.2.2.1 document foundation * 2.2.2.2 layer * 2.2.2.3 attribute set 2.2.2.4 member 2.2.2.5 default member 2.2.3 public component * 2.2.4 nature (pointer to traits?) 2.2.5 activation * 2.2.6 driver file 2.2.7 information resource/publication/document 2.2.8 Profile Markup Model 2.2.9 Base Markup Model 2.2.10 Semantic inflection 2.2.11 Vocabulary Term 2.2.12 Z39.86-AI Framework

Final term set 201004

Changes done prior to May public release. Compare with Source definitions/usage section below, which lists usage before the changes described in this section. The terms should be defined in a spec glossary unless otherwise specified.

Note that we also may want to consider

• moving the ADM/CMP specific terms to a dedicated glossary that lives nearer to those sections
• that each time a particular term occurs in a major section, we could xref it to its glossary

Terms changed

Core Module Pool → Core Modules

was 

Core Module Pool

changed to 

Core Modules

rationale 

demystification

notes 

when referencing, use the expanded term, not a CM abbreviation. Document name is "Z39.86-AI Core Modules"

in glossary? 

no

makes the change 

Matt

CURIE/RDF Property → Term

was 

CURIE and RDF Property

changed to 

(RDF vocabulary) term

rationale 

aligns with RDFa 1.1 (which we intend to adopt during summer autumn review period)

notes 

in some places, the use of the CURIE term is still justified. Glossary would need to make clear that we use "term" as a shorthand for a TERMorURIorCURIE compliant value (this datatype not in RDFa10)

makes the change 

Markus (dblcheck RDFa 1.1 draft first)

document instance → Z39.86-AI document

was 

document instance

changed to 

Z39.86-AI document or, if needed, Z39.86-AI document instance

rationale 

think "document instance" is used as vague synonym in some places. Better use the same term all the time for clarity

Boris: I think there's some inconsistency whether "Document" refers to just the XML file ("a document...must be a well-formed XML Document...") or the whole package ("A Z39.86-AI document may comprise more than just the XML file...."). We probably need two terms to cover both.

makes the change 

Matt

Terms pending decision

Z39.86-AI Framework

Are we using this consistently as a synonym for "this specification"? If so, this one should be fine.

Decision

Keep unchanged

Abstract Document Model and Markup Model

We should be dealing with these in tandem as they need to be named in a way that makes their relation clear.

Suggestion 1 (markus)

Here's a suggestion where the suggested terms to use are marked in bold:

One thing the spec does is to define an Abstract Document Model which is a blueprint model for zedai documents (the layers and attribute sets).

Profiles define concrete Document Model's which in order to be compliant must adhere to all rules in the Abstract Document Model.

A Profile's Document Model consists of normative schemas and any normative prose expressed through the Profile's resource directory.

Features define concrete Document Model Fragment's that are designed to be "injected" into the Document Models of Profiles.

The Document Model Fragment defined by a Feature consists of normative schema fragments and any normative prose expressed through the Profile's resource directory.

Note the use of "fragment" in the feature context, this would be simply to make very clear the distinction between profiles and features in terms of what they actually define.

Note also that this proposal uses "Document Model" instead of "Markup Model". To me as a non-native-speaker, this is much more clear.

Boris: I think the above is pretty clear. The only possible confusion would be with Document Object Model (DOM) as used in other specifications. I like the abstract document model / concrete document model contrast / parallelism.

Decision

Use "Markup Model" for the concrete schema. Rewrite the definition taken XHTMLMOD. Do not include normative prose in this term, so we need to talk about both separately where needed.

Abstract Document Model remains named so.

Markup Model Fragment used for features.

Abstract Definitions

Currently these occur in the CMP document, and in feature resource directories (since the latter contributes stuff that isnt part of the core modules). The term is taken from XHTMLMOD.

James:

I don't care for this term. To me, it's just the "module description", or "module documentation", or even "module definition". I don't see anything particularly "abstract" about it.

James (29 Apr 2010): If we are taking the term from XHTMLMOD, why are we not just adopting that whole section of their spec regarding syntactic representation?

Suggestion 1 (markus)

Markus: We could use the terms "Module Definition" and "Component Definition" instead. Its preferable to have two different terms as these have different fields inside them. The fact that these definitions in some cases (content model for example) are likely to change at activation/concretization time can be conveyed by other means than by calling the definition "abstract"; for example by using "Initial Content Model" and so on; where the term "initial" would convey the embryonic nature of the expression.

Boris: I was confused by "Abstract Definition" too. "Module/Component Definition" is better. "Description" or "Documentation" clearly signal the prose nature of these, but perhaps incorrectly suggest that they are loose and unstructured. I don't think you need to qualify with "abstract" or "initial" except in contexts where you're explicitly talking about how profiles can customize the modules they use.

Markus: yes, I think "definition" needs to be here; these things do express constraints that if not followed yields non-compliance.

Decision

Use "Module Definition" and "Component Definition" and make sure that there is prose that makes very clear that these defs represent an initial state.

Trait

James:

There is a list of six traits given here -- can there be others? If so, how are they defined? If not, we can simplify the specification language by addressing these six directly. If these are the only six, then I'd drop the term "trait", which is so generic as to be meaningless, and instead say that a component must have a semantic definition, a default usage context, a default content model, a default attribute model, and indications of whether it is variable and/or mandatory. Then you can address each of those things.

Boris:

I was worried about this list too. If a Component includes things like a datatype, pattern, or set of values, then a requirement that every Component have a content model as a trait is seemingly unmeetable - datatypes and such don't have content models, do they? Could we just say something more along the lines of "The Component Definition contains the following information..."

Boris: I am rather confused by traits. They have a seemingly loose definition: "a piece of information about a component that defines something about its overall nature". It sounds like a trait is actually a piece of a Component Definition (or Abstract Definition)? But elsewhere in the spec it talks about "information about traits", "aggregation of traits", etc which doesn't fit if the trait is a piece of documentation.

Suggestion 1 (James)

Drop the term trait and refer to the former traits directly instead.

Markus: there will need to be some prose solution for when needing to refer to these former traits "in passing" or collectively; but I guess that can be solved. As Boris suggests above, simply using "Component Definition" could work.

Markus: in this context, also find any occurence of "nature" and replace by "Component definition"

James: suggesting to restructure this section to be more clear. Merge first two pieces of components section. Then "Here's the traits that every component must define, and then separate subsections for each one of those things.

Decision

James take a shot at rewrite as per above tomorrow.

Initial vs Default in AbsDef traits

James:

Can we say "default" instead of "initial"? I think that's clearer.

Markus: Well, those two terms have different meaning to me, where initial is closer to what we want to say (but there may be a better term even so of course). The key point here is that a trait (content model, attribute model, usage context) as described in the abstract definitions may be (and is unless explicitly forbidden) open to modification via addition and/or subtraction. "Initial" refers to the state before this has happened. "Default" to me says something else than this.

Suggestion 1 (markus)

Keep "initial" as per the reasoning above.

Boris: To me, "initial" implies a time sequence. "Default" suggests that something can be modified, but if not modified there is a fallback value. So I would have voted for "default" in this case since the modules define a set of traits that can be used as is, or modified, but are not changing over time.

Markus: ok, if this is the consensus of the native speakers around the table, then "default" it is

Suggestion 2 (James/Boris)

Change "initial" to "default".

Decision

Go for suggestion 2: use default.

Member and Default member

These terms should be used exclusively to refer to an element or an attribute that is contributed to a class. Is this confusing? Should we try to avoid using a special term at all if possible?

Decision

Keep member and default member but try to say "member of a class" or similar where possible.

In glossary? No, hopefully not.

@Matt: find all occurrences of fundamental member and replace.

Specialization and Variant

These too should be dealt with in tandem as they are easily confused. Do we want to change anything here?

variant

used to separate elements with same QNames that are used in different layers. This is concretely needed (for example the end user schema doc needs to be able to express this separation, and already uses "variant" to do so). The term originally came from documentation on object written by Boris! Dont blame the swedes all the friggin time!

specialization

was: "element or attribute with a new QName but that inherits traits from an ancestor" but when dropping "trait" we cant define it like that anymore. This is used a) when saying that a layers' default member can only be replaced by an element that inherits fundamental behaviors of the original default and b) as processing directives for implementors: "this thing fundamentally behaves as a foo".

Decision

Keep.

Boris: re specialization: remember to express which traits are inherited.

Alterability and Optionality

These are discussed here and here.

Any grand ideas on finding anything smoother?

Decision

Keep.

Module activation

This could perhaps be replaced by the literal expansion: "when including a module in a profile or feature schema", if we want to reduce the number of gloss terms. Note that it is used throughout the CMP definition tables (and there, it is good with a short term to use)

Decision

Keep.

James reminds us that the section on module activation doesn't match the gloss def.

Attribute set vs Attribute collection

Matt: Perhaps we should consider changing again to "attribute collections" to be more in line with XHTMLMOD?

Markus: I think "collection" is in general more clear to non-native speakers than "set". Set is more correct (highlights the unordered nature of attributes) but there's no reason to point that out here, as XML already defines it so.

Decision

Go for collection.

Z39.86 file sets

This is used in passing in the introduction to the container section of the spec as a way of referring to the XML document(s) and all the other referenced stuff that goes into the container. Elsewhere in the spec (e.g., the introduction to the Documents section) the term Z39.86-AI document is defined to include the other, non-XML stuff.

James: I think using ZAI document to refer to a bunch of files is incorrect; we need a term to cover the entire content of the ZAI container. "Z39.86-AI file set" isn't a bad place to start. What does OCF use? "Publication"?

James: also, if we define this container, do we need to define a manifest? Markus: there's manifest.xml, Matt: not included atm

James: we need the term fileset defined and we need prose that defines which local members of the fileset must be included in the container. "The container must include the ZAI document and all local resources referenced from the document". And then define "local" as every resource with the URI file scheme (and clarify that this means that http etc resources should not be included.) TODO check that there's no other scheme we must account for.

Markus: the section would prolly benefit from stating (informatively) that we do not define a separate manifest: the zedai document is its own manifest.

Boris: make sure that zedai document def makes clear that its one infoset possibly split over multiple files.

Matt: added def for document instance to cover local and external and rewrote container sections to refer to the local instance part. review needed.

Information resource/publication

Decision

Use Information resource. If needed, add a gloss entry that defines that these are the resources being represented as ZedAI documents.

Public Components

Boris: Externally visible?

Decision

Keep. But work on definition; perhaps just an example.

Terms kept unchanged

→Class

→Feature

→Profile

→Z39.86-AI document

→Module

→Processing Agent

→Resource directory

→Layer

→Document Foundation

→Implicit value

→Module Component

Source definitions/usage

Compare http://www.w3.org/TR/xhtml-modularization/terms.html

Terms defined in the specification

Abstract Definition

A human readable set of statements describing the initial state and nature of a module and/or its component using a mixture of prose, [RNC] syntax and other means. Abstract definitions must not be relied on to provide information about the practical implementation of that module or component as employed in any Z39.86-AI profile. Abstract definitions are intended solely for profile creators.

Class

A class represents an abstract means of referring to a set of element and/or attribute declarations associated with a layer or set in the Abstract Document Model. Classes correspond to name classes in [RelaxNG] and named groups in [XMLSchema]. Classes are dynamically populated depending on which modules and components are activated in a profile. Classes do not constitute content model templates, but are collections of declarations that can be used to create concrete content models.

Customization

An element or attribute whose usage context, content model and/or attribute model have been altered from their initial state during activation.

Feature

A partial markup model designed to represent a limited, highly-specialized set of content structures. Mathematical equations, chemistry formulas, and musical notations are examples of the kinds of content structures that might be addressed by a Z39.86-AI feature. Features share the same general structure as profiles, but are more specialized and of narrower scope and are intended to be used as discrete components within profiles.

Implicit value

The value a Processing Agent must assume for an attribute when the attribute is not present. Implicit value declarations may apply to all elements that can contain the attribute or only to elements in particular contexts. Each component's abstract definition defines the implicit values a Processing Agent must apply.

Markup model

The markup vocabulary (i.e., the gamut of element and attribute names, notations, etc.) and grammar (i.e., the prescribed use of that vocabulary) as defined by a schema. The markup model is the concrete representation in markup syntax of an abstract document model, and may be defined with varying levels of strict conformity.

Markus: I still dont understand the definition. Is the idea to refer to "the intended nature/structure of document instances, as defined partly by schemas and partly by associated non-schema prose"? If so, is the term Document Model better? Further, the "may be defined with varying levels of strict conformity" part of the def makes no sense at all in our context AFAICS

Matt: Is the strictness legacy xhtml strict/transitional/frameset parlance? I think all it's trying to define is a handy term for referencing all of what a schema defines: sum of the elements and the way that their content models work to allow you to model data. A document (object) model would be what you get after parsing your file, no?

James: As I read it, a markup model is what a schema defines. "Markup model" provides a term for this without mentioning any particular schema per se. That is, the same markup model can be represented by multiple schemas in different schema languages. It is a useful term when describing what it is that profiles define. However, if you are happy with just saying that profiles define schemas, that could work as well, I suppose.

Markus: Aha, thanks James for clarification. But shouldn't it really mean: markup model == what the schema defines + any RD normative prose? The schemas dont express all restrictions on documents. If we can just fix the definition to be less XHTML-inherited, and more along the lines of what James describes above, it would work for me.

Markus; either way, shouldn't we go for Abstract Markup Model and (Concrete) Markup Model OR Abstract Document Model and (Concrete) Document Model? Would help creating the connection between these two I think.

Module

An abstract unit within a markup model expressed as a schema fragment, used to consolidate markup declarations to increase the flexibility, modifiability, reuse and understanding of specific logical or semantic structures.

Module Activation

The act of including a module in a profile, thereby including all or some of its components in the markup model. Activation can include making alterations to the traits of the module components, as well as excluding components entirely.

Boris: consider simplifying this to "module inclusion" ?

Module Component

An individual element, attribute, datatype, value or pattern defined in a module.

Markus: this term is only defined as a shortform, instead of having to say "element, attribute, datatype, value or pattern defined in a module" every time. As such, it could be dropped, using the long literal expansion instead.

James: If the term isn't used that often, then the expansion could be OK, and that's one less term to have to keep track of. Alternatively, you could shorten the expansion to just "structure defined in a module" or "component defined in a module" or something like that.

Processing Agent

An application that processes a Z39.86-AI document for some reason. Examples include, but are not limited to, authoring tools (XML editors, XML-enabled word processors), transformation pipelines, business transfer chains, end-user provisioning interfaces, and conformance validators. Note that this definition does not include XML Processor as defined in [XML].

Profile

An integrated markup model (element set and grammar) and associated RDF vocabulary designed to represent information resources of a particular type.

Markus: in the def, "and associated RDF vocabulary" needs to go away.

RDF vocabulary

An ontology that provides a mechanism to annotate elements or element content with machine-extractable semantic information about their nature or purpose. RDF vocabularies are expressed in RDF. REMARK How RDF vocabularies are expressed may change as a result of Issue 107 .

Markus: suggest replacing "ontology..." with "collections of terms used to annotate" (see Vocabulary Terms below). Also, "RDF vocabularies are expressed in RDF. " is wrong, and can simply be taken out from the def.

Resource directory

A package of information regarding a profile or feature, including normative schemas, informative schemas, RDF vocabularies, documentation, stylesheets, or other associated resources. Resource directories are expressed in XHTML+RDFa (per [RDFa]).

Specialization

An element or attribute that inherits some or all of it traits from another element, but that serves a more specific semantic purpose. Elements contributed to a layer in the Abstract Document Model typically inherit a set of basic traits from that layer's fundamental member, and are thus specializations of the fundamental member. Specializations may, however, be derived from any member of a layer, in which case the fundamental member's traits are only indirectly inherited. Unlike variants, specializations do not share the same QName with the element they inherit traits from.

Trait

A single aspect of the overall nature of a component, such as the semantic definition or the initial content model. Refer to Section 4.3.2, “Traits” for more information.

Variant

An element that derives its semantic definition from another element but that is intended for use in a different layer of the Abstract Document Model than the element it is derived from. A variant shares the same QName as the element it is derived from.

Z39.86-AI document

An XML document that conforms to a Z39.86-AI profile.

Other terms

Core Module Pool *

Markus: are we happy with this? One of the few places where "core" might make sense, but is pool the best suffix?

Matt: I wouldn't change Core to Base here, as base makes them sound pretty lowly (core sounding a little more authoritative). No one else on the web uses CMP, so it does have uniqueness on its side (and there aren't many examples of modular schemas that are intended for this kind of general use to standardize terminology with). Nothing I can think of has quite the same ring to it as CMP, but maybe could be generalized to the Z39.86-AI Module Pool?

Matt: XHTMLMOD uses "core modules" for the ones that must be present (our document, global-classes, etc.). Maybe we should have the Z39.86-AI Core Modules and the Z39.86-AI Module Pool (/collection/set) to be completely unambiguous?

James: You could call them "common modules", I suppose. Alternatives to "pool" are "set", "collection" ... or just <null> (i.e., just call them "core modules" or "common modules" and leave it at that)

Markus: I think I like the term "common" as a replacement for "core" as it emphasizes the idea that these are here in order to assure that profiles share as much of their gene pool as possible.

Abstract Document Model *

Matt: All the following are the unique terms to the ADM. If we define separately from where they're introduced, I'd opt not to use a localized glossary. The terms are used elsewhere in the spec and in the CMP (which probably should reference back to the main spec).

document foundation *

layer *

attribute set

Matt: Perhaps we should consider changing again to "attribute collections" to be more in line with XHTMLMOD?

member

default member

public component *

Markus: this one needs tweaks, it uses the meaning of component as defined above. Still, its a tricky one, in particular because what we're trying to describe is tricky. It is about the "attachable" elements of a feature... perhaps we should be silent on this whole topic in the spec, thus obviating the need for the term. We could also rephrase this req to be a recommendation for feature integration, and just describe the intent in prose without the term.

nature (pointer to traits?)

Markus: yes, I have used nature as a synonym to "all traits of a component". We could drop the use of "nature" and just refer to traits instead.

activation *

Markus: I guess this one could be skipped too, just saying "when including a module in a profile" instead

driver file

information resource/publication/document

Matt: All for variety (and information resource is a good generic term where document is too precise). Should we talk about publications, though? It only appears in a few places in metadata, but metadata isn't exclusive to publications.

Profile Markup Model

Base Markup Model

Semantic inflection

Markus: I like this one a lot, should definitely stay.

Vocabulary Term

Markus: RDFa 1.1 intends to use the term "term" consistently to refer to a vocab RDF property. We should do this as well. Its a replacement for "RDF property" as we use it today, and sometimes it can also be used in place of "CURIE". In both cases, "term" seems the friendliest alternative.

Z39.86-AI Framework

Matt: Adding this because we go upper and lower case variously throughout on "framework". Should it be used as a proper name everywhere (like ADM, CMP, etc.), or is there a small "f" framework for general descriptions of how all the pieces interoperate? Or is it small "f" when talking practically and cap "F" when talking formally about the specification document?