From:
higgins-dev-bounces@xxxxxxxxxxx [mailto:higgins-dev-bounces@xxxxxxxxxxx] On Behalf Of Nataraj Nagaratnam
Sent: Sunday, March 02, 2008 8:45
AM
To: Higgins (Trust Framework)
Project developer discussions
Cc: 'Higgins (Trust Framework)
Project developer discussions'; higgins-dev-bounces@xxxxxxxxxxx
Subject: RE: [higgins-dev] Telecon
to discuss alternatives to Node
These
nuances about when something is blank, complexnode etc are good for us -
developers who understand and entrenched in the system. But for those app
developers and community interested in what Higgins has to offer, I think we
need to keep it simple in terms of what they are interested in dealing with
(persons, org, devices, etc). Thus the terminology is important.
So there are couple of things over the different threads of discussions
- Terminology
In this context, Greg summarized - The
debate here is what Higgins should call the digital representation of an Entity.
That seems to be the case. If so ..
how about "DigitalEntity"? This way we have different terms for
the thing-being-represented and representation itself... as Entity and DigitalEntity respectively. Will that help with the
debate/discussion here? We had used DigitalSubject.. so I think we are not
averse to the idea of having a prefix 'Digital.'... and this may also help
keep some obvious consistency/relationship between the two terms even for
someone new to Higgins.
- Semantics
Like Jim and Tony have expressed in their notes - I also do not believe we
should use the same term for primary entity objects (like person, org
etc), as well as for their complex value attributes or any other object/data/metadata
that maybe associated with. This will create confusion - if it confuses us
(dev community), then it is guaranteed to confuse those outside this dev
list.
This semantic separation, that gets well reflected in terminology, is
important for consumability of our APIs to developers and community
outside the Higgins dev list.
-Raj
"Paul
Trevithick" ---03/02/2008 09:14:57 AM---Jim,
|
"Paul
Trevithick" <paul@xxxxxxxxxxxxxxxxx>
Sent by:
higgins-dev-bounces@xxxxxxxxxxx
03/02/2008 09:14 AM
|
Please respond to
"Higgins \(Trust Framework\) Project developer discussions"
<higgins-dev@xxxxxxxxxxx>
|
|
|
To
|
"'Higgins
\(Trust Framework\) Project developer discussions'" <higgins-dev@xxxxxxxxxxx>
|
|
cc
|
|
|
Subject
|
RE: [higgins-dev]
Telecon to discuss alternatives to Node
|
|
Jim,
I should have explained. The diagram reflects some proposed updates
to the model, not what’s in v1.0 of the data model. I’ve been
working on a series of changes, improvements to the model as part of the HOWL
update. As part of this when we moved away from using RDF reification, this
simplification became clear: complex values can now be Nodes or BlankNodes. If
it is a Node and if/when we move over to the updated model
IContext.getNode(<someNodID>) should return a complex value. A BlankNode
is a node without a NodeID. If the complex value is a BlankNode, then it cannot
be found using IContext.getNode (which gets us back to where we are with
complex values in v1.0).
-Paul
From: higgins-dev-bounces@xxxxxxxxxxx [mailto:higgins-dev-bounces@xxxxxxxxxxx]
On Behalf Of Jim Sermersheim
Sent: Sunday, March 02, 2008 6:50 AM
To: 'Higgins (Trust Framework) Project developer discussions'
Subject: Re: [higgins-dev] Telecon to discuss alternatives to Node
Ok, either I'm confused now, or IdAS is not representing things as you describe
them, Paul. In IdAS, a complex attribute is not a node. Otherwise someone would
be able to get that node using IContext.getNode(<someNodeID>). I know I
may be using screwed up logic to come to this understanding of what you're
saying. Let me know if I am.
Jim
>>> "Paul Trevithick" <paul@xxxxxxxxxxxxxxxxx>
03/01/08 10:45 PM >>>
Although Entity was the winner of the vote, it was decided at the Higgins call
last Thursday that we needed a dedicated call to make sure that we’re all
on the same page as to exactly what we’re naming here. We felt that we
needed at least one of the folks proposing the winning “Entity”
term to be present on the call before we can finalize this issue. The
non-Entity folks were not convinced that we’re all seeing the problem
(never mind the solution) the same way.
To try to get to closure, I’ve created: http://doodle.ch/7sfxpr6hvu29wnys
to pick a good time on Wednesday to discuss this.
One more thing...
Nodes don’t just represent people and their interconnections in the
social graph. Nodes (along with Attributes) are the building blocks for
representing
everything
: People, Groups, Events, Documents, Postal Addresses in a Context.
Speaking of which, here’s an example of a Node representing some partial
aspect of a Person Entity that has an attribute “hasAddress” whose
value is a Node representing a postal address. When the value of an attribute
is a Node, we call this a “complex” (as opposed to a literal)
value. Literal values are drawn as squares.
[If you’re familiar with RDF you’ll see that a Higgins Node is
almost exactly the same concept as an RDF node.]
If, after the discussion, we all think we really are seeing the issues the same
way, then we’ll settle on Entity as the Node replacement, as it was the
most popular term.
-Paul
I did think of one other word too: “item”.
_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev
