From: higgins-dev-bounces@xxxxxxxxxxx [mailto:higgins-dev-bounces@xxxxxxxxxxx] On Behalf Of Sergey
Lyakhov
Sent: Tuesday, March 04, 2008
10:57 AM
To: higgins-dev@xxxxxxxxxxx
Subject: Re: [higgins-dev] Telecon
to discuss alternatives to Node
> As part of this when we moved away
from using RDF reification,
> this simplification became clear:
complex values can now be Nodes or BlankNodes.
That should have
read “when we moved away from explicit Value classes (e.g.
StringSimpleValue, etc.). We have moved TOWARDS using reification, not away
from it. [I wrote the opposite of what I meant in the email to Jim that you
quote above. I can’t understand how my fingers typed that.]
So it looks we need to change IdAS interfaces properly.
By the way, I have some questions/notes.
1. Are we going to fully remove IComplexValue interface
(replase it with INode)?
I think we
should. Don’t know where Jim stands on this.
2. According to http://wiki.eclipse.org/Attribute ,
complex attribute should be datatype property with NodeID data range. But in
our case BlankNode does not have NodeID attribute, so we can not use BlankNode
as complex value.
I updated this
wiki page a week or so ago. Please review again.
3. Both classes Node and BlankNode are subclasses
of owl:Thing. Is it correct to present them by the same INode
interface? Perhaps, we can avoid using of BlankNode class if
we define that Node can have 0..1 values of NodeID attribute (if it is
possoble). In this case all Node instances without NodeID
attribute can be considered as "BlankNodes".
I introduced the
BlankNode vs. Node distinction so that I’d have a name for “identifiable”
Nodes. For example if we’re trying to describe what a Node Relation is,
the target of the relation must be an identifiable Node. BlankNodes are not
identifiable. So we wanted to say (in RDF-speak) that the “range”
of a Node Relation must be a Node but NOT a blank node.
4. We need to define the rules of using of Node
as complex value. Can a few Nodes have the same BlankNode
as complex value, should we delete complex values if we delete their
parent node, etc.
Obviously
multiple Nodes can have the same Node as a (complex) value. But I don’t see
how at the IdAS API level it is possible for multiple Nodes to have the same
BlankNode as a (complex) value. At a logical level this doesn’t make
sense to me.
5. There is no any mentioning about metadata
in http://wiki.eclipse.org/Higgins_Global_Graph.
Are we going to use metadata in IdAS? If yes, which kind of metadata are we
going to use (metadata of value (simple/complex), metadata of attribute,
etc.)?
One outcome of
the F2F in Provo
was to do away with metadata and instead just be able to have attribute instances
about other attribute instances. This will involve changing the IdAS API to be
able to get/set attributes on attributes. We need to discuss this with Jim. We didn’t
get this done in Provo.
6. In person-example.owl you sent on February, 20, I
found the example of using higgins:Statement as metadata of simple
value, but if to look at higgins.owl, there is no any indication that
higgins:Statement should be used to represent metadata.
----- Original Message -----
Sent: Sunday, March 02,
2008 4:14 PM
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.
Nodes
don’t just represent people and their interconnections in the social
graph. Nodes (along with Attributes) are the building blocks for representing
: 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.
I did
think of one other word too: “item”.
_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev