Old Persona Data Model Naming Notes

{{#eclipseproject:technology.higgins|eclipse_custom_style.css}}

EntityIds and ContextIds

By convention the Persona Data Model 2.0 uses a restricted set of the full capabilities of CDM 2.0. The restriction is in the area of EntityIds and ContextIds. PDM 2.0 adds the following restriction:

• All absolute entityId and all contextIds MUST be XRI 2.0 URIs or Linked Data URIs

EntityIds

• An entityId MAY be represented in relative form--relative to the base URI of the containing context. e.g. "foo" is an example of a relative entityid. If http://boo.com# is the ContextId containing "foo" then http://boo.com#foo would be the absolute form
• Whether or not an entityId is relative or absolute MUST be able to be determined by inspection of its syntax

Resolution:

• EntityIds MAY be resolvable
• A resolveable entityId resolves to exactly one entity. This entity is called the authoritative entity (resource description).
  • Note: although the following capability is not yet used by Higgins code, it is possible that for any given context, C, there may exist both entityId references that resolve to entities within C as well as entityId references that resolve to entities within contexts other than C
• EntityIds that resolve to a context outside of their containing context MUST be in absolute form

Context objects:

1. The entityId of the special object within a context that represents the context itself is, by convention, named "_ContextSingleton"

Example

Here is an example of an absolute EntityId:

   http://xri.net/@mydex*ptrevithick/($context)*(amazon.com)//Person_1

The above is comprised of this ContextId:

   http://xri.net/@mydex*ptrevithick/($context)*(amazon.com)

Where:

• http//xri.net is prepended to @mydex to convert XRI into URI form
• @mydex is Mydex's entry in the global "@" registry run by Neustar
• @mydex*ptrevithick is paul's i-name (it is a mydex "community" i-name that cost me nothing as Mydex runs their own registry). We could have substituted "=paul.trevithick" (which Paul would have had to pay for) instead of "@mydex*ptrevithick" as long as Paul had carefully set up the ($context)*(amazon.com) SEP identically at both the =paul.trevithick service and the @mydex*ptrevithick service.
• ($context)*(amazon.com) is the portion that identifies the amazon.com profile context as opposed to some other context on Paul's PDS

The above contextId is concatenated with "//" and this relative EntityId:

   Person_1

Where

• Person_1 is the relative entity id within the context. In reality is more likely some number like a34f38c390b8

Issues

In the Higgins PDS, all data is stored as Statements. Each Statement consists of a Subject, Predicate, and Object. Each Statement is stored in a Content (AKA Graph). Contexts, Subjects, Predicates, and many Objects (some Objects are literal values) are specified by URIs. A URI which represents a Subject in one Statement may represent a Context, Predicate, or Object in another Statement. Statements pertaining to the same Subject or Object may be contained in different Contexts. A Store contains a set of Contexts. The Higgins PDS attempts to handle scenarios involving multiple Stores.

Many applications will want to access all of the Statements related to a specific:

• Context
• Subject
• Object
• Subject and Predicate
• Object and Predicate
• Subject in Context
• Object in Context
• etc.

When all of the Contexts are contained in the same Store, these queries are relatively trivial. However, much complexity is involved when they are contained in multiple, potentially discoverable, Stores. When Contexts are created, a decision must be made regarding which Store will comtain them and how they will be named. When Statements are created, a decision must be made regarding which Context will contain them. When new Subjects and Objects are created, they must be named in a way that allows them to be unique and allows the discovery of which Context (and Stores) contain Statements pertaining to them. In the Higgins PDS, Users may establish relationships with different Store providers, and may decide to migrate from one provider to another. Therefore, the identifier used for Contexts, Subjects, and Objects should not lock them into a specific Store.

Linked Data URIs and Universal Data Identifiers (UDI)s are technologies designed to help solve many of these problems. However, these alternatives both seem limited in a way that assumes that all Statements related to that Subject or Object are contained in the same Context (in the same Store).

There seems be be a need for a service that allows the registration, modification, and resolution of these identifiers in a way that allows an appropriate authority to maintain control over how they resolve. Many problems must be solved to make this work, including:

• No single authority is appropriate for all Statements related to a specific Subject or Object, so who controls how the URIs resolve?
• Even if Statements are protected via access control, knowing that there are Statements related to a specific Subject or Object in a specific Context or Store is often enough to disclose sensitive information.
• Since not all Stores are expected to be equally performant or contain relevent data, a search for all Statements related to a specific Subject or Object should not require replication of all Contexts in all Stores, but how are we to determine which are important?

Due to the above issues, for the near term, the Higgins Project will progress with the following simplifying assumption:

• The will be one Store containing all Contexts accessed thru any instance of the Higgins Personal Data Service and associated clients.
• Subjects and Object will be named relative to the authoritative Context where they are defined.
• Therefore, a separate Name Resolution Service will not be needed.

Questions

• Assuming we can find all of the Statements related to a Subject, how can we determine which Context is authoritative for that Subject?
  • It seems enough in most cases that the Entity URI includes the authoritative Context URI.
  • Should there be a statement: <contextname> <isauthoritativefor> <entityname> for every Entity in order to cover that cases where Entity URI does not include the authoritative Context URI?
• Other than the root Person, does the name of an Entity matter as long as it is unique within the scope of the authoritative Context?
  • A simple approach could be <contextname>//<entityname> where entityname is <classname>_<N> where N is a counter scoped to the Context.
    • A statement: <contextname> <entitycounter> <N> would be placed inside each Context.
    • N would be set to 0 initially and incremented each time a new Entity was created.

Naming Conventions

Contexts

Contexts are named according to their scope: Universal, User, Application, Site, User @ Site, User @ Application, User @ User, Application @ Site, etc. Most Context names will be in the form of a URI defined under the PDS. Where possible, the URI will resolve to Linked Data. URIs will be of the form:

  http://<pdsservername>/data?[user=<username>][&][peer=<username>][&][app=<appname>][&][site=<sitename>][&][context=<contextname>]

Universal Contexts

There are a few Contexts that contain definitions of classes and other statements that are required in order for the system to function (e.g. those that define the Persona Data Model). These Contexts are usually defined in OWL/RDF files that are accessible at their Base URI. The statements in these files will be loaded into Contexts named with the Base URI:

Example

  http://www.eclipse.org/higgins/ontologies/2010/6/persona

Note

Universal Contexts are also accessible as Linked Data under an alternate name relative to the PDS.

Example

  http://pds.azigo.com/data?context=(http://www.eclipse.org/higgins/ontologies/2010/6/persona)

User Contexts

For every User with an account, there is exactly one Root Context.

Example

  http://pds.azigo.com/data?user=ptrevithick

User at Site Contexts

Example

  http://pds.azigo.com/data?user=ptrevithick&site=bestbuy.com

Application at Site Contexts

Example

  http://pds.azigo.com/data?app=formfiller&site=bestbuy.com

User at Peer Contexts

Example

  http://pds.azigo.com/data?user=ptrevithick&peer=mmcintosh

Non-Context Entities

URIs will be relative to the authoritative Context URI.

Example

  <contextname>//<entityname>

Root Person

The Root Person in each User's Root Context has a relative name of Person_0.

Example

  http://pds.azigo.com/data?user=ptrevithick//Person_0

Other Entities

TBD