Eventities

Foundations

In respect to LOD and OAC standards, all object resources in this code, at any point, are simple objects which can be described in the minimum amount of data, externally gathering all other attributes. At any point, an object should carry its own URI and be dereferencable so as not to break the graph. There is no strong preference to a storage type or characteristic, so long as these objects can be delivered as expected. This projects suggests JSON-LD because it is cool right now, but any RDF-y syntax that comes in the future may be made to work without much stress.

All resources in this system fall into two categories—entities and events. These will be explored in more detail below, but have basically analogous to the difference between the two nodes referenced in a triple. An nv:Entity (prefix pending) is a special resource that carries an [nv:Event] (rdf:describedby) set in place of more advanced relationships and attributes. An nv:Event functions as the node which confers these relationships and attributes by maintaining a set of nv:Outcomes which confer new attributes onto one or more nv:Entitys at a point in time.

Attributes

Attribute	#	Description
@id	1	In an isolated, noninteroperable project this may be as simple as an iterated integer or unique string. In an honest and open project this will be a URI as the @id in JSON-LD specifications.
label	0-1	This can be as complex as desired, but is only a human readable string with no further meaning. In best practice, it is replaced with something appropriately specific to your resource such as rdfs:label.
@type	1	By default, all resources will be nv:Entitys, but this structure makes it appropriate to also identify each of these resources also as foaf:Person, frbr:ClassicalWork, etc.

Attribute Restrictions

No other attribute is recommended on the resource in this state. A specific web application or service may attach other properties as a convenience or presentation aid, but should not include attributes best assigned by an nv:Event. Possible attributes may include icon with a link to a representative image or character, displayTemplate with a link to an HTML snippet for display, etc.

Dereferencing and Delivery

As these are real and discrete objects, it may be useful to not only dereference the set of nv:Events on an nv:Entity, but also to add a general set of properties with information like the generator, modifications, creation date, etc. For use with tools that expect a very well-described resource (and which may not be aware of the concept of the set of events attached), a simple switch may be handy to 'resolve' the events onto the requested entity itself. Clever machines can do this by understanding the rdf:describedBy relationship on their own.

Unpacking nv:Entity

In its simplest form, an nv:Entity is a URI for an authoritative reference. In any project or application where a real link to an established object is needed, the @id should be the authority URI that already exists. When such a URI is unavailable or unreliable, the locally minted @id becomes this (hopefully for the world). The set of nv:Outcomes included in the properties of each nv:Entity is a convenience feature, as it can also be automatically applied by querying for outcomes with this entity (??? SPARQL this ???).

aside for ignorance ??? clean up as below with TTL and JSON

In effect, the nv:Event outcomes confer relationships onto each nv:Entity. This 
is a little more complex than if:

<Person1> a nv:Entity, foaf:Person ;
  foaf:name "Adam" ;
  rdf:describedBy <Outcome1>,<OutcomeN> .

Is reciprocal to

<Event1> a nv:Event ;
  nv:outcomes,ore:aggregates <Outcome1>,<OutcomeN> . 
     // This is a weird part, I might be missing a resourcemap

<Outcome1>
  ore:AggregatedBy, nv:inchronizedBy <Event1> ; // This means "placed in time by"
  rdf:describes <Person1> ;
  foaf:name "Adam: .

In this way, <Event1> can be described with a date, location, etc. that are 
inherited to <Outcome1>, so the description of <Person1> is less static and 
can be seen as updating through time.
~~~~~~
Though this example is a person, an `nv:Entity` is any imaginable noun. It can be used for landmarks, clans, structures, governments, vehicles...

### Unpacking `nv:Event`
There is nothing logical preventing an `nv:Event` from also being an `nv:Entity` and it may be subclassed in the future. However, the principal feature of an `nv:Event` is that is implies it will have a `date` and `location` (of some description). These are not required because just having the node is important enough that further description is gravy. Every `nv:Event`, however, MUST have outcomes (nv:outcomes, ore:aggregates) which `rdf:describes` the `nv:Entity`(s) which they effect.

It is these `nv:Outcome`s that hold the magic for this arrangement. Each one `rdf:describes` an `nv:Entity` to assign a new property to it as a result of the occurrence of the referenced `nv:Event`. In practice in an application, these `nv:Outcome`s will hold three main types of data: *handling information*, *evidence*, and *attribution*. Though certain clearinghouses may establish rules for expected vocabularies, this system does not prevent the addition of any annotation, allowing for the proliferation and simple adoption of emergent ways of identifying handling (as presentation APIs become more relevant and numerous), evidence (as different assertions may require citation conventions which vary by field), and attribution (as authorization matures and more automatic annotation machines are built).

#### Handling Information
An application may specify for itself internal information which makes the data easier to deal with and may also be shared through an application specific API or formalized with external vocabularies. For example, an `nv:Event` which represents a person's birth may look like this:

<person1> a nv:Entity, foaf:Person ;
inApp:label "Adam" ;
rdf:describedBy <outcome.birthday> .</outcome.birthday></person1>

<event.birthday> a nv:Event, foaf:dateOfBirth ; // perhaps this foaf is inappropriate
owl:inXSDDateTime "1966-03-31" ;
nv:location "unhelpful Literal" ;
nv:outcomes,ore:aggregates <outcome.birthday> .
// Other outcomes would be assigning children to parents, siblings, hospitals...</outcome.birthday></event.birthday>

<outcome.birthday> a ore:SpecificResource ;
ore:AggregatedBy, nv:inchronizedBy <event.birthday> ;
rdf:describes <person1> ;
foaf:gender ;
// Other outcomes would be assigning birth parents, gender, given name...</person1></event.birthday></outcome.birthday>

 In the JSON (inApp removes @context, here), we would see these values combined with display and handling information. Just like in JSON-LD, the values of each property may be a simple literal or a specifically described object:

Event
{
@id: "/entities/event/55",
@type: [ "nv:Event", "foaf:dateOfBirth" ],
date: {
@type: "owl:inXSDDateTime",
@value: "1966-03-31",
visible: true, // inApp to show
dataType: "datePicker", // inApp to control input
onUpdate: "updateDateFunction" // inApp input callback
// Other options like 'helptext', 'description', 'editable', etc.
},
location: {
@type: undefined, // or nonexistent
@value: "unhelpful Literal",
visible: true,
dataType: "string",
},
icon: "calendar", // inApp lookup for icon display
label: "Birthday of Abel", // inApp for this event
outcomes: {
@id: "/outcomes/12", // this needs to be referencable
@type: "ore:SpecificResource", // probably unneeded inApp
toEvent: "/entities/event/55", // shorthand for ore:AggregatedBy, nv:inchronizedBy
"rdf:describes": "/entities/person/03"
visible:true,
@set: [
{
@type: ["foaf:person","nv:hasBirthMother"],
@value: { // artificially expanded here
@id: "/entities/person/02",
label: "Eve"
}
labelAs: "Birth Mother", // inApp label used when applied to person display
visible: true,
dataType: "personPicker", // inApp to select or create a person for this
} // others to add here... name, birth father, gender...
]
}
}

Person
{
@id: "/entities/person/03",
@type: [ "nv:Entity", "foaf:Person" ],
label: "Abel", // inApp convenience label
icon: "male",
events: { // shorthand for rdf:DescribedBy
@set: [ "/entities/event/55" ]
},
// All else is conferred by dereferencing the events above
"nv:hasBirthMother" : "/entities/person/02"
}
~~~~~~~

In the same nv:Event, in a well-done application, the form for adding this birthday would also include an entry in the nv:Event for Eve, assigning a "nv:hasOffspring <Abel>" to ensure the reciprocal relationship is not only assigned, but attached to the very same birthday for easy discovery.

Evidence

Ultimately, the goal of this organization is to set up a mechanism that lays plain the evidence for each assertions or assignment. ??? What to use ??? maybe [SPAR ]http://sempublishing.sourceforge.net/ is good.

To that end, an outcome may look like this (with omissions):

~~~~~
{
@id: "/outcomes/12",
toEvent: "/entities/event/55",
"rdf:describes": "/entities/person/03"
visible:true,
@set: [
{
@type: ["foaf:person","nv:hasBirthMother"],
@value: "/entities/person/02",
evidence: "Genesis 4:2", // ??? some good scriptural or canonical text citation
attribution: "http://ident.com/JohnQPublic" // more below
}
]
}
~~~~~~
The evidence may be as populated as possible and refer to any sort of item that supports this. It is not possible to overload this property, but subordinating derivative references or authorities can make a well-established "fact" easier to resolve.

Attribution

The evidences, the outcomes, and indeed any referenced entity here, can have its own attribution. It may be an automated machine process, an individual scholar, a center or research group, but they will be described in this area.

Not to be diminished by its position or succinctness, this concept of micro-publishing is supported by this system and can become a powerful way to trace attribution of the research and work that goes into this data. Authentication is still wanting, but nevertheless these attributions allow for some level of trust when determining the quality of linked data or community contributions.