OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xdi message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [xdi] XDI collection as attribute


On Mon, Sep 15, 2014 at 10:33 PM, Joseph Boyle <planetwork@josephboyle.net> wrote:

On Sep 15, 2014, at 10:13 PM, =Drummond Reed <drummond.reed@xdi.org> wrote:
 Note that the legal collection ABNF def seems weird to me as I interpret it as: [@]
Shouldn't there be an XDI name after the '@' ?
In which case, the definition should be:
legal-collection     = COLL             "@" xdi-name COLR
or something like that...

First, the legal context symbol is now +, not @. And second, the collection of entities that are purely identified as legal authorities is indeed just identified as [+]. The same is true for the collection of personal authorities, [=], and the collection of general authorities (things), [*].

The reason that no XDI name is allowed after these context symbols because, with authority context symbols, it is the symbols themselves that provide the type of the collection. Any XDI name after the symbol, e.g., +neustar, represents an authority instance, and by definition you can't have a collection of an instance, you can only have a collection of a set of members of the same type.

Here's another way to put it:
  • [=] is the collection of all personal authorities, i.e., entities of type "person"
  • [+] is the collection of all legal authorities,  i.e., entities of type "legal"
  • [*] is the collection of all general authorities, i.e., entities of type "general" (anything that has independent identity)
  • [$xxx] is the collection of all entities of type $xxx (defined by the XDI TC)
  • [#xxx] is the collection of all entities of type #xxx (defined by community consensus)
=Drummond 

One thing I’m not clear on here is, if you take the collection of personal authorities then index a single member from it, isn’t that the same as just specifying that personal authority? 
i.e. [=]!drummond vs. =drummond

The reason it's not exactly "the same" is that a member of a collection can be specified persistently, whereas by default a singleton is not persistent. So, to use your example (and assuming the string !drummond is actually assigned persistently):

=drummond      <== not persistent identifier
[=]!drummond   <== persistent identifier

But the need for a human-friendly non-persistent identifer to map to a persistent identifier is the whole rationale behind the XDI name/number pattern, so that's why the best practice will be the following XDI statement:

=drummond/$ref/[=]!drummond

=Drummond 
 



 On Sep 15, 2014, at 9:05 PM, =Drummond Reed <drummond.reed@xdi.org> wrote:

On Mon, Sep 15, 2014 at 6:06 PM, Le Van Gong, Hubert <Hubert.LeVanGong@neustar.biz> wrote:
Andy recently mentioned a bug in the XDI graph editor where collections are not represented using a diamond (attribute).

As I'm trying to determine the appropriate pattern for collections, I started reading the XDI ABNF and came up with some questions: what type of collections *must* be represented as an attribute?
For instance, should we represent an authority-collection (i.e. a person-collection or a legal-collection) as an attribute?

Hubert, there are only two types of collections: entity collections and attribute collections. Authorities (persons, legal, general) are just subtypes of entities. The existing ABNF may not make that clear enough, which leads us to...
 

Also, can someone confirm https://wiki.oasis-open.org/xdi/XdiAbnf is up to date?

It's not. I just put the most recent top-level ABNF at the top of the ABNF Discussion page. Hopefully this makes it much clearer that there are only entity collections and attribute collections. The former should be represented in the visual graph notation as filled circles; the latter as filled diamonds.

Thanks,

=Drummond  



--
Hubert A. Le Van Gong
Distinguished Engineer, Technology Foundry
San Jose, CA 95129
USA
--------------------------------------------------
email: hubert.levangong@neustar.biz
=hubert












[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]