From: higgins-dev-bounces@xxxxxxxxxxx [mailto:higgins-dev-bounces@xxxxxxxxxxx] On Behalf Of Anthony Nadalin
Sent: Tuesday, February 05, 2008
10:35 AM
To: Higgins
(Trust Framework) Project developer discussions
Cc: 'Higgins
(Trust Framework) Project developer discussions'; higgins-dev-bounces@xxxxxxxxxxx
Subject: RE: [higgins-dev] Data
Model Discussions
So lets have a dedicated call either this week or next
to discuss as all of us were not in the room when the changes were made and
need to understand.
Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122
"Paul
Trevithick" ---02/05/2008 09:29:29 AM---1) WRT
|
From:
|
"Paul Trevithick"
<paul@xxxxxxxxxxxxxxxxx>
|
|
To:
|
"'Higgins \(Trust Framework\) Project developer
discussions'" <higgins-dev@xxxxxxxxxxx>
|
|
Cc:
|
<higgins-dev-bounces@xxxxxxxxxxx>
|
|
Date:
|
02/05/2008 09:29 AM
|
|
Subject:
|
RE: [higgins-dev]
Data Model Discussions
|
1) WRT http://wiki.eclipse.org/Higgins_Global_Graph: You’re
right the
Identifiers section of the above page was out of
sync with latest changes. I
fixed it just now.
As you can see there remains one last work item
(that Drummond is working
on), namely, merging I-NodeIdDatatype and
I-NodeRelationDatatype. [We now
realize that these two are really just relative
and absolute variants of a
new thing that could be either one.]
Identifiers are now lower level "Attribute
Value Datatypes" --really just
constraints on URIs. Attributes can now use these
lower level datatypes for
their values. For example, a Context Relation
would be an attribute of a
Context instance whose attribute type is
"Context Relation", whose value is
an instance of ContextIdDatatype.
2) Jim, Drummond, Markus and I continued working
through the data models
after the F2F officially ended on Thursday. When
we officially ended, we had
a set of seven core concepts (not including the 3
(and soon 2) attribute
value datatypes). After a few hours we rearranged
them and re-named them to
transform them from a fully hierarchical "is
a" hierarchy which is
conceptually more pure, to a flatter set of
concepts that we all strongly
felt would be much more convenient for IdAS
clients to use.
In the flattened form, for example it is easier to
ask of an I-Node (e.g. a
person):
a) get a list of its friends (query for all I-Node
Relations)
b) get a list of its "other"
representations of this person (usually in
different Contexts) (query for all I-Node
Correlations)
c) get the sole unique identifier of this I-Node
(query for the I-NodeId)
If OTOH these concepts mentioned above are
arranged into this three level
hierarchy:
I-Node Relations
I-Node Correlation
I-NodeId
[In other words: I-NodeId is a kind of I-Node
Correlation, and I-Node
Correlation is a kind of I-Node Relation]
Then while this three level hierarchy is strictly
true, it makes it awkward
to do queries, (a), (b), mentioned above that we
think will be very common.
Why? To answer (a) above you would first do a
query for I-Node Relations,
then you'd loop through the resulting list and
remove the Correlations and
the sole I-NodeId to get just the
"friends" that you want. [Note: When doing
an IdAS query for attribute of type X, IdAS will
return all values from all
attributes of type X AND ALL SUB-TYPES]
The current, complete "is a" hierarchy
is as follows:
Attribute
Context Relation
Context Correlation
ContextId
I-Node Relation
I-Node Correlation
I-NodeId
[Note: following the same line of reasoning, even
the above one level of
hierarchy isn't as convenient as it could be by
completely flattening it.
There is, for example, no single call that will
return the set of all
attributes that are NOT relations, correlations or
the I-NodeId (or
ContextId) attributes.]
-Paul
________________________________________
From: higgins-dev-bounces@xxxxxxxxxxx
[mailto:higgins-dev-bounces@xxxxxxxxxxx]
On Behalf Of Anthony Nadalin
Sent: Monday, February 04, 2008 11:42 AM
To: Higgins
(Trust Framework) Project developer discussions
Cc: 'Higgins
(Trust Framework) Project developer discussions';
higgins-dev-bounces@xxxxxxxxxxx
Subject: RE: [higgins-dev] Data Model Discussions
It seems that the data model is now some what
messed up on the wiki as the
items listed under domain concepts and the items
under Identifiers overlap
and are mis matched. Also this does not seem to be
the state in which we
closed the meeting on Thursday. What caused the
changes ?
Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122
"Drummond Reed"
---01/30/2008 06:09:49 PM---I like this summary. A few
questions/suggestions inline marked [=Drummond].
From:
"Drummond Reed"
<drummond.reed@xxxxxxxxxxxx>
To:
"'Higgins
(Trust Framework) Project developer discussions'"
<higgins-dev@xxxxxxxxxxx>
Date:
01/30/2008 06:09 PM
Subject:
RE: [higgins-dev] Data Model Discussions
________________________________________
I like this summary. A few questions/suggestions
inline marked [=Drummond].
________________________________________
From: higgins-dev-bounces@xxxxxxxxxxx
[mailto:higgins-dev-bounces@xxxxxxxxxxx]
On Behalf Of Anthony Nadalin
Sent: Wednesday, January 30, 2008 3:55 AM
To: higgins-dev@xxxxxxxxxxx
Subject: [higgins-dev] Data Model Discussions
So continuing on our Data Model Topic of
yesterday, here is what I see being
our only constructs:
Context: is a typed object with a set of one or
more Digital Subjects
identified by a ContextId.
[=Drummond] Do you mean that the ContextId
identifies the set of Digital
Subjects (which it does), or that it identifies
the Context (which I believe
it does too)? If the former, maybe we should say,
“Context is a typed object
with a set of one or more Digital Subjects, the
set of which is identified
by a ContextId.”
If the latter, “Context is a typed object,
identified by a ContextId, with a
set of one or more Digital Subjects.”
ContextId is typed object that contains a URI or
XRI that identifies a
single Context.
Digital Subject is a typed object that has zero or
more Attributes.
SubjectId is a typed object of type attribute that
has been pre-defined that
identifies a single Digital Subject.
[=Drummond] Suggest: “SubjectId is a
pre-defined typed object (of type
Attribute) that identifies a single Digital
Subject within a Context.”
Attribute is a typed object and identified by is
identified by a URI that
defines its type. An attribute may have one or
more values. The values may
be of simple type (defined by the XML Schema
literal types) or complex
(structured) type. An attribute may have
attributes.
[=Drummond] Do you want to say anything about Higgins pre-defined Attributes
that supply the Attribute metadata specified in
HOWL, i.e., add the sentence
at the end, “Higgins
has pre-defined a set of attributes for use on other
attributes that provide metadata supporting the Higgins Data Model.”
Relation is a typed object of type attribute that
has been pre-defined that
links one Digital Subject to another Digital Subject
in the same or within a
different Context.
[=Drummond] “Relation is a pre-defined typed
object (of type Attribute) that
links one Digital Subject to another Digital
Subject in the same or within a
different Context.”
Correlation is a typed object of attribute that
has been pre-defined that is
used when the two Digital Subjects being linked
are representations of the
same SubjectId
[=Drummond] On this one, as I understand it, if
the Correlation is within
the same Context, the SubjectIds can’t be the
same (or else they would not
be unique in the Context). If it is across
contexts, the SubjectIds may or
may not be the same. If so, how about,
“Correlation is a pre-defined typed
object (of type Attribute) used when the the two
Digital Subjects being
linked represent the same entity, although they
may have different
SubjectIds.”
_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev
_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev
