Copyright © 2009-2010 Grégoire Burel
This work is licensed under a Creative Commons Attribution License. This copyright applies to the CURIO Vocabulary Specification and accompanying documentation in RDF. Regarding underlying technology, CURIO uses W3C's RDF technology, an open Web standard that can be freely used by anyone.
The CURIO Vocabulary is being developed within the Organisations, Information and Knowledge (OAK) Group at the University of Sheffield. This project has received funding from the EU project WeKnowIt (ICT-215453).
This specification describes the CURIO language, defined as a dictionary of named properties and classes using W3C's RDF/OWL technology.
The CURIO Vocabulary is a general purpose ontology designed for managing user generated resources in a unified and collaborative fashion. Despite being developed in the context of the WeKnowIt project, the vocabulary can be easily adapted for a particular need thanks to its flexible resource model.
CURIO can be considered as an aggregative ontology since it aggregates and connect many concept from different standard ontology in a formalised way. This vocabulary reuse most of its concept from the SIOC vocabulary but incorporate many classes and properties from other ontology such as DCTerms, GeoOWL, CommonTag and OPO. The ontology is based around the concept of Resource. A Resource is a specific class that holds a user generated content. Currently different class exists. Particularly, the Document and Event classes enables the combination of virtual events with a real one.
This document contains a detailed description of the CURIO Core Ontology and its standard modules.
CURIO has been initially developed for the WeKnowIt project as a mean for connecting the different level of intelligence found within the project. However, the ontology is generic enough for being used in a wide range of project were modeling collective intelligence is necessary. CURIO is an evolving work and not considered stable at the moment. The CURIO RDF namespace is fixed and its identifier is not expected to change.
The authors welcome comments on this document, preferably via emailing the main author since no mailing list exists at the moment<EMAIL_ADDRESS>For more information, see the changes section for details of the changes in this version of the specification.
Collaborative platforms are emerging as a new mean for managing user generated content in order to generate a collective knowledge that can be reused among communities. This generated content produced by the interaction of many user at the same time needs a common format in order to connect all this content together. The effort of creating a common understanding of an online community has been addressed by the SIOC community. However, a common model of the information shared within these communities remains informal.
The Collaborative User Resource Interaction Ontology, or CURIO, is a set of modules that provides a common understanding of resources shared between users on a common platform. The modules model different standard object such as pictures or events according to a community perspective. This perspective requires a formal representation of the generals features found in such type of community such as comments, tags, title, localisation.
The CURIO Vocabulary described in this document create common understanding of the entities manipulated by a community of users. Developers can use this ontology to express the information generated by their user in a formal way for a better exposition of their information. CURIO is not a substitute to SIOC. Instead, CURIO is a set of common practices for defining the structured information available on a social platform. CURIO sits on the top of SIOC and enable a more formal definition of the information encountered on community websites.
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
Namespace URIs of the general form "http://www.example.com/" represent some application-dependent or context-dependent URI as defined in RFC 2396.
The XML Namespace URIs that MUST be used by implementations of this specification are:
An a-z index of CURIO terms, by class (categories or types) and by property.
Classes: | AbstractResource| Agent | Audio | AuthorTag | AutoTag | Document | Event | EventResource | Image | LocalisedResource | Participation | Rating | ReaderTag | Resource | ResourceFeed | SemanticTag | Tag | TaggedContent | Text | User | UserTag | UserUpdate |
Properties: | content | endTime | frequency | has_document | has_event | has_localisation | has_participant | has_participation | has_subEvent | is_subEventOf | is_tagging | mimeType | rate | role | startTime | tag |
CURIO terms, grouped in broad categories.
The CURIO Ontology is written in RDF/OWL and reusing many concepts from SIOC. The following diagram represents an high level overview of the CURIO vocabulary.
Use the mouse cursor over the diagram for zooming it. You can also download the full version of the picture.
Here is a very basic description of a Document Resource:
<curio:Document> <sioc:about>mage0197.jpg</sioc:about> <dc:title>Fallen Tree.</dc:title> <dc:description>The charter square roundabout has been blocked by a fallen tree.</dc:description> <dc:created xsi:type='xsd:dateTime'>2001-10-26T19:32:52Z</dc:created> </curio:Document>
This example, defines a small document resource. The document is a picture. It has a title, a description and a date. A document may have more properties.
The previous example can be encoded in RDFa as well:

 	 Fallen Tree.	 The charter square roundabout has been blocked by a fallen tree.	 26/10/2001 at 19:32

CURIO is being developed within the Organisations, Information and Knowledge (OAK) Group at the University of Sheffield. This project has received funding from the EU project WeKnowIt (ICT-215453). The name "CURIO" is an acronym for "Collaborative User Resource Interaction Ontology". CURIO is also a short word that means "curiosity". The vocabulary was previously internally named "Interaction Model" within the WeKnowIt project.
The rest of this document introduces the most important classes and properties (relationship and attribute) of CURIO. It is highly recommended to read first the SIOC specification for a better understanding of CURIO.
The specific contents of the CURIO Vocabulary are detailed in the CURIO Core Vocabulary Namespace document.
This specification introduces CURIO as a Semantic Web vocabulary or ontology. It describes the CURIO Core Vocabulary and the terms (RDF classes and properties) that constitute it, so that Semantic Web applications can use those terms in a variety of RDF-compatible document formats and applications.
The CURIO ontology is identified by the namespace URI "http://purl.org/net/curio/ns#".
Revisions and extensions of SIOC are conducted through edits to the namespace document, which by convention is published on the Web at the namespace URI.
CURIO modules are extensions to the CURIO Core Vocabulary. A module provides additional features to the core ontology such as specific type of resources. Currently, CURIO has two modules: Resources and Documents.
The main idea of CURIO is the concept of Resource.  This module describes classes that define different type of resources.
Classes defined within this module: Event.
A full definition of these classes and related properties can be found in the namespace of the CURIO Resources module at http://purl.org/net/curio/resources#.
Community platforms very often deal with files or such type of document resources. These resources can be grouped under the concept of Document, a specific type of Resource. For instance, a platform may deals with specific type of data such as images or audio document. In this context it is necessary to provide a suitable representation of such kind of information.
Classes defined within this module: Audio, Document, Image, Text.
A full definition of these classes and related properties can be found in the namespace of the CURIO Resources module at http://purl.org/net/curio/documents#.
CURIO is a contribution to the Semantic Web, the specification is written using W3C's Resource Description Framework (RDF). As a consequence, CURIO adopts XML as its representation language.
CURIO introduces the following classes and properties. There is a link at the top of this document to the RDF/XML version.
Classes: | AbstractResource| Agent | Audio | AuthorTag | AutoTag | Document | Event | EventResource | Image | LocalisedResource | Participation | Rating | ReaderTag | Resource | ResourceFeed | SemanticTag | Tag | TaggedContent | Text | User | UserTag | UserUpdate |
Properties: | content | endTime | frequency | has_document | has_event | has_localisation | has_participant | has_participation | has_subEvent | is_subEventOf | is_tagging | mimeType | rate | role | startTime | tag |
| Status: | stable |
|---|---|
| Properties include: | dc:created dc:source dc:title |
| subClassOf | sioc:Post |
| has subclass | Resource UserUpdate |
The AbstractResource
class is class modeling some attribute of a Resource
. This class should not be instantiated directly. Please consider the Resource
class instead.
| Status: | stable |
|---|---|
| subClassOf | foaf:Agent |
The Agent
class is simply a subclass of foaf:Agent
. As a consequence, it shares all the properties of a foaf:Agent
.
| Status: | testing |
|---|---|
| subClassOf | Document |
The Audio
class a very basic document designed for modeling audio content. This class is defined within the Documents Module namespace.
| Status: | stable |
|---|---|
| subClassOf | UserTag |
| Disjoint With: | AutoTag ReaderTag |
The AuthorTag
class is a specific type of UserTag
designed for identifying that the creator of this tag is also the creator of the resource.
| Status: | stable |
|---|---|
| subClassOf | UserTag |
| Disjoint With: | AuthorTag ReaderTag |
The AutoTag
class is a specific type of UserTag
designed for identifying that it has been asserted by an automatic system.
| Status: | testing |
|---|---|
| Properties include: | mimeType |
| subClassOf | Resource TaggedContent |
| Disjoint With: | Event |
The Document
class specifies an object uploaded by a user on a platform. Typically, a document can be considered as a file object. The uploaded object should be connected using the sioc:about
property and the associated mimeType
.
| Status: | testing |
|---|---|
| Properties include: | has_document has_localisation has_participation has_subEvent is_subEventOf startTime endTime |
| Used with: | has_event is_participationOf |
| subClassOf | Resource |
| Disjoint With: | curior:EventResource Document |
The Event
class specifies an event happening in the real world. Accordingly, an event is bounded by a geo localisation and a time frame.
| Status: | testing |
|---|---|
| Properties include: | has_event |
| Used with: | has_document |
| subClassOf | Resource |
| Disjoint With: | curior:Event UserUpdate |
The EventResource
class specifies a resource that participates in a Event
. Typically, such type of resource is a Document
that describes in a different manner a particular Event
.
| Status: | testing |
|---|---|
| subClassOf | Document foaf:Image |
| Disjoint With: | curiod:Audio curiod:Text |
The Image
class is subclassing foaf:Image
. As a consequence, it shares all the properties of a foaf:Image
.
| Status: | testing |
|---|---|
| Properties include: | has_document has_localisation has_participation has_subEvent is_subEventOf startTime endTime |
| Used with: | has_event is_participationOf |
| subClassOf | Resource |
| Disjoint With: | curior:EventResource Document |
The Event
class specifies an event happening in the real world. Accordingly, an event is bounded by a geo localisation and a time frame.
| Status: | stable |
|---|---|
| Properties include: | weblog gender holdsAccount birthday age made skypeID msnChatID icqChatID mbox status mbox_sha1sum account yahooChatID aimChatID jabberID openid tipjar |
| Used with: | member maker |
| has subclass | Group Person Organization |
| Disjoint With: | Document |
The Agent
class is the class of
agents; things that do stuff. A well
known sub-class is Person
,
representing people. Other kinds of agents
include Organization
and Group
.
The Agent
class is useful in a
few places in FOAF where
Person
would have been overly
specific. For example, the IM chat ID
properties such as jabberID
are typically associated with
people, but
sometimes belong to software bots.
[#] [wiki] [back to top]
| Status: | stable |
|---|---|
| Properties include: | member |
| subClassOf | Agent |
The Group
class represents a
collection of individual agents (and may
itself play the role of a Agent
,
ie. something that can perform actions).
This concept is intentionally quite broad, covering informal and
ad-hoc groups, long-lived communities, organizational groups within a
workplace, etc. Some
such groups may have associated characteristics which could be captured
in RDF (perhaps a
homepage
, name
, mailing list etc.).
While a Group
has the
characteristics of a Agent
, it
is also associated with a number of other Agent
s
(typically people) who
constitute the Group
. FOAF
provides a mechanism, the
membershipClass
property, which relates a Group
to a
sub-class of the class Agent
who
are members of the group. This is a
little complicated, but allows us to make group membership rules
explicit.
The markup (shown below) for defining a group is both complex and
powerful. It
allows group membership rules to match against any RDF-describable
characteristics of the potential
group members. As FOAF and similar vocabularies become more expressive
in their ability to
describe individuals, the Group
mechanism for categorising them into
groups also becomes more powerful.
While the formal description of membership criteria for a Group
may
be complex, the basic mechanism for saying that someone is in a Group
is
very simple. We simply use a member
property of the
Group
to indicate the agents that
are members of the group. For example:
<foaf:Group> <foaf:name>ILRT staff</foaf:name> <foaf:member> <foaf:Person> <foaf:name>Martin Poulter</foaf:name> <foaf:homepage rdf:resource="http://www.ilrt.bris.ac.uk/aboutus/staff/staffprofile/?search=plmlp"/> <foaf:workplaceHomepage rdf:resource="http://www.ilrt.bris.ac.uk/"/> </foaf:Person> </foaf:member> </foaf:Group>
Behind the scenes, further RDF statements can be used to express the rules for being a member of this group. End-users of FOAF need not pay attention to these details.
Here is an example. We define a Group
representing those people who
are ILRT staff members (ILRT is a department at the University of
Bristol). The membershipClass
property connects the group (conceived of as a social
entity and agent in its own right) with the class definition for those
people who
constitute it. In this case, the rule is that all group members are in
the
ILRTStaffPerson class, which is in turn populated by all those things
that are a
Person
and which have a workplaceHomepage
of
http://www.ilrt.bris.ac.uk/. This is typical: FOAF groups are created by
specifying a sub-class of Agent
(in fact usually this
will be a sub-class of Person
),
and giving criteria
for which things fall in or out of the sub-class. For this, we use the
owl:onProperty
and owl:hasValue
properties,
indicating the property/value pairs which must be true of matching
agents.
 <foaf:Group> <foaf:name>ILRT staff</foaf:name> <foaf:membershipClass> <owl:Class rdf:about="http://ilrt.example.com/groups#ILRTStaffPerson"> <rdfs:subClassOf rdf:resource="http://xmlns.com/foaf/0.1/Person"/> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="http://xmlns.com/foaf/0.1/workplaceHomepage"/> <owl:hasValue rdf:resource="http://www.ilrt.bris.ac.uk/"/> </owl:Restriction> </rdfs:subClassOf> </owl:Class> </foaf:membershipClass> </foaf:Group>
Note that while these example OWL rules for being in the
eg:ILRTStaffPerson class are
based on a Person
having a
particular
workplaceHomepage
,
this places no obligations on the authors of actual
FOAF documents to include this information. If the information is
included, then
generic OWL tools may infer that some person is an eg:ILRTStaffPerson.
To go the extra
step and infer that some eg:ILRTStaffPerson is a member
of the group
whose name
is "ILRT staff", tools
will need some knowledge of the way
FOAF deals with groups. In other words, generic OWL technology gets us
most of the way,
but the full Group
machinery
requires extra work for implimentors.
The current design names the relationship as pointing from the group, to the member. This is convenient when writing XML/RDF that encloses the members within markup that describes the group. Alternate representations of the same content are allowed in RDF, so you can write claims about the Person and the Group without having to nest either description inside the other. For (brief) example:
<foaf:Group> <foaf:member rdf:nodeID="martin"/>  </foaf:Group> <foaf:Person rdf:nodeID="martin">  </foaf:Person>
There is a FOAF issue tracker associated with this FOAF term. A design goal is to make the most of W3C's OWL language for representing group-membership criteria, while also making it easy to leverage existing groups and datasets available online (eg. buddylists, mailing list membership lists etc). Feedback on the current design is solicited! Should we consider using SPARQL queries instead, for example?
[#] [wiki] [back to top]
| Status: | stable |
|---|---|
| subClassOf | Agent |
| Disjoint With: | Document Person |
The Organization
class
represents a kind of Agent
corresponding to social instititutions such as companies, societies etc.
This is a more 'solid' class than Group
,
which allows
for more ad-hoc collections of individuals. These terms, like the
corresponding
natural language concepts, have some overlap, but different emphasis.
[#] [wiki] [back to top]
| Status: | stable |
|---|---|
| Properties include: | knows schoolHomepage firstName familyName topic_interest currentProject myersBriggs geekcode img plan workInfoHomepage pastProject family_name surname interest publications workplaceHomepage lastName |
| Used with: | knows |
| subClassOf | Agent Person Spatial Thing |
| Disjoint With: | Document Project Organization |
The Person
class represents
people. Something is a
Person
if it is a person. We
don't nitpic about whether they're
alive, dead, real, or imaginary. The Person
class is a sub-class of the
Agent
class, since all people are
considered 'agents' in FOAF.
[#] [wiki] [back to top]
| Status: | testing |
|---|---|
| Properties include: | sha1 topic primaryTopic |
| Used with: | workInfoHomepage schoolHomepage accountServiceHomepage page weblog isPrimaryTopicOf interest homepage openid publications workplaceHomepage tipjar |
| has subclass | PersonalProfileDocument |
| Disjoint With: | Person Project Organization |
The Document
class represents
those things which are, broadly conceived,
'documents'.
The Image
class is a sub-class of
Document
, since all images
are documents.
We do not (currently) distinguish precisely between physical and
electronic documents, or
between copies of a work and the abstraction those copies embody. The
relationship between
documents and their byte-stream representation needs clarification (see sha1
for related issues).
[#] [wiki] [back to top]
| Status: | testing |
|---|---|
| Properties include: | thumbnail depicts |
| Used with: | thumbnail depiction img |
The class Image
is a sub-class of
Document
corresponding to those documents which are images.
Digital images (such as JPEG, PNG, GIF bitmaps, SVG diagrams etc.) are
examples of
Image
.
[#] [wiki] [back to top]
| Status: | testing |
|---|---|
| subClassOf | Document |
The PersonalProfileDocument
class represents those
things that are a Document
,
and that use RDF to
describe properties of the person who is the maker
of the document. There is just one Person
described in
the document, ie.
the person who made
it and who
will be its
primaryTopic
.
The PersonalProfileDocument
class, and FOAF's
associated conventions for describing it, captures an important
deployment pattern for the FOAF vocabulary. FOAF is very often used in
public RDF documents made available through the Web. There is a
colloquial notion that these "FOAF files" are often somebody's
FOAF file. Through PersonalProfileDocument
we provide
a machine-readable expression of this concept, providing a basis for
FOAF documents to make claims about their maker and topic.
When describing a PersonalProfileDocument
it is
typical (and useful) to describe its associated Person
using the maker
property.
Anything that is a
Person
and that is the maker
of some
Document
will be the primaryTopic
of
that Document
. Although this
can be inferred, it is
helpful to include this information explicitly within the
PersonalProfileDocument
.
For example, here is a fragment of a personal profile document which describes its author explicitly:
<foaf:Person rdf:nodeID="p1"> <foaf:name>Dan Brickley</foaf:name> <foaf:homepage rdf:resource="http://danbri.org/"/>  </foaf:Person> <foaf:PersonalProfileDocument rdf:about=""> <foaf:maker rdf:nodeID="p1"/> <foaf:primaryTopic rdf:nodeID="p1"/> </foaf:PersonalProfileDocument>
Note that a PersonalProfileDocument
will have some
representation as RDF. Typically this will be in W3C's RDF/XML syntax,
however we leave open the possibility for the use of other notations, or
representational conventions including automated transformations from
HTML (GRDDL spec for
one such technique).
[#] [wiki] [back to top]
| Status: | unstable |
|---|---|
A LabelProperty
is any
RDF property with texual values that serve as labels.
Any property that is a LabelProperty
is effectively a sub-property of rdfs:label. This utility
class provides an alternate means of expressing this idea, in a way that
may help with OWL 2.0 DL compatibility.
[#] [wiki] [back to top]
| Status: | unstable |
|---|---|
| Properties include: | accountName accountServiceHomepage |
| Used with: | account holdsAccount |
| subClassOf | A thing |
| has subclass | Online Gaming Account Online E-commerce Account Online Chat Account |
The OnlineAccount
class
represents the provision of some form of online
service, by some party (indicated indirectly via a accountServiceHomepage
)
to some Agent
. The
account
property of the agent
is used to indicate accounts that are associated with the agent.
See OnlineChatAccount
for an example. Other sub-classes include OnlineEcommerceAccount
and OnlineGamingAccount
.
One deployment style for this construct is to use URIs for well-known documents (or other entities) that strongly embody the account-holding relationship; for example, user profile pages on social network sites. This has the advantage of providing URIs that are likely to be easy to link with other information, but means that the instances of this class should not be considered 'accounts' in the abstract or business sense of a 'contract'.
[#] [wiki] [back to top]
| Status: | unstable |
|---|---|
| subClassOf | Online Account |
A OnlineChatAccount
is a OnlineAccount
devoted to
chat / instant messaging. The account may offer other services too;
FOAF's
sub-classes of OnlineAccount
are not mutually disjoint.
This is a generalization of the FOAF Chat ID properties,
jabberID
, aimChatID
,
skypeID
, msnChatID
, icqChatID
and
yahooChatID
.
Unlike those simple properties, OnlineAccount
and associated FOAF terms
allows us to describe a great variety of online accounts, without having
to anticipate
them in the FOAF vocabulary.
For example, here is a description of an IRC chat account, specific to the Freenode IRC network:
<foaf:Person> <foaf:name>Dan Brickley</foaf:name> <foaf:account> <foaf:OnlineAccount> <rdf:type rdf:resource="http://xmlns.com/foaf/0.1/OnlineChatAccount"/> <foaf:accountServiceHomepage rdf:resource="http://www.freenode.net/"/> <foaf:accountName>danbri</foaf:accountName> </foaf:OnlineAccount> </foaf:account> </foaf:Person>
Note that it may be impolite to carelessly reveal someone else's chat
identifier (which
might also serve as an indicate of email address) As with email, there
are privacy and
anti-SPAM considerations. FOAF does not currently provide a way to
represent an
obfuscated chat ID (ie. there is no parallel to the mbox
/
mbox_sha1sum
mapping).
In addition to the generic OnlineAccount
and
OnlineChatAccount
mechanisms,
FOAF also provides several convenience chat ID properties
(jabberID
, aimChatID
, icqChatID
,
msnChatID
,yahooChatID
, skypeID
).
These serve as as a shorthand for some common cases; their use may not
always be
appropriate.
We should specify some mappings between the abbreviated and full
representations of
Jabber, AIM, MSN,
ICQ, Yahoo! and MSN chat
accounts. This has been done for skypeID
.
This requires us to
identify an appropriate accountServiceHomepage
for each. If we
wanted to make the OnlineAccount
mechanism even more generic, we could
invent a relationship that holds between a OnlineAccount
instance and a
convenience property. To continue the example above, we could describe
how Freenode could define a
property 'fn:freenodeChatID'
corresponding to Freenode online accounts.
[#] [wiki] [back to top]
| Status: | unstable |
|---|---|
| subClassOf | Online Account |
A OnlineEcommerceAccount
is a OnlineAccount
devoted to
buying and/or selling of goods, services etc. Examples include Amazon, eBay,
PayPal, thinkgeek, etc.
[#] [wiki] [back to top]
| Status: | unstable |
|---|---|
| subClassOf | Online Account |
A OnlineGamingAccount
is a OnlineAccount
devoted to
online gaming.
Examples might include EverQuest, Xbox live, Neverwinter Nights, etc., as well as older text-based systems (MOOs, MUDs and suchlike).
[#] [wiki] [back to top]
| Status: | unstable |
|---|---|
| Disjoint With: | Document Person |
The Project
class represents
the class of things that are 'projects'. These
may be formal or informal, collective or individual. It is often useful
to indicate the
homepage
of a Project
.
Further work is needed to specify the connections between this class and
the FOAF properties
currentProject
and pastProject
.
[#] [wiki] [back to top]
| Status: | stable | |
|---|---|---|
| Domain: | A thing | |
| Range: | Document | |
| Inverse Functional Property |
The homepage
property relates
something to a homepage about it.
Many kinds of things have homepages. FOAF allows a thing to have
multiple homepages, but
constrains homepage
so that
there can be only one thing that has any
particular homepage.
A 'homepage' in this sense is a public Web document, typically but not
necessarily
available in HTML format. The page has as a topic
the thing whose
homepage it is. The homepage is usually controlled, edited or published
by the thing whose
homepage it is; as such one might look to a homepage for information on
its owner from its
owner. This works for people, companies, organisations etc.
The homepage
property is a
sub-property of the more general
page
property for relating a thing
to a page about that thing. See also
topic
, the inverse of the page
property.
[#] [wiki] [back to top]
| Status: | stable |
|---|---|
| Domain: | Agent |
| Range: | A thing |
The made
property relates a Agent
to something made
by it. As such
it is an
inverse of the maker
property,
which relates a thing to
something that made it. See made
for more details on the
relationship between these FOAF terms and related Dublin Core
vocabulary.
[#] [wiki] [back to top]
| Status: | stable |
|---|---|
| Domain: | A thing |
| Range: | Agent |
The maker
property relates
something to a
Agent
that made
it. As such it is an
inverse of the made
property.
The name
(or other rdfs:label
)
of the
maker
of something can be
described as the
dc:creator
of that thing.
For example, if the thing named by the URI
http://danbri.org/ has a
maker
that is a Person
whose
name
is 'Dan Brickley', we can
conclude that
http://danbri.org/ has a dc:creator
of 'Dan
Brickley'.
FOAF descriptions are encouraged to use dc:creator
only for
simple textual names, and to use maker
to indicate
creators, rather than risk confusing creators with their names. This
follows most Dublin Core usage. See UsingDublinCoreCreator
for details.
[#] [wiki] [back to top]
| Status: | stable | |
|---|---|---|
| Domain: | Agent | |
| Range: | A thing | |
| Inverse Functional Property |
The mbox
property is a
relationship between the owner of a mailbox and
a mailbox. These are typically identified using the mailto: URI scheme
(see RFC 2368).
Note that there are many mailboxes (eg. shared ones) which are not the
mbox
of anyone. Furthermore, a
person can have multiple
mbox
properties.
In FOAF, we often see mbox
used as
an indirect way of identifying its
owner. This works even if the mailbox is itself out of service (eg. 10
years old), since
the property is defined in terms of its primary owner, and doesn't
require the mailbox to
actually be being used for anything.
Many people are wary of sharing information about their mailbox
addresses in public. To
address such concerns whilst continuing the FOAF convention of
indirectly identifying
people by referring to widely known properties, FOAF also provides the
mbox_sha1sum
mechanism,
which is a relationship between a person and
the value you get from passing a mailbox URI to the SHA1 mathematical
function.
[#] [wiki] [back to top]
| Status: | stable |
|---|---|
| Domain: | Group |
| Range: | Agent |
The member
property relates a Group
to a
Agent
that is a member of that
group.
See Group
for details and
examples.
[#] [wiki] [back to top]
| Status: | testing | |
|---|---|---|
| Domain: | Agent | |
| Inverse Functional Property |
The aimChatID
property
relates a Agent
to a textual
identifier ('screenname') assigned to them in the AOL Instant Messanger
(AIM) system.
See AOL's AIM site for more details of
AIM and AIM
screennames. The iChat
tools from Apple also make use of
AIM identifiers.
See OnlineChatAccount
(and OnlineAccount
) for a
more general (and verbose) mechanism for describing IM and chat
accounts.
[#] [wiki] [back to top]
| Status: | testing |
|---|---|
| Domain: | Person |
| Range: | A thing |
A currentProject
relates a Person
to a Document
indicating some
collaborative or
individual undertaking. This relationship
indicates that the Person
has
some active role in the
project, such as development, coordination, or support.
When a Person
is no longer
involved with a project, or
perhaps is inactive for some time, the relationship becomes a
pastProject
.
If the Person
has stopped
working on a project because it
has been completed (successfully or otherwise), pastProject
is
applicable. In general, currentProject
is used to indicate
someone's current efforts (and implied interests, concerns etc.), while
pastProject
describes what
they've previously been doing.
Note that this property requires further work. There has been confusion
about
whether it points to a thing (eg. something you've made; a homepage for a
project,
ie. a Document
or to instances
of the class Project
,
which might themselves have a homepage
.
In practice, it seems to have been
used in a similar way to interest
,
referencing homepages of ongoing projects.
[#] [wiki] [back to top]
| Status: | testing |
|---|---|
| Domain: | A thing |
| Range: | Image |
The depiction
property is a
relationship between a thing and an
Image
that depicts it. As such it
is an inverse of the
depicts
relationship.
A common use of depiction
(and depicts
) is to indicate
the contents of a digital image, for example the people or objects
represented in an
online photo gallery.
Extensions to this basic idea include 'Co-Depiction' (social networks as evidenced in photos), as well as richer photo metadata through the mechanism of using SVG paths to indicate the regions of an image which depict some particular thing. See 'Annotating Images With SVG' for tools and details.
The basic notion of 'depiction' could also be extended to deal with multimedia content (video clips, audio), or refined to deal with corner cases, such as pictures of pictures etc.
The depiction
property is a
super-property of the more specific property
img
, which is used more sparingly.
You stand in a
depiction
relation to any
Image
that depicts
you, whereas img
is typically used
to indicate a few images that are
particularly representative.
[#] [wiki] [back to top]
| Status: | testing |
|---|---|
| Domain: | Image |
| Range: | A thing |
The depicts
property is a
relationship between a Image
and something that the image depicts. As such it is an inverse of the
depiction
relationship. See depiction
for further notes.
[#] [wiki] [back to top]
| Status: | testing |
|---|---|
| Domain: | Person |
The familyName
property is
provided (alongside givenName
)
for use when describing parts of people's names. Although these
concepts do not capture the full range of personal naming styles found
world-wide, they are commonly used and have some value.
There is also a simple name
property.
Support is also provided for the more archaic and culturally varying
terminology of firstName
and lastName
.
See the issue tracker for design discussions, status and ongoing work on rationalising the FOAF naming machinery.
[#] [wiki] [back to top]
| Status: | testing |
|---|---|
| Domain: | Person |
The firstName
property is
provided (alongside lastName
)
as a mechanism to support legacy data that cannot be
easily interpreted in terms of the (otherwise preferred) familyName
and givenName
properties. The concepts
of 'first' and 'last' names do not work well across cultural and
linguistic boundaries; however they are widely used in addressbooks and
databases.
See the issue tracker for design discussions, status and ongoing work on rationalising the FOAF naming machinery.
There is also a simple name
property.
[#] [wiki] [back to top]
| Status: | testing | |
|---|---|---|
| Domain: | Agent | |
| Functional Property |
The gender
property relates a Agent
(typically a
Person
) to a string representing
its gender. In most cases the value
will be the string 'female' or 'male' (in lowercase without surrounding
quotes or spaces).
Like all FOAF properties, there is in general no requirement to use
gender
in any particular
document or description. Values other than
'male' and 'female' may be used, but are not enumerated here. The gender
mechanism is not intended to capture the full variety of biological,
social and sexual
concepts associated with the word 'gender'.
Anything that has a gender
property will be some kind of
Agent
. However there are kinds of
Agent
to
which the concept of gender isn't applicable (eg. a Group
). FOAF does not
currently include a class corresponding directly to "the type of thing
that has a gender".
At any point in time, a Agent
has
at most one value for
gender
. FOAF does not treat gender
as a
static property; the same individual may have different values
for this property
at different times.
Note that FOAF's notion of gender isn't defined biologically or
anatomically - this would
be tricky since we have a broad notion that applies to all Agent
s
(including robots - eg. Bender from Futurama is 'male'). As stressed
above,
FOAF's notion of gender doesn't attempt to encompass the full range of
concepts associated
with human gender, biology and sexuality. As such it is a (perhaps
awkward) compromise
between the clinical and the social/psychological. In general, a person
will be the best
authority on their gender
.
Feedback on this design is
particularly welcome (via the FOAF mailing list,
foaf-dev).
We have tried to
be respectful of diversity without attempting to catalogue or enumerate
that diversity.
This may also be a good point for a periodic reminder: as with all FOAF
properties,
documents that use 'gender
' will
on occassion be innacurate, misleading
or outright false. FOAF, like all open means of communication, supports lying.
Application authors using
FOAF data should always be cautious in their presentation of unverified
information, but be
particularly sensitive to issues and risks surrounding sex and gender
(including privacy
and personal safety concerns). Designers of FOAF-based user interfaces
should be careful to allow users to omit
gender
when describing
themselves and others, and to allow at least for
values other than 'male' and 'female' as options. Users of information
conveyed via FOAF (as via information conveyed through mobile phone text
messages, email,
Internet chat, HTML pages etc.) should be skeptical of unverified
information.
[#] [wiki] [back to top]
| Status: | testing |
|---|---|
The givenName
property is
provided (alongside familyName
)
for use when describing parts of people's names. Although these
concepts do not capture the full range of personal naming styles found
world-wide, they are commonly used and have some value.
There is also a simple name
property.
Support is also provided for the more archaic and culturally varying
terminology of firstName
and lastName
.
See the issue tracker for design discussions, status and ongoing work on rationalising the FOAF naming machinery.
[#] [wiki] [back to top]
| Status: | testing | |
|---|---|---|
| Domain: | Agent | |
| Inverse Functional Property |
The icqChatID
property
relates a Agent
to a textual
identifier assigned to them in the ICQ Chat system.
See the icq chat site for more
details of the 'icq'
service. Their "What
is ICQ?" document
provides a basic overview, while their "About Us page
notes that ICQ has been acquired by AOL. Despite the relationship with
AOL, ICQ is at
the time of writing maintained as a separate identity from the AIM brand
(see
aimChatID
).
See OnlineChatAccount
(and OnlineAccount
) for a
more general (and verbose) mechanism for describing IM and chat
accounts.
[#] [wiki] [back to top]
| Status: | testing |
|---|---|
| Domain: | Person |
| Range: | Image |
The img
property relates a Person
to a
Image
that represents them.
Unlike its super-property
depiction
, we only use img
when an image is
particularly representative of some person. The analogy is with the
image(s) that might
appear on someone's homepage, rather than happen to appear somewhere in
their photo album.
Unlike the more general depiction
property (and its inverse,
depicts
), the img
property is only used with
representations of people (ie. instances of Person
).
So you can't use
it to find pictures of cats, dogs etc. The basic idea is to have a term
whose use is more
restricted than depiction
so
we can have a useful way of picking out a
reasonable image to represent someone. FOAF defines img
as a
sub-property of depiction
,
which means that the latter relationship is
implied whenever two things are related by the former.
Note that img
does not have any
restrictions on the dimensions, colour
depth, format etc of the Image
it
references.
Terminology: note that img
is a
property (ie. relationship), and that
code:Image
is a similarly named class (ie. category, a type
of thing). It
might have been more helpful to call img
'mugshot' or similar; instead
it is named by analogy to the HTML IMG element.
[#] [wiki] [back to top]
| Status: | testing |
|---|---|
| Domain: | Person |
| Range: | Document |
The interest
property
represents an interest of a
Agent
, through
indicating a Document
whose topic
(s) broadly
characterises that interest.
For example, we might claim that a person or group has an interest in
RDF by saying they
stand in a interest
relationship to the RDF home page.
Loosly, such RDF would be saying
"this agent is interested in the topic of this page".
Uses of interest
include a
variety of filtering and resource discovery
applications. It could be used, for example, to help find answers to
questions such as
"Find me members of this organisation with an interest in XML who have
also contributed to
CPAN)".
This approach to characterising interests is intended to compliment other mechanisms (such as the use of controlled vocabulary). It allows us to use a widely known set of unique identifiers (Web page URIs) with minimal pre-coordination. Since URIs have a controlled syntax, this makes data merging much easier than the use of free-text characterisations of interest.
Note that interest does not imply expertise, and that this FOAF term
provides no support
for characterising levels of interest: passing fads and lifelong quests
are both examples
of someone's interest
.
Describing interests in full is a complex
undertaking; interest
provides
one basic component of FOAF's approach to
these problems.
[#] [wiki] [back to top]
| Status: | testing | |
|---|---|---|
| Domain: | A thing | |
| Range: | Document | |
| Inverse Functional Property |
The isPrimaryTopicOf
property relates something to a document that is
mainly about it.
The isPrimaryTopicOf
property is inverse functional: for
any document that is the value of this property, there is at most one
thing in the world
that is the primary topic of that document. This is useful, as it allows
for data
merging, as described in the documentation for its inverse, primaryTopic
.
page
is a super-property of isPrimaryTopicOf
. The change
of terminology between the two property names reflects the utility of
'primaryTopic' and its
inverse when identifying things. Anything that has an isPrimaryTopicOf
relation
to some document X, also has a page
relationship to it.
Note that homepage
, is a
sub-property of both page
and
isPrimarySubjectOf
.
The awkwardly named
isPrimarySubjectOf
is less specific, and can be used with any document
that is primarily about the thing of interest (ie. not just on
homepages).
[#] [wiki] [back to top]
| Status: | testing | |
|---|---|---|
| Domain: | Agent | |
| Inverse Functional Property |
The jabberID
property relates a
Agent
to a textual
identifier assigned to them in the Jabber
messaging
system.
See the Jabber site for more
information about the Jabber
protocols and tools.
Jabber, unlike several other online messaging systems, is based on an
open, publically
documented protocol specification, and has a variety of open source
implementations. Jabber IDs
can be assigned to a variety of kinds of thing, including software
'bots', chat rooms etc. For
the purposes of FOAF, these are all considered to be kinds of Agent
(ie.
things that do stuff). The uses of Jabber go beyond simple IM
chat applications. The
jabberID
property is provided
as a basic hook to help support RDF description
of Jabber users and services.
See OnlineChatAccount
(and OnlineAccount
) for a
more general (and verbose) mechanism for describing IM and chat
accounts.
[#] [wiki] [back to top]
| Status: | testing |
|---|---|
| Domain: | Person |
| Range: | Person |
The knows
property relates a Person
to another
Person
that he or she knows.
We take a broad view of 'knows', but do require some form of reciprocated interaction (ie. stalkers need not apply). Since social attitudes and conventions on this topic vary greatly between communities, counties and cultures, it is not appropriate for FOAF to be overly-specific here.
If someone knows
a person, it
would be usual for
the relation to be reciprocated. However this doesn't mean that there is
any obligation
for either party to publish FOAF describing this relationship. A knows
relationship does not imply friendship, endorsement, or that a
face-to-face meeting
has taken place: phone, fax, email, and smoke signals are all perfectly
acceptable ways of communicating with people you know.
You probably know hundreds of people, yet might only list a few in your public FOAF file. That's OK. Or you might list them all. It is perfectly fine to have a FOAF file and not list anyone else in it at all. This illustrates the Semantic Web principle of partial description: RDF documents rarely describe the entire picture. There is always more to be said, more information living elsewhere in the Web (or in our heads...).
Since knows
is vague by design,
it may be suprising that it has uses.
Typically these involve combining other RDF properties. For example, an
application might
look at properties of each weblog
that was made
by
someone you "knows
". Or check the
newsfeed of the online photo archive
for each of these people, to show you recent photos taken by people you
know.
To provide additional levels of representation beyond mere 'knows', FOAF applications can do several things.
They can use more precise relationships than knows
to relate people to
people. The original FOAF design included two of these
('knowsWell','friend') which we
removed because they were somewhat awkward to actually use,
bringing an
inappopriate air of precision to an intrinsically vague concept. Other
extensions have
been proposed, including Eric Vitiello's Relationship
module for
FOAF.
In addition to using more specialised inter-personal relationship types
(eg rel:acquaintanceOf etc) it is often just as good to use RDF
descriptions of the states
of affairs which imply particular kinds of relationship. So for example,
two people who
have the same value for their workplaceHomepage
property are
typically colleagues. We don't (currently) clutter FOAF up with these
extra relationships,
but the facts can be written in FOAF nevertheless. Similarly, if there
exists a
Document
that has two people
listed as its maker
s,
then they are probably collaborators of some kind. Or if two people
appear in 100s of
digital photos together, there's a good chance they're friends and/or
colleagues.
So FOAF is quite pluralistic in its approach to representing relationships between people. FOAF is built on top of a general purpose machine language for representing relationships (ie. RDF), so is quite capable of representing any kinds of relationship we care to add. The problems are generally social rather than technical; deciding on appropriate ways of describing these interconnections is a subtle art.
Perhaps the most important use of knows
is, alongside the
rdfs:seeAlso
property, to connect FOAF files together.
Taken alone, a FOAF
file is somewhat dull. But linked in with 1000s of other FOAF files it
becomes more
interesting, with each FOAF file saying a little more about people,
places, documents, things...
By mentioning other people (via knows
or other relationships), and by
providing an rdfs:seeAlso
link to their FOAF file, you can
make it easy for
FOAF indexing tools ('scutters') to find
your FOAF and the FOAF of the people you've mentioned. And the FOAF of
the people they
mention, and so on. This makes it possible to build FOAF aggregators
without the need for
a centrally managed directory of FOAF files...
[#] [wiki] [back to top]
| Status: | testing |
|---|---|
| Domain: | A thing |
| Range: | A thing |
The logo
property is used to
indicate a graphical logo of some kind.
It is probably underspecified...
[#] [wiki] [back to top]
| Status: | testing | |
|---|---|---|
| Domain: | Agent | |
| Inverse Functional Property |
A mbox_sha1sum
of a Person
is a textual representation of
the result of applying the SHA1 mathematical functional to a 'mailto:'
identifier (URI) for an
Internet mailbox that they stand in a mbox
relationship to.
In other words, if you have a mailbox (mbox
)
but don't want to reveal its
address, you can take that address and generate a mbox_sha1sum
representation
of it. Just as a mbox
can be used
as an indirect identifier for its owner, we
can do the same with mbox_sha1sum
since there is only one
Person
with any particular value
for that property.
Many FOAF tools use mbox_sha1sum
in preference to exposing mailbox
information. This is usually for privacy and SPAM-avoidance reasons.
Other relevant techniques
include the use of PGP encryption (see Edd Dumbill's
documentation) and the use of FOAF-based
whitelists for
mail filtering.
Code examples for SHA1 in C#, Java, PHP, Perl and Python can be found in Sam Ruby's
weblog entry. Remember to include the 'mailto:' prefix, but no
trailing
whitespace, when computing a mbox_sha1sum
property.
[#] [wiki] [back to top]
| Status: | testing | |
|---|---|---|
| Domain: | Agent | |
| Inverse Functional Property |
The msnChatID
property
relates a Agent
to a textual
identifier assigned to them in the Microsoft online chat system
originally known as 'MSN', and now
Windows
Live Messenger.
See the Microsoft mesenger
and Windows Live
ID sites for more details.
See OnlineChatAccount
(and OnlineAccount
) for a
more general (and verbose) mechanism for describing IM and chat
accounts.
[#] [wiki] [back to top]
| Status: | testing |
|---|---|
| Domain: | Person |
The myersBriggs
property
represents the Myers Briggs (MBTI) approach to
personality taxonomy. It is included in FOAF as an example of a property
that takes certain constrained values, and to give some additional
detail to the FOAF
files of those who choose to include it. The myersBriggs
property applies only to
the
Person
class; wherever you see
it, you can infer it is being applied to
a person.
The myersBriggs
property is
interesting in that it illustrates how
FOAF can serve as a carrier for various kinds of information, without
necessarily being
commited to any associated worldview. Not everyone will find myersBriggs
(or star signs,
or blood types, or the four humours) a useful perspective on human
behaviour and
personality. The inclusion of a Myers Briggs property doesn't indicate
that FOAF endorses
the underlying theory, any more than the existence of weblog
is an
endorsement of soapboxes.
The values for myersBriggs
are the following 16 4-letter textual codes:
ESTJ, INFP, ESFP, INTJ, ESFJ, INTP, ENFP, ISTJ, ESTP, INFJ, ENFJ, ISTP,
ENTJ, ISFP,
ENTP, ISFJ. If multiple of these properties are applicable, they are
represented by
applying multiple properties to a person.
For further reading on MBTI, see various online sources (eg. this article). There are various online sites which offer quiz-based tools for determining a person's MBTI classification. The owners of the MBTI trademark have probably not approved of these.
This FOAF property suggests some interesting uses, some of which could perhaps be used to test the claims made by proponents of the MBTI (eg. an analysis of weblog postings filtered by MBTI type). However it should be noted that MBTI FOAF descriptions are self-selecting; MBTI categories may not be uniformly appealing to the people they describe. Further, there is probably a degree of cultural specificity implicit in the assumptions made by many questionaire-based MBTI tools; the MBTI system may not make sense in cultural settings beyond those it was created for.
See also Cory Caplinger's summary table or the RDFWeb article, FOAF Myers Briggs addition for further background and examples.
Note: Myers Briggs Type Indicator and MBTI are registered trademarks of Consulting Psychologists Press Inc. Oxford Psycholgists Press Ltd has exclusive rights to the trademark in the UK.
[#] [wiki] [back to top]
| Status: | testing |
|---|---|
| Domain: | A thing |
The name
of
something is a simple textual string.
XML language tagging may be used to indicate the language of the name. For example:
<foaf:name xml:lang="en">Dan Brickley</foaf:name>
FOAF provides some other naming constructs. While foaf:name does not explicitly represent name substructure (family vs given etc.) it does provide a basic level of interoperability. See the issue tracker for status of work on this issue.
The name
property, like all RDF
properties with a range of rdfs:Literal, may be used with XMLLiteral
datatyped
values (multiple name
s are
acceptable whether they are in the same langauge or not). XMLLiteral
usage is not yet widely adopted. Feedback on this aspect of the FOAF
design is particularly welcomed.
[#] [wiki] [back to top]
| Status: | testing |
|---|---|
The nick
property relates a Person
to a short (often
abbreviated) nickname, such as those use in IRC chat, online accounts,
and computer
logins.
This property is necessarily vague, because it does not indicate any particular naming control authority, and so cannot distinguish a person's login from their (possibly various) IRC nicknames or other similar identifiers. However it has some utility, since many people use the same string (or slight variants) across a variety of such environments.
For specific controlled sets of names (relating primarily to Instant
Messanger accounts),
FOAF provides some convenience properties: jabberID
,
aimChatID
, msnChatID
and
icqChatID
. Beyond this, the
problem of representing such accounts is not
peculiar to Instant Messanging, and it is not scaleable to attempt to
enumerate each
naming database as a distinct FOAF property. The OnlineAccount
term (and
supporting vocabulary) are provided as a more verbose and more
expressive generalisation
of these properties.
[#] [wiki] [back to top]
| Status: | testing |
|---|---|
| Domain: | A thing |
| Range: | Document |
The page
property relates a thing
to a document about that thing.
As such it is an inverse of the topic
property, which relates a document
to a thing that the document is about.
[#] [wiki] [back to top]
| Status: | testing |
|---|---|
| Domain: | Person |
| Range: | A thing |
After a Person
is
no longer involved with a
currentProject
, or has
been inactive for some time, a
pastProject
relationship
can be used. This indicates that
the Person
was involved with the
described project at one
point.
If the Person
has stopped
working on a project because it
has been completed (successfully or otherwise), pastProject
is
applicable. In general, currentProject
is used to indicate
someone's current efforts (and implied interests, concerns etc.), while
pastProject
describes what
they've previously been doing.
[#] [wiki] [back to top]
| Status: | testing |
|---|---|
The phone
of something is a
phone, typically identified using the tel: URI
scheme.
[#] [wiki] [back to top]
| Status: | testing |
|---|---|
| Domain: | Person |
The plan
property provides a
space for a
Person
to hold some arbitrary
content that would appear in
a traditional '.plan' file. The plan file was stored in a user's home
directory on a UNIX machine, and displayed to people when the user was
queried with the finger utility.
A plan file could contain anything. Typical uses included brief comments, thoughts, or remarks on what a person had been doing lately. Plan files were also prone to being witty or simply osbscure. Others may be more creative, writing any number of seemingly random compositions in their plan file for people to stumble upon.
See History
of the
Finger Protocol by Rajiv Shah for more on this piece of Internet
history. The
geekcode
property may also be
of interest.
[#] [wiki] [back to top]
| Status: | testing | |
|---|---|---|
| Domain: | Document | |
| Range: | A thing | |
| Functional Property |
The primaryTopic
property
relates a document to the
main thing that the document is about.
The primaryTopic
property
is functional: for
any document it applies to, it can have at most one value. This is
useful, as it allows for data merging. In many cases it may be difficult
for third parties to determine the primary topic of a document, but in
a useful number of cases (eg. descriptions of movies, restaurants,
politicians, ...) it should be reasonably obvious. Documents are very
often the most authoritative source of information about their own
primary topics, although this cannot be guaranteed since documents
cannot be
assumed to be accurate, honest etc.
It is an inverse of the isPrimaryTopicOf
property, which relates a
thing to a document primarily about that thing. The choice
between these two
properties is purely pragmatic. When describing documents, we
use primaryTopic
former to
point to the things they're about. When
describing things (people etc.), it is useful to be able to directly
cite documents which
have those things as their main topic - so we use isPrimaryTopicOf
. In this
way, Web sites such as Wikipedia
or NNDB can provide indirect
identification for the things they
have descriptions of.
[#] [wiki] [back to top]
| Status: | testing |
|---|---|
| Domain: | Person |
| Range: | Document |
The publications
property
indicates a Document
listing (primarily in human-readable form) some publications associated
with the
Person
. Such documents are
typically published alongside one's
homepage
.
[#] [wiki] [back to top]
| Status: | testing |
|---|---|
| Domain: | Person |
| Range: | Document |
The schoolHomepage
property relates a Person
to a
Document
that is the homepage
of a School that the
person attended.
FOAF does not (currently) define a class for 'School' (if it did, it
would probably be as
a sub-class of Organization
).
The original application area for
schoolHomepage
was for
'schools' in the British-English sense; however
American-English usage has dominated, and it is now perfectly reasonable
to describe
Universities, Colleges and post-graduate study using schoolHomepage
.
This very basic facility provides a basis for a low-cost, decentralised approach to classmate-reunion and suchlike. Instead of requiring a central database, we can use FOAF to express claims such as 'I studied here' simply by mentioning a school's homepage within FOAF files. Given the homepage of a school, it is easy for FOAF aggregators to lookup this property in search of people who attended that school.
[#] [wiki] [back to top]
| Status: | testing |
|---|---|
| Domain: | Person |
A number of naming constructs are under development to provide
naming substructure; draft properties include firstName
,
givenName
, and surname
. These are not currently
stable or consistent; see the issue
tracker for design discussions, status and ongoing work on
rationalising the FOAF
naming machinery.
There is also a simple name
property.
[#] [wiki] [back to top]
| Status: | testing |
|---|---|
| Domain: | Image |
| Range: | Image |
The thumbnail
property is a
relationship between a
full-size Image
and a smaller,
representative Image
that has been derrived from it.
It is typical in FOAF to express img
and depiction
relationships in terms of the larger, 'main' (in some sense) image,
rather than its thumbnail(s).
A thumbnail
might be clipped
or otherwise reduced such that it does not
depict everything that the full image depicts. Therefore FOAF does not
specify that a
thumbnail depicts
everything
that the image it is derrived from depicts.
However, FOAF does expect that anything depicted in the thumbnail will
also be depicted in
the source image.
A thumbnail
is typically
small enough that it can be
loaded and viewed quickly before a viewer decides to download the larger
version. They are often used in online photo gallery applications.
[#] [wiki] [back to top]
| Status: | testing |
|---|---|
| Domain: | Agent |
| Range: | Document |
The tipjar
property relates an Agent
to a Document
that describes
some mechanisms for
paying or otherwise rewarding that agent.
The tipjar
property was created
following discussions
about simple, lightweight mechanisms that could be used to encourage
rewards and payment for content exchanged online. An agent's
tipjar
page(s) could describe
informal ("Send me a
postcard!", "here's my book, music and movie wishlist") or formal
(machine-readable micropayment information) information about how that
agent can be paid or rewarded. The reward is not associated with any
particular action or content from the agent concerned. A link to
a service such as PayPal is the
sort of thing we might expect to find in a tipjar document.
Note that the value of a tipjar
property is just a
document (which can include anchors into HTML pages). We expect, but
do not currently specify, that this will evolve into a hook
for finding more machine-readable information to support payments,
rewards. The OnlineAccount
machinery is also relevant,
although the information requirements for automating payments are not
currently clear.
[#] [wiki] [back to top]
| Status: | testing |
|---|---|
| Domain: | Document |
| Range: | A thing |
The topic
property relates a
document to a thing that the document is
about.
As such it is an inverse of the page
property, which relates a thing to
a document about that thing.
[#] [wiki] [back to top]
| Status: | testing |
|---|---|
| Domain: | Person |
| Range: | A thing |
The topic_interest
property is generally found to be confusing and ill-defined
and is a candidate for removal. The goal was to be link a person to some
thing that is a topic
of their interests (rather than, per interest
to a page that is about such a
topic).
[#] [wiki] [back to top]
| Status: | testing | |
|---|---|---|
| Domain: | Agent | |
| Range: | Document | |
| Inverse Functional Property |
The weblog
property relates a Agent
to a weblog of
that agent.
[#] [wiki] [back to top]
| Status: | testing |
|---|---|
| Domain: | Person |
| Range: | Document |
The workInfoHomepage
of a Person
is a
Document
that describes their
work. It is generally (but not necessarily) a
different document from their homepage
,
and from any
workplaceHomepage
(s)
they may have.
The purpose of this property is to distinguish those pages you often see, which describe someone's professional role within an organisation or project. These aren't really homepages, although they share some characterstics.
[#] [wiki] [back to top]
| Status: | testing |
|---|---|
| Domain: | Person |
| Range: | Document |
The workplaceHomepage
of a Person
is a
Document
that is the homepage
of a
Organization
that they
work for.
By directly relating people to the homepages of their workplace, we have a simple convention that takes advantage of a set of widely known identifiers, while taking care not to confuse the things those identifiers identify (ie. organizational homepages) with the actual organizations those homepages describe.
For example, Dan Brickley works at W3C. Dan is a Person
with a
homepage
of
http://danbri.org/; W3C is a
Organization
with a homepage
of http://www.w3.org/. This
allows us to say that Dan has a workplaceHomepage
of http://www.w3.org/.
<foaf:Person> <foaf:name>Dan Brickley</foaf:name> <foaf:workplaceHomepage rdf:resource="http://www.w3.org/"/> </foaf:Person>
Note that several other FOAF properties work this way;
schoolHomepage
is the
most similar. In general, FOAF often indirectly
identifies things via Web page identifiers where possible, since these
identifiers are widely
used and known. FOAF does not currently have a term for the name of the
relation (eg.
"workplace") that holds
between a Person
and an Organization
that they work for.
[#] [wiki] [back to top]
| Status: | testing | |
|---|---|---|
| Domain: | Agent | |
| Inverse Functional Property |
The yahooChatID
property
relates a Agent
to a textual
identifier assigned to them in the Yahoo online Chat system.
See Yahoo's the Yahoo! Chat site
for more details of their
service. Yahoo chat IDs are also used across several other Yahoo
services, including email and
Yahoo! Groups.
See OnlineChatAccount
(and OnlineAccount
) for a
more general (and verbose) mechanism for describing IM and chat
accounts.
[#] [wiki] [back to top]
| Status: | unstable |
|---|---|
| Domain: | Agent |
| Range: | Online Account |
The account
property relates a Agent
to an
OnlineAccount
for which
they are the sole account holder. See
OnlineAccount
for usage
details.
[#] [wiki] [back to top]
| Status: | unstable |
|---|---|
| Domain: | Online Account |
The accountName
property of
a OnlineAccount
is a
textual representation of the account name (unique ID) associated with
that account.
[#] [wiki] [back to top]
| Status: | unstable |
|---|---|
| Domain: | Online Account |
| Range: | Document |
The accountServiceHomepage
property indicates a relationship between a
OnlineAccount
and the
homepage of the supporting service provider.
[#] [wiki] [back to top]
| Status: | unstable | |
|---|---|---|
| Domain: | Agent | |
| Functional Property |
The age
property is a relationship
between a Agent
and an integer string representing their age in years. See also birthday
.
[#] [wiki] [back to top]
| Status: | unstable |
|---|---|
| Domain: | Spatial Thing |
| Range: | Spatial Thing |
The based_near
relationship relates two "spatial
things"
(anything that can be somewhere), the latter typically
described using the geo:lat / geo:long
geo-positioning
vocabulary
(See GeoInfo in the W3C
semweb
wiki for details). This allows us to say describe the typical latitute
and
longitude of, say, a Person (people are spatial things - they can be
places) without implying that a precise location has been given.
We do not say much about what 'near' means in this context; it is a 'rough and ready' concept. For a more precise treatment, see GeoOnion vocab design discussions, which are aiming to produce a more sophisticated vocabulary for such purposes.
FOAF files often make use of the contact:nearestAirport
property. This
illustrates the distinction between FOAF documents (which may make
claims using any RDF
vocabulary) and the core FOAF vocabulary defined by this specification.
For further reading on
the use of nearestAirport
see UsingContactNearestAirport
in the
FOAF wiki.
[#] [wiki] [back to top]
| Status: | unstable | |
|---|---|---|
| Domain: | Agent | |
| Functional Property |
The birthday
property is a
relationship between a Agent
and a string representing the month and day in which they were born
(Gregorian calendar).
See BirthdayIssue
for details of related properties that can
be used to describe such things in more flexible ways.
See also age
.
[#] [wiki] [back to top]
| Status: | unstable |
|---|---|
The dnaChecksum
property is
mostly a joke, but
also a reminder that there will be lots of different identifying
properties for people, some of which we might find disturbing.
[#] [wiki] [back to top]
| Status: | unstable |
|---|---|
| Domain: | Person |
The lastName
property is
provided (alongside firstName
)
as a mechanism to support legacy data that cannot be
easily interpreted in terms of the (otherwise preferred) familyName
and givenName
properties. The concepts
of 'first' and 'last' names do not work well across cultural and
linguistic boundaries; however they are widely used in addressbooks and
databases.
See the issue tracker for design discussions, status and ongoing work on rationalising the FOAF naming machinery.
There is also a simple name
property.
[#] [wiki] [back to top]
| Status: | unstable |
|---|---|
The membershipClass
property relates a Group
to an
RDF
class representing a sub-class of Agent
whose instances are all the
agents that are a member
of the Group
.
See Group
for details and
examples.
[#] [wiki] [back to top]
| Status: | unstable | |
|---|---|---|
| Domain: | Agent | |
| Range: | Document | |
| Inverse Functional Property |
A openid
is a property of a Agent
that associates it with a document
that can be used as an indirect
identifier in the manner of the OpenID
"Identity URL". As the OpenID 1.1 specification notes, OpenID itself"does
not provide any mechanism to
exchange profile information, though Consumers of an Identity can learn
more about an End User from any public, semantically
interesting documents linked thereunder (FOAF, RSS, Atom, vCARD, etc.)".
In this way, FOAF and OpenID complement each other;
neither provides a stand-alone approach to online "trust", but combined
they can address interesting parts of this larger problem
space.
The openid
property is "inverse
functional", meaning that anything that is the foaf:openid of something,
is the
openid
of no more than one
thing. FOAF is agnostic as to whether there are (according to the
relevant OpenID
specifications) OpenID URIs that are equally associated with multiple
Agents. FOAF offers sub-classes of Agent, ie.
Organization
and Group
, that allow for such scenarios to be
consistent with the notion that any
foaf:openid is the foaf:openid of just one Agent
.
FOAF does not mandate any particular URI scheme for use as openid
values. The OpenID 1.1
specification includes a delegation
model that is often used to
allow a weblog or homepage document to also serve in OpenID
authentication via "link rel" HTML markup. This deployment model
provides a
convenient connection to FOAF, since a similar technique is used
for FOAF
autodiscovery in HTML. A single document can, for example, serve both as
a homepage and an OpenID identity URL.
[#] [wiki] [back to top]
| Status: | unstable |
|---|---|
| Domain: | Document |
The sha1
property relates a Document
to the textual form of
a SHA1 hash of (some representation of) its contents.
The design for this property is neither complete nor coherent. The Document
class is currently used in a way that allows multiple instances at
different URIs to have the
'same' contents (and hence hash). If sha1
is an owl:InverseFunctionalProperty,
we could deduce that several such documents were the self-same thing. A
more careful design is
needed, which distinguishes documents in a broad sense from byte
sequences.
[#] [wiki] [back to top]
| Status: | unstable |
|---|---|
| Domain: | Agent |
[#] [wiki] [back to top]
| Status: | unstable |
|---|---|
| Domain: | Agent |
status
is a short textual string
expressing what the user is happy
for the general public (normally) to know about their current activity.
mood, location, etc.
[#] [wiki] [back to top]
| Status: | unstable |
|---|---|
This property is a candidate for deprecation in favour of 'honorificPrefix' following Portable Contacts usage. See the FOAF Issue Tracker.
The approriate values for title
are not formally constrained, and will
vary across community and context. Values such as 'Mr', 'Mrs', 'Ms',
'Dr' etc. are
expected.
[#] [wiki] [back to top]
| Status: | archaic |
|---|---|
| Domain: | Person |
This property is considered an archaic spelling of familyName
.
[#] [wiki] [back to top]
| Status: | archaic |
|---|---|
| Domain: | A thing |
| Range: | A thing |
The fundedBy
property relates
something to something else that has provided funding for it.
This property is tentatively considered archaic usage, unless we hear about positive implementation experience.
[#] [wiki] [back to top]
| Status: | archaic |
|---|---|
| Domain: | Person |
The geekcode
property is used
to represent a 'Geek Code' for some
Person
.
See the Wikipedia entry
for
details of the code, which provides a somewhat frivolous and willfully
obscure mechanism for
characterising technical expertise, interests and habits. The geekcode
property is not bound to any particular version of the code.
[#] [wiki] [back to top]
| Status: | archaic |
|---|---|
The givenName
property is
provided (alongside familyName
)
for use when describing parts of people's names. Although these
concepts do not capture the full range of personal naming styles found
world-wide, they are commonly used and have some value.
There is also a simple name
property.
Support is also provided for the more archaic and culturally varying
terminology of firstName
and lastName
.
See the issue tracker for design discussions, status and ongoing work on rationalising the FOAF naming machinery.
[#] [wiki] [back to top]
| Status: | archaic |
|---|---|
| Domain: | Agent |
| Range: | Online Account |
This property is considered archaic usage. It is generally
better to use account
instead.
The holdsAccount
property
relates a Agent
to an
OnlineAccount
for which
they are the sole account holder. See
OnlineAccount
for usage
details.
This property is equivalent to the account
property, which
was introduced primarily to provide simpler naming for the same idea.
[#] [wiki] [back to top]
| Status: | archaic |
|---|---|
| Domain: | A thing |
| Range: | A thing |
This property is considered archaic usage, and is not currently recommended for usage.
The theme
property is rarely used
and under-specified. The intention was
to use it to characterise interest / themes associated with projects and
groups. Further
work is needed to meet these goals.
[#] [wiki] [back to top]
The CURIO Vocabulary is being developed within the Organisations, Information and Knowledge (OAK) Group at the University of Sheffield. This project has received funding from the EU project WeKnowIt (ICT-215453).


Start Syncing!
Synclip allows you to sync your clipboard to any computer running Chrome.
It also stores history of previously shared clipboards!
Find it on the Chrome Webstore.
Get started
User Guide
Synclip allows you to sync your clipboard text between any computers running Chrome. Simply copy
text to your clipboard, click "Sync" on the extension popup, and immediately get notified on all
other computers where you're signed in and have the extension installed. The text can then be
easily copied from the notification. Synclip also stores a history of previously shared clipboards!
Synclip is designed to be very simple and ready to use, but just in case, here's a step-by-step guide.
-
Make sure you're signed in to Chrome
-
In order for Synclip to work, you must be signed in to Chrome on
the device you want to share your clipboard from, and any device you want to share your clipboard
to. For details on signing in to Chrome
click here.
-
Sync your extensions
-
Synclip uses extension sync storage to sync your clipboard. This means you must have
extension synchronization enabled in Chrome.
-
In the top-right corner of the screen, click the Chrome menu
-
Click Settings.
-
Under "Sign In," click Advanced sync settings.
-
To sync all data, select Sync everything from the dropdown.
-
To sync only your extensions (required), select Choose what to sync
from the dropdown, then check the checkbox next to Extensions.
-
Click OK.
- Click the Synclip extension icon
- Your current clipboard content is shown in the clipboard window. To sync, simply click the Sync button.
- All other computers signed into the same user profile on Chrome should immediately show a notification with the
synced content ready to copy.
- Simply click Copy on the notification to copy the content to the clipboard on that computer.
- You can also choose to dismiss the notification by clicking the Dismiss button (don't worry, the content
will be available in your history for you to copy later).
Synclip stores a clearable history of your last 5 synchronized clipboards in the History tab.
- Click the Synclip extension icon
- Click History at the top right of the popup.
- Your most recent clipboard is shown in the clipboard window. You can navigate between previous clipboards
using the arrow buttons at the bottom of the popup.
- To copy content from the history into your clipboard, simply click Copy when the content you want to copy
is in the history clipboard window.
- To clear your history, click Clear history at the bottom of the popup.
Release Notes
Visit this page for a comprehensive list of features and bug fixes as they are released.
Feel free to view the GitHub repository
to explore the code in detail, raise issues, or even contribute! Suggestions for improvements are more than welcome!
1.0.1 & 1.0.2 - Minor page refactoring
Features
- This web page is now hosted separately from the extension
- Minor changes necessary to point to new pages
- Added 404 page
1.0.0 - Initial Release
Features
- Sync clipboard between instances of Chrome on PC
- Notifications with ability to copy or dismiss
- Persistent, clearable history of most recent 5 clipboard syncs
- Support web page with user guide, release notes, and support
Support
Please see the extension support
page or the GitHub repository to submit questions or issues with the extension,
or to view questions or issues raised by other users. I will try to address all issues raised within a timely manner.
Please also see below for some common issues.
If you're not receiving notifications on other PCs after syncing, your clipboard history isn't viewable, or the popup appears disabled, please
visit the User Guide to ensure you've completed the necessary prerequisites and are using the extension properly.
If you see the error message Error syncing clipboard, you have likely exceeded one of the following limitations of chrome sync storage,
the mechanism that Synclip uses to sync clipboards:
- Each clipboard has a maximum storage size of 8162 characters. Try syncing a smaller clipboard if you suspect this is the issue.
- Chrome sync storage is limited to 1800 operations per hour or 120 operations per minute. Synclip may use multiple operations per
sync. Try waiting a few seconds or minutes if you suspect this is the issue.


Test Run:02/06/2019 4:35:51.343 PM
TESTS
Note: * indicates a violation test case
PASSED (1 out of 1)
Case Type
Passed
Total
Violation
0
0
Boolean
1
1
All Cases
1
1
State
Contract Violation
Test Name
Test1
TESTS
PASSED
NONE
t1: test birthday book


Represents a single leaderboard entry.
More...
#include <RuyiNetGetGroupSocialLeaderboardResponse.h>
Represents a single leaderboard entry.
◆ parseJson()
| void Ruyi::SDK::Online::RuyiNetGetGroupSocialLeaderboardResponse::Data::LeaderboardEntry::parseJson |
( |
nlohmann::json & |
j | ) |
|
|
inline |
◆ createdAt
| long Ruyi::SDK::Online::RuyiNetGetGroupSocialLeaderboardResponse::Data::LeaderboardEntry::createdAt |
When this entry was created (UNIX timestamp).
◆ data
| std::string Ruyi::SDK::Online::RuyiNetGetGroupSocialLeaderboardResponse::Data::LeaderboardEntry::data |
Extra data provided by the developer, if any.
◆ index
| int Ruyi::SDK::Online::RuyiNetGetGroupSocialLeaderboardResponse::Data::LeaderboardEntry::index |
◆ pictureUrl
| std::string Ruyi::SDK::Online::RuyiNetGetGroupSocialLeaderboardResponse::Data::LeaderboardEntry::pictureUrl |
The URL of the player's profile picture.
◆ playerId
| std::string Ruyi::SDK::Online::RuyiNetGetGroupSocialLeaderboardResponse::Data::LeaderboardEntry::playerId |
The ID of the player this entry represents.
◆ playerName
| std::string Ruyi::SDK::Online::RuyiNetGetGroupSocialLeaderboardResponse::Data::LeaderboardEntry::playerName |
The display name of the player.
◆ rank
| int Ruyi::SDK::Online::RuyiNetGetGroupSocialLeaderboardResponse::Data::LeaderboardEntry::rank |
The overall rank of the player on this leaderboard.
◆ score
| int Ruyi::SDK::Online::RuyiNetGetGroupSocialLeaderboardResponse::Data::LeaderboardEntry::score |
The latest score for the player.
◆ updatedAt
| long Ruyi::SDK::Online::RuyiNetGetGroupSocialLeaderboardResponse::Data::LeaderboardEntry::updatedAt |
When this entry was last updated (UNIX timestamp).
The documentation for this struct was generated from the following file:


INSPIRED BY PURPOSE. DRIVEN BY PASSION.
Hii, myself Balaji Wadawadagi. I am a positive, driven hardworking, passionate and enthusiastic person who can work effectly both in a team, and also on my own. Because I love what I do, because I have a steady source of motivation that drives me to do my best. This passion lead me to challenge myself daily and learn new skills that help me to do better work.
I am a good communicator, I can work on my own initative, I can prioritize tasks and plans effectively. I thrive on challenge and constantly set goals for myself, so that I always have something to strive towards.
I create the overall look and feel of my website. I plan and build the elements of my website, from structure and layout to images, colours, fonts and graphics.
I make Responsive design according to the user's behavior and environment based on screen size, platform and orientation, which consists of intellegent use of CSS media queries.
I make my project well organized by using meaningful names and avoiding unnecessary comments which makes the code readable for people.
Mera Kisan is an e-commerce website for farmers where they can sell their agricultural produce directly to the customers and businesses.
Open Website View SourceAapka Sahara Foundation is a user-friendly website designed for aged people where the volunteers of ASF can provide help to the aged.
Open Website View SourceGithub MAD Task is a dynamic webpage which changes it's appeaarance depending on the screen size and orienttaion of the device being used to view it.
Open Website View SourceCOME LET'S FIGURE THIS OUT TOGETHER.
CONNECT WITH ME AT -


Two timers are defined:
*one-shot timer: setTimeout(function, miliseconds)
*Interval timer: setInterval(function, miliseconds)
the setTimeout starts the function after a certain time,
stated in miliseconds, has elapsed.
The setInterval runs the function every intervaltime,
as stated in miliseconds.
Both timers return an id that can be used to clear the timer
using the clearTimeout(id) and clearInterval(id)
This text will change color and font after 4 seconds


Before Change
target_libraries = OrderedSet()
if isinstance(current_target, JarLibrary):
target_libraries = OrderedSet(iter_transitive_jars(current_target))
for dep in current_target.dependencies:
info["targets"].append(dep.address.spec)
if isinstance(dep, JarLibrary):
for jar in dep.jar_dependencies:
After Change
libraries.add(target.id)
return libraries
libraries_for_target = set([self._jar_id(jar) for jar in iter_transitive_jars(current_target)])
for dep in self._dependencies_to_include_in_libraries(current_target, modulizable_target_set):
libraries_for_target.update(_full_library_set_for_target(dep))
info["libraries"].extend(libraries_for_target)


| Package | Description |
|---|---|
| com.google.publicalerts.cap |
This package contains the core classes that encode the CAP protocol as
well as classes that can parse and write CAP messages from a variety of
wire formats.
|
| com.google.publicalerts.cap.feed |
This package contains classes to parse and write feeds (Atom, RSS, and more)
enclosing CAP messages.
|
| com.google.publicalerts.cap.profile |
This package contains classes that handle specific CAP profiles, which
specify a set of extra constraints on the CAP format.
|
| com.google.publicalerts.cap.profile.au | |
| com.google.publicalerts.cap.profile.ca | |
| com.google.publicalerts.cap.profile.us | |
| com.google.publicalerts.cap.testing |
| Modifier and Type | Field and Description |
|---|---|
| static Reasons | Reasons.EMPTY |
| Modifier and Type | Method and Description |
|---|---|
| Reasons | Reasons.Builder.build()
Builds and returns the immutable collection.
|
| Reasons | CapException.getReasons() |
| Reasons | XercesCapExceptionMapper.map(Reasons reasons)
Attempts to map Reasons of type CapException.ReasonType.OTHER derived
from Xerces-generated SAXParseExceptions to reasons with more
descriptive CapException.ReasonTypes and error messages specific to CAP.
|
| static Reasons | Reasons.of(Reason... reasons)
Creates a Reasons object with the content specified.
|
| Reasons | Reasons.prefixWithXpath(java.lang.String xPathPrefix)
Builds a copy of this Reasons object, with the XPath prefixed with xPathPrefix.
|
| Reasons | CapValidator.validate(MessageOrBuilder message,
java.lang.String xmlns,
java.lang.String xpath,
boolean visitChildren)
Validates the given message.
|
| Modifier and Type | Method and Description |
|---|---|
| Reasons | XercesCapExceptionMapper.map(Reasons reasons)
Attempts to map Reasons of type CapException.ReasonType.OTHER derived
from Xerces-generated SAXParseExceptions to reasons with more
descriptive CapException.ReasonTypes and error messages specific to CAP.
|
| Constructor and Description |
|---|
| CapException(Reasons reasons) |
| Modifier and Type | Method and Description |
|---|---|
| Reasons | CapFeedValidator.validate(SyndFeed feed)
Validates a feed.
|
| Constructor and Description |
|---|
| CapFeedException(Reasons reasons) |
| Modifier and Type | Method and Description |
|---|---|
| Reasons | CapProfile.validate(AlertOrBuilder alert)
Checks the given alert against the profile and returns a collection of:
errors explaining how the alert does not match the profile,
recommendations and best-practices recommended by the profile to improve the alert.
|
| Reasons | GoogleProfile.validate(AlertOrBuilder alert) |
| Modifier and Type | Method and Description |
|---|---|
| Reasons | AustralianProfile.validate(AlertOrBuilder alert) |
| Modifier and Type | Method and Description |
|---|---|
| Reasons | CanadianProfile.validate(AlertOrBuilder alert) |
| Modifier and Type | Method and Description |
|---|---|
| Reasons | Ipaws1Profile.validate(AlertOrBuilder alert) |
| Modifier and Type | Method and Description |
|---|---|
| static void | CapTestUtil.assertReasons(Reasons actual,
Reason... expected)
Asserts that the expected matches actual, where equality
between Reason objects is guaranteed if two objects have same:
reason type,
XPath.
|


The Web InterFace Language (WIFL) addresses the description of a web application with RESTful APIs. Its goal is to cover common idioms of RESTful APIs and is intended to be used in the annotation of HTML with RDFa. This document contains a detailed description of the model, including the object and datatype classes. The description is marked up with RDFa using the RDF schema vocabulary.
For a comparison of WIFL and WADL, see WIFL is not WADL.


Class IDGenerator
Class designed as a helper for situations where you need to generate and assign a unique integer to each instance of a class, eg. for a class implementing IHasID.
Implements
Namespace: SadRogue.Primitives
Assembly: TheSadRogue.Primitives.dll
Syntax
public class IDGenerator : Object, IMatchable<IDGenerator>
Remarks
This is one way to fulfill the requirement of assigning a persistant, unique ID to each instance of an object, which is a fairly common requirement when defining objects that exist on a grid.
The class may be initialized with a starting unsigned integer -- if none is given, 0 is the default starting point. To assign an ID, call UseID(), and assign the value that it returns. This class is NOT thread-safe on its own -- if it needs to be, you can simply use a lock to wrap any calls to UseID.
Constructors
IDGenerator(UInt32, Boolean)
Constructor.
Declaration
public IDGenerator(uint startingInt = 0U, bool lastAssigned = false)
Parameters
| Type | Name | Description |
|---|---|---|
| UInt32 | startingInt | Unsigned integer to start at (one that will be returned first time UseID() is called). Defaults to 0. |
| Boolean | lastAssigned | Whether or not the last possible ID has been assigned. If this is set to true, the
|
Properties
CurrentInteger
The integer ID that will be returned the next time UseID() is called.
Declaration
public uint CurrentInteger { get; }
Property Value
| Type | Description |
|---|---|
| UInt32 |
LastAssigned
If true, the ID generator has assigned the last ID in the uint range, and will throw an InvalidOperationException the next time UseID is called.
Declaration
public bool LastAssigned { get; }
Property Value
| Type | Description |
|---|---|
| Boolean |
Methods
Matches(IDGenerator)
Compares the two IDGenerator objects to see if they are in an identical state.
Declaration
public bool Matches(IDGenerator other)
Parameters
| Type | Name | Description |
|---|---|---|
| IDGenerator | other |
Returns
| Type | Description |
|---|---|
| Boolean | True if the IDGenerator object specified is in the same state as the current one; false otherwise. |
UseID()
Call every time you wish to "assign" an ID. The integer returned will never be returned again (each integer returned by this function will be unique).
Declaration
public uint UseID()
Returns
| Type | Description |
|---|---|
| UInt32 | The ID that has been assigned. |


Technical Post 5.0
Modeling Objects with Classes
by Joan Torres
I had to change my cellphone this week. So when the idea to model an object with classes came up that's the first thing that popped into my head. After all, phones today have many features and uses we can use as examples. I will definitely not model everything, just some of the essentials to illustrate the use of classes.
How Classes Help
In the programming world, we use classes when we want to define a generic group of objects. In this case, a phone is a generic class for my Samsung phone, much like a vehicle is a generic class for cars, trucks, motorcycles. My Galaxy S is a phone. My Toyota Car is a vehicle. This is the idea behind defining classes. Once a class is initialized we create an instance of that class, otherwise known as an object. Therefore, my specific phone is an object of the class phone.
Now we say what the class is, but why would we use a class instead of just a variable? Well, because we're not saving just the name of the phone. Phones have many attributes as well as actions they can perform. Let's look at a few of these.
Starting with attributes, when we mention our phones to others we commonly talk about its model and phone_number. Those are two attributes every phone has and they can become instance fields or instance variables in our class. Instance variables are variables that are available in every part of the class. Usually these variables need to be given a value in order to create an object. Not all instance variables need to be initialized though. For example, our phone could have a list of contacts. In fact, phones do have one today, but we don't have to add anyone to the list in order to use our phone. However, we can add people to it later. Adding people to the list has to be done through the object in a way that allows us to modify it. The way we do this is through the use of instance methods.
In a class, instance methods are actions our object can do. If we take our phone class and add common actions phones can do as methods we would have a fully functional, useful class. Examples of these actions turned into methods would be the already-mentioned "add_contact" method, place_a_call, and send_a_text.
A Ruby Example
Let's go ahead and turn use this knowledge to make a concrete definition of our phone class using Ruby to illustrate it:
class Phone def initialize(model, phone_number) @model = model @phone_number = phone_number @contacts = Hash.new end def add_contact(name, phone_number) @contacts[name] = phone_number end def place_a_call( phone_number ) #implementation for placing the call end def send_a_text( message, phone_number ) #implementation for sending a text to phone number end end
Note the variables with the at sign (@) in front of them. These are the instance variables. Now, once we have this class we can create an object and add a contact in the following way:
myPhone = Phone.new("Samsung Galaxy S",<PHONE_NUMBER>) myPhone.add_contact("Pats",<PHONE_NUMBER>)
Those phones are not obviously not real, but they help illustrate how this works. This is but a simple example to help show how classes can help us model an object from the world. We can have the class include tons of other actions and variables so that our class can get closer to modeling a real phone. However, it is important to note that these are the internal definitions of a phone. The external, graphical and more physical features can't be defined this way. They are after all "hardware" and what we're working on here is "software".
References
Here's a list of useful resources:


TRIANGLE TRACKER
Enter any Three values you like and start tracking triangle!
First value:
Second value:
Third value:
Track


{{define "page"}}
EVEData.org has been operating since 2008, originally starting as a market and trade tool for the EVE Online in-game browser using basic HTML. Over time and with changes driven by CCP and other third party developers, the site has been refactored a number of times, but remains as a collection of tools that I use in-game for trade or PvP.
The site was originally written in utilizing Linux, Apache (mod_perl), MySQL, and Perl (LAMP). As the second Moondoggie was introduced to the EVE client, the website evolved to include more css formatted HTML and better tools with Javascript triggers to control the UI.
The latest version has been rewritten from the ground up using a micro-service infrastructure in Go, utilizing Percona Cluster, and Redis. Prometheus used to track backend metrics.
{{end}}


Boil water notice affecting 600,000 people to remain in place until at least tomorrow
by By Digital Desk staffIrish Water has said it will be tomorrow before an update is issued on the boil water notice affecting parts of Dublin, Kildare and Meath.
Further tests are being carried out at the Leixlip treatment plant where a fault occurred after heavy rain.
More than 600,000 people are into the 7th day of boiling their drinking water as a result.
In a message posted to Twitter, Irish Water said: "We continued to collect water quality samples over the weekend. Additional testing is taking place today and Tuesday."


30 Days of Google Cloud
gesture
What is this about?
Developer Student Club HIT in collaboration with Google Developers and Qwiklabs brings
to you the #30DaysofGoogleCloud, the best place to get started with the Google Cloud Platform.
Do sign up in order to have a seamless experience for #30DaysofGoogleCloud.
How do we do?
We have 2 Exciting Tracks for you. Click on a Track to get enrolled in it.
Cloud Engineering
Finish the following Set of Quests to complete this Track.
Begin First Quest
Data Science & Machine Learning
Finish the following Set of Quests to complete this Track.
Begin First Quest
wb_incandescent
What's at Stake?
Anyone who completes at least one Track is eligible for Goodies.
T-shirts
Schwags
Certification
filter_drama
Getting Started
#30DaysofGoogleCloud or is it already here?
Meet our facilitator Dipanjan Patra
Contact him for getting help and a seamless experience of #30DaysofGoogleCloud
Join the Conversation
Join our Slack Channel to know more about the Activities, Sessions and other fun stuff.
Join us on
Join our Discord Server to know more about the Activities, Sessions and other fun stuff.
Join us on


Current firmware: It is highly recommended that you upgrade the SPWF01SA firmware. The latest firmware can be found here (requires login).


%include templates/parts/head.html
%include templates/parts/navBar.htmlAll office hours (except Chris') are going to be held in the basement of Huang in the work area infront of the Heroes' Wall. Some office hours are also online. Online office hours will be hosted in Huang and we encourage on campus students to go visit them -- in addition to being in person there will also be a link (see Piazza) that allows SCPD students to ask questions.


{% extends "base.html" %} {% block title %} Wellbeing | Diabetes Predicter {% endblock title %} {% block content %}
Enter simple information about your medical / health condition and get whether are you diabetic or not!


COVID-19, also known as the "coronavirus", is an infectious disease that causes flu-like symptoms. It is highly contageous and can be fatal, especially for older adults and people with certain medical conditions. The WHO has declared the 2019-2020 outbreak of COVID-19 to be a worldwide pandemic. Health experts and government agencies recommend strong social distancing to limit the spread of the virus.
The PyCarolinas organizers recognize the severity of the COVID-19 pandemic. We will take appropriate actions regarding PyCarolinas 2020 to ensure everyone's safety and health. We take this responsibility very seriously. We also encourage everyone to stay safe and stay #PythonStrong!
The information on this page was last updated on March 17, 2020.
Maybe. At the present time, we still intend to host the conference as planned. We hope that COVID-19 will have run its course by June so that we can all return to "normal" lives. However, we just don't know what will happen.
We will follow both common sense and government directives to determine if we should or should not hold PyCarolinas 2020 on June 20. We will err on the side of caution. If we need to cancel the conference on its original date, we will do our best to reschedule it. We will also communicate updates on this website, on Twitter, and through our newsletter. Contact us if you have any questions or concerns.
We changed the entire structure of PyCarolinas to better accommodate the unknowns with this pandemic. Originally, we planned to hold a traditional two-day conference with keynotes and scheduled talks. Now, we plan to hold a one-day unconference instead. We want PyCarolinas to be lean so that we can pivot quickly.
We will continue to monitor the COVID-19 pandemic and make appropriate changes as necessary.
No. We would like PyCarolinas 2020 to be an in-person conference. Hosting it online would require lots of additional work, which would go against our lean planning philosophy for this year. Furthermore, we believe that there is something magical about physically being at a Python conference.
Nevertheless, we would indeed like to stream our lightning talks online for those who cannot join in person. We need volunteers and sponsors to do so. Please contact us if this is a way you can support us!
Probably!  However, if you are coming from far out of town, then we recommend that you monitor the travel situation before committing to come. We would hate for you to book plans and then need to cancel. Furthermore, if you feel ill shortly before or during the conference, then we politely ask you to stay home.
If you registered a ticket but are no longer able to come, then please contact us ASAP so we can give your ticket to someone else!
PyCarolinas 2020 should be free, so no refund should be necessary.


Wind Sylph:
...You have gathered all of them! You are faithful indeed... Even the wind keeps its promises. Take this Tone of Wind... Be careful, because it might blow away...