Tony,
It sounds like we’re just down to
semantics here. Per RFC 3986 (URIs), section 1.1:
Identifier
An identifier embodies the information required to distinguish
what is being identified from all other things within its scope of
identification. Our use of the terms "identify" and "identifying"
refer to this purpose of distinguishing one resource from all
other resources, regardless of how that purpose is accomplished
(e.g., by name, address, or context). These terms should not be
mistaken as an assumption that an identifier defines or embodies
the identity of what is referenced, though that may be the case
for some identifiers. Nor should it be assumed that a system
using URIs will access the resource identified: in many cases,
URIs are used to denote resources without any intention that they
be accessed. Likewise, the "one" resource identified might not be
singular in nature (e.g., a resource might be a named set or a
mapping that varies over time).
By that definition, an internal database
pointer is an identifer.
But no need to argue about semantics. If
you prefer “reference” that’s fine with me. I think everyone agrees that the
value of an EntityId is a “reference” that identifies exactly one Entity in a
context.
=Drummond
From:
higgins-dev-bounces@xxxxxxxxxxx [mailto:higgins-dev-bounces@xxxxxxxxxxx] On Behalf Of Anthony Nadalin
Sent: Friday, September 19, 2008
12:11 PM
To: Higgins (Trust Framework)
Project developer discussions
Cc: Higgins (Trust Framework)
Project developer discussions; higgins-dev-bounces@xxxxxxxxxxx
Subject: Re: Strawman for 0..n
entity ids [WAS:[higgins-dev] Myposition onEntityId]
does not have to be, as internal data base pointers
are not identifiers
Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122
---09/19/2008
09:11:06 AM---What do you mean "not an identifier"? Something that is
used to resolve to something else is an identifier by definition isn't
|
From:
|
<jimse@xxxxxxxxxx>
|
|
To:
|
"Higgins
(Trust Framework) Project developer discussions"
<higgins-dev@xxxxxxxxxxx>, <higgins-dev-bounces@xxxxxxxxxxx>
|
|
Date:
|
09/19/2008 09:11 AM
|
|
Subject:
|
Re: Strawman for
0..n entity ids [WAS: [higgins-dev] Myposition onEntityId]
|
What do you mean "not an identifier"? Something that is used to
resolve to something else is an identifier by definition isn't it?
>>> Anthony Nadalin <drsecure@xxxxxxxxxx> 09/18/08 10:58 PM
>>>
So to further qualify the EntityID is not an Identifier and not an attribute.
The entityID may be fully qualified that is may have a referwnce to the context
thus can resolve with out a contextID
-----------------
Sent from my BlackBerry Handheld.
----- Original Message -----
From: "Drummond Reed" [drummond.reed@xxxxxxxxxxxx]
Sent: 09/18/2008 09:11 PM MST
To: "'Higgins (Trust Framework) Project developer
discussions'" <higgins-dev@xxxxxxxxxxx>
Cc: <higgins-dev-bounces@xxxxxxxxxxx>
Subject: RE: Strawman for 0..n entity ids [WAS: [higgins-dev] My
position onEntityId]
Tony,
I think everyone’s on board that an EntityId represents a reference to exactly
one Entity in a context. Now its about cardinality, immutability, and type.
Regarding the first two, the current proposal is that if cardinality is 0..n,
the
IEntity.getEntityIds()
method will
return all of them (whether exposed as attributes or not), and the proposed
IEntity.getCanonicalEntityId()
method will
return only the single EntityId specified in that context to be: a) canonical,
b) immutable. If the context does not support either canonical immutable IDs,
the
IEntity.getCanonicalEntityId()
method will
return an error.
If
there’s agreement on that, then it’s just down to the types returned by those
methods and accepted by
IContext.getEntity()
.
=Drummond
From:
higgins-dev-bounces@xxxxxxxxxxx [mailto:higgins-dev-bounces@xxxxxxxxxxx]
On Behalf Of
Anthony Nadalin
Sent:
Thursday, September 18, 2008 10:34
AM
To:
Higgins (Trust Framework) Project
developer discussions
Cc:
Higgins (Trust Framework) Project
developer discussions; higgins-dev-bounces@xxxxxxxxxxx
Subject:
Re: Strawman for 0..n entity ids
[WAS: [higgins-dev] My position onEntityId]
Depends, no one is
stating what an EntityID represents, my view is it resolves to the Entity
within a context
Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122
"Markus
Sabadello" ---09/18/2008 12:30:56 PM---After the call, I had this idea:
|
From:
|
"Markus Sabadello"
<msabadello@xxxxxxxxxxxxx>
|
|
To:
|
"Higgins (Trust Framework) Project developer
discussions" <higgins-dev@xxxxxxxxxxx>
|
|
Date:
|
09/18/2008 12:30 PM
|
|
Subject:
|
Re: Strawman for 0..n entity ids [WAS: [higgins-dev]
My position on EntityId]
|
After the call, I had this idea:
1. Let's say IEntity.getEntityIds() returns an array of Objects (in Java:
Object[]). These Objects can either be Strings or IAttributeValues. If the
EntityId is not exposed as an attribute, it's just a String. If it is exposed
as an attribute, then it's an IAttributeValue.
2. IEntity.getCanonicalEntityId() returns a single Object. As before, if the
canonical EntityId is not exposed as an attribute, then the Object is a String.
Otherwise it's an IAttributeValue.
3. IContext.getEntity() has two overloaded versions. One that takes a String,
and one that takes an IAttributeValue.
So in total:
public Object[] IEntityId.getEntityIds(); // Objects can either be String or
IAttributeValue
public Object IEntity.getCanonicalEntityId(); // Object can either be String or
IAttributeValue
public IEntity IContext.getEntity(String);
public IEntity IContext.getEntity(IAttributeValue);
You don't invent something new for typing such as key-value pairs. You simply
use the existing IAttributeValue interface. IAttributeValue already includes
the type. And it can be complex, so you can do multi-part keys too.
All the IAttributeValue instances returned by IEntityId.getEntityIds() are
guaranteed to also show up somewhere on the IEntity in an IAttribute that is a
sub-attribute of higgins:synonym.
Would that work?
Markus
_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev
