Mon Vocabulary

Draft Specification


Abstract

This specification describes the Mon Vocabulary. The Mon Vocabulary is an extension of the Activity Vocabulary vocabulary inteded for use in the context of the ActivityStreams 2.0 format and provides a foundational vocabulary for representing relationships between trainers, routes, and mon.


1. Introduction

A mon is an imaginary creature or object which may be collected, traded, and interacted with. Mon frequently have individual properties, known as stats, and are capable of particular actions, known as techniques. The collectors, or owners, of mon are known as trainers. This specification defines a common vocabulary for describing mon and trainers, intended for use in the context of ActivityStreams 2.0 documents.

1.1 Relationship to Other Specifications

This document is part of the MonStrPub set of specifications. Any process claiming to implement MonStrPub must conform to this specification.

This document builds upon the Activity Vocabulary and is intended for use in an ActivityStreams 2.0 context.

1.2 Notational Conventions

Activity Vocabulary types are indicated with the prefix as:, which represents the https://www.w3.org/ns/activitystreams# base URI. Note that in ActivityStreams 2.0 documents, this prefix MAY be omitted.

Roleplaying Vocabulary types are indicated with the prefix rp:, which represents the https://www.monstr.pub/ns/roleplaying# base URI. Note that in ActivityStreams 2.0 documents, this prefix MUST be declared in the @context of the document to be valid, and a different prefix MAY be used instead.

Mon Vocabulary types are indicated with the prefix [mon:], which represents the https://www.monstr.pub/ns/monstrpub# base URI. Note that in ActivityStreams 2.0 documents, this prefix MUST be declared in the @context of the document to be valid, and a different prefix MAY be used instead.

Note: As this is still a draft specification, the above URIs may change at some point in the future.

2. Conformance

All sections explicitly marked as non-normative, as well as any diagrams, examples, or notes in this specification, are non-normative. Everything else in this specification is normative.

The Mon Vocabulary is an extension of the Roleplaying Vocabulary, which is in turn an extension of the Activity Vocabulary. Implementations of the Mon Vocabulary MUST conform to the requirements set forward in these specifications.

This specification defines three conformance classes:

Except where explicitly stated, conformance requirements are for documents, not processors.

The key words MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL are to be interpreted as described in RFC2119.

3. Mon Activity Types

As with the Activity Vocabulary, all Mon Activity Types inherit the properties of the base as:Activity type. Many of these are subtypes of a more specific Activity Type; for example, as:Offer.

3.1 The mon:Capture Activity

URI
https://www.monstr.pub/ns/monstrpub#Capture
Extends
Properties
Inherits all properties from as:Offer

A specialization of as:Offer in which the as:actor is attempting to claim ownership of the as:object. The as:instrument property MAY be used to indicate mechanisms of capture.

3.2 The mon:Search Activity

URI
https://www.monstr.pub/ns/monstrpub#Search
Extends
Properties
Inherits all properties from as:Offer

A specialization of as:Offer in which the as:actor is searching the as:object. The as:instrument property MAY be used to indicate objects used when searching. The as:target property MAY be used to indicate a desired object.

4. Mon Actor Types

In the Activity Vocabulary, Actors are Objects which are capable of performing an Activity. Processors MUST recognize objects of the following types as Actors:

Processors MAY automatically assign the type mon:Trainer to as:Person objects which are not mon:Mon.

The Mon Actor Types defined in this section are mutually exclusive; objects MUST NOT have more than one of these types. Actors MAY, however, have other types not defined by this specification. Processors SHOULD ignore any unknown types assigned to objects who have types defined in this section.

Processors MUST ignore any objects with more than one Mon Actor Type assigned.

4.1 The mon:Mon Actor

URI
https://www.monstr.pub/ns/monstrpub#Mon
Extends
Disjoint With
Properties
Inherits all properties from rp:Effectual, rp:Perishable, rp:Performer, rp:Qualified, rp:Quantified, and rp:Ranked

Describes a mon. mon:Mon actors MUST also be assigned the as:Person type.

The rp:class property MAY be used to specify the species of a mon:Mon, which MUST be a mon:Species. mon:Mon MUST NOT have more than one rp:class. Processors MUST ignore all values of rp:class if there are more than one, or if they do not point to a mon:Species object.

To ensure that the mon:Species is always able to be dereferenced, rp:class links SHOULD point to files on the same server as the associated mon:Mon. Processors MAY refuse to fetch rp:class links which do not share an origin with a given mon:Mon.

When processing a mon:Mon with an associated mon:Species, processors SHOULD use values from the associated mon:Species if the following properties are not specified on the mon:Mon:

If one or more rp:Affinity objects are provided via the rp:quality property on an associated mon:Species, but no rp:Affinity is provided via the same property on a given mon:Mon, processors SHOULD treat the mon:Mon as though those objects had been provided on its rp:quality property as well.

A mon:Mon has an owner if there is an mon:Trainer object provided, or linked to, via the as:attributedTo property. Each mon:Mon MUST NOT have more than one owner. Upon encountering a mon:Mon with multiple owners, processors MUST ignore all but one.

mon:Mon who are owned by a mon:Trainer SHOULD exist on the same server as that mon:Trainer. The owner of a mon:Mon MUST NOT change over time.

Information regarding the capture of a mon:Mon MAY be provided via the as:generator property, including:

These may be provided directly or as links.

The as:generator property of a mon:Mon MUST NOT have, or link to, more than one of each of mon:Regions, mon:Routes, or mon:Trainers. Upon encountering a mon:Mon with multiple such objects present or linked to as as:generator values, processors MUST ignore all but one. The values of the as:generator property MUST NOT change over time.

The mon:Region of a mon:Mon MAY be provided, or linked to, using the as:attributedTo property. Each mon:Mon MUST NOT have more than one associated mon:Region. Upon encountering a mon:Mon with multiple associated mon:Regions, processors MUST ignore all of them, and treat the mon:Mon as though no mon:Region was specified.

mon:ItemSlots MAY be attached to a mon:Mon (held) via the as:attachment property.

4.2 The mon:Route Actor

URI
https://www.monstr.pub/ns/monstrpub#Route
Extends
Disjoint With
Properties
Inherits all properties from as:Object

Describes a location or other construct, real or imagined, from which mon may be found. mon:Routes which correspond to real-world locations MUST also be assigned the as:Place type.

An as:name SHOULD be provided for all mon:Routes, naming the route. A tagline for the mon:Route MAY be provided via the as:summary property. A longer description of the mon:Route MAY be provided via the as:content property.

The mon:Region of a mon:Route MAY be provided, or linked to, using the as:attributedTo property. Each mon:Route MUST NOT have more than one associated mon:Region. Upon encountering a mon:Route with multiple associated mon:Regions, processors MUST ignore all of them, and treat the mon:Route as though no mon:Region was specified.

Recognizing mon:Routes as Actors is OPTIONAL for processors.

4.3 The mon:Trainer Actor

URI
https://www.monstr.pub/ns/monstrpub#Trainer
Extends
Disjoint With
Properties
Inherits all properties from as:Object

Describes a potential owner, or trainer, of mon. mon:Trainer actors MUST also be assigned the as:Person type. Only mon:Trainers are able to own mon.

The mon:Region of a mon:Trainer MAY be provided, or linked to, using the as:attributedTo property. Each mon:Trainer MUST NOT have more than one associated mon:Region. Upon encountering a mon:Trainer with multiple associated mon:Regions, processors MUST ignore all of them, and treat the mon:Trainer as though no mon:Region was specified.

mon:ItemSlots MAY be attached to a mon:Trainer (held) via the as:attachment property.

5. Mon Object Types

In addition to the Mon Activity Types and the Mon Actor Types, the Mon Vocabulary includes the following Mon Object Types:

5.1 The mon:Item Object

URI
https://www.monstr.pub/ns/monstrpub#Item
Extends
Properties
Inherits all properties from rp:Action and rp:Class

Describes a class of item of some sort.

An as:name SHOULD be provided for all mon:Items. A short description or explanation of the mon:Item MAY be provided via the as:summary property. A longer description of the mon:Item MAY be provided via the as:content property.

5.2 The mon:ItemSlot Object

URI
https://www.monstr.pub/ns/monstrpub#ItemSlot
Extends
Properties
Inherits all properties from rp:Action, rp:Instance, and rp:Perishable

Describes one or more identical instances of a mon:Item.

The rp:class property MAY be used to specify the class of a mon:ItemSlot, which MUST be a mon:Item. mon:ItemSlots MUST NOT have more than one rp:class. Processors MUST ignore all values of rp:class if there are more than one, or if they do not point to a mon:Item object.

To ensure that the mon:Item is always able to be dereferenced, rp:class links SHOULD point to files on the same server as the associated mon:ItemSlot. Processors MAY refuse to fetch rp:class links which do not share an origin with a given mon:ItemSlot.

When processing a mon:ItemSlot with an associated mon:Item, processors SHOULD use values from the associated mon:ItemSlot if the following properties are not specified on the mon:Item:

The rp:health property describes how many times the items described by the mon:ItemSlot are able to be used. For single-use items, this is the number of items being described. For multi-use items, this is the number of uses remaining for the item. Items which may be used more than once SHOULD each be given their own mon:ItemSlot object.

5.3 The mon:Region Object

URI
https://www.monstr.pub/ns/monstrpub#Region
Extends
Properties
Inherits all properties from as:Object

Describes a region. Regions are objects which MAY be used to discover different mon:Species or mon:Routes. mon:Regions which correspond to real-world locations MUST also be assigned the as:Place type.

The mon:supports property may be used to indicate extensions which are supported by objects associated with the mon:Region. All objects which reference this mon:Region in their as:attributedTo SHOULD support any such extensions.

An as:name SHOULD be provided for all Regions. A tagline for the mon:Region MAY be provided via the as:summary property. A longer description of the mon:Region MAY be provided via the as:content property.

The mon:dex property, if present, MUST contain an as:OrderedCollection of mon:Species objects. New mon:Species objects SHOULD only be added to the end of this collection, and as:Tombstone objects SHOULD be used to mark any mon:Species removed from a mon:dex collection. The ordering of existing items in a mon:dex collection SHOULD NOT change over time.

The mon:routes property, if present, MUST contain an as:OrderedCollection of mon:Route objects. New mon:Route objects SHOULD only be added to the end of this collection, and as:Tombstone objects SHOULD be used to mark any mon:Route removed from a mon:routes collection. The ordering of existing items in a mon:routes collection SHOULD NOT change over time.

All of the objects in the as:OrderedCollections described above SHOULD be located on the same server as the given mon:Region. The mon:Species and mon:Routes discoverable through these collections SHOULD reference this mon:Region in their as:attributedTo.

5.4 The mon:Species Object

URI
https://www.monstr.pub/ns/monstrpub#Species
Extends
Properties
Inherits all properties from rp:Qualified, rp:Quantified, and rp:Role

Describes a variety, or species, of mon.

An as:name SHOULD be provided for all mon:Species. A tagline, or short description, for the mon:Species MAY be provided via the as:summary property. A longer description of the mon:Species MAY be provided via the as:content property.

The mon:Region of a mon:Species MAY be provided, or linked to, using the as:attributedTo property. Each mon:Species MUST NOT have more than one associated mon:Region property. Upon encountering a mon:Species with multiple associated mon:Regions, processors MUST ignore all of them, and treat the mon:Species as though no mon:Region was specified.

If mon:Mon of a particular mon:Species are known to exist on a particular mon:Route, that mon:Route may be provided, or linked to, using the as:location property.

Most of the properties on the mon:Species object are not directly inherited by associated mon:Mon, but MAY be used when generating associated Mon values, in an implementation-defined manner.

6. Properties

6.1 The mon:captureRate Property

URI
https://www.monstr.pub/ns/monstrpub#captureRate
Domain
Range
Functional
True

Provides an estimation of the base likelihood of capturing a mon:Mon under ideal conditions, as a float from 0 (impossible) to 1 (guaranteed). Note that this is merely an estimate, and servers MAY take a number of factors into account when determining the success of a capture.

An object MUST NOT have more than one value for its mon:captureRate property. Upon encountering an object with more than one mon:captureRate value, processors MUST ignore all but the smallest one.

6.2 The mon:dex Property

URI
https://www.monstr.pub/ns/monstrpub#dex
Domain
Range
Functional
True

Provides an as:OrderedCollection or as:Collection of mon:Species which might be found at a given location. For mon:Regions, this MUST be an as:OrderedCollection.

An object MUST NOT have more than one value for its mon:dex property. Upon encountering an object with more than one mon:dex value, processors MUST ignore all values; that is, treat the object as if no mon:dex property had been defined.

6.3 The mon:mon Property

URI
https://www.monstr.pub/ns/monstrpub#mon
Domain
Range
Functional
True

References an as:OrderedCollection or as:Collection of the mon:Mon for which a mon:Trainer is an owner. All of the mon:Mon in the referenced collection MUST be owned by that mon:Trainer.

The ordering of items within the as:OrderedCollection MAY change over time. as:Tombstones SHOULD NOT be used to mark removed items.

An object MUST NOT have more than one value for its mon:mon property. Upon encountering an object with more than one mon:mon value, processors MUST ignore all values; that is, treat the object as if no mon:mon property had been defined.

6.4 The mon:routes Property

URI
https://www.monstr.pub/ns/monstrpub#routes
Domain
Range
Functional
True

Provides an as:OrderedCollection or as:Collection of mon:Routes which might be accessed from a given location. For mon:Regions, this MUST be an as:OrderedCollection.

An object MUST NOT have more than one value for its mon:routes property. Upon encountering an object with more than one mon:routes value, processors MUST ignore all values; that is, treat the object as if no mon:routes property had been defined.

6.5 The mon:supports Property

URI
https://www.monstr.pub/ns/monstrpub#supports
Domain
Range
Functional
True

Provides URIs which represent supported extensions to MonStrPub.

7. Extension

The types above may be extended by other specifications. However, any objects whose type extends one of the above types MUST also declare the base type, as listed above, to ensure cross-compatibility with other servers. Similarly, if a server uses types from other vocabularies which overlap with one of the above types, the MonStrPub type MUST also be specified.

8. Changelog

This section is non-normative.

2018-05-15.
2018-05-08.
2018-05-05.
2018-05-01.
2018-04-21.
2018-04-20.
2018-04-18.