http://www.simetris.com.ar

Part-Whole relationships. Part(s) describing surronding Whole.

The idea is to develop kind of data structure, with parts nested compounding a whole, and the inner parts of the structure knows, in reverse order, the containing tree of elements or structure surrounding it.

1: Definitions:

1. superPart: Part containing one or more parts.
2. part: Inside a superPart. Can contain subParts.
3. subPart: Inner unit inside a part.
4. NID: Nesting level ID (deep level entities are in a nested/tree structure)

   XML Example:

   <superPart NID="0"> <part NID="1"> <subPart NID="2"> </part> <!-- end NID 1 --> </superPart> <!-- end NID 0 -->
5. SeqID: Sequence ID (symbol sequencing and identification)

   Symbols sequencing and identification begins with first occurrence of a symbol in a structure, begining with 0, next symbol is tagged with 1. If next symbol appeared before, then the tag used before to identify it is used.

6. OccID: Occurrence ID

   Times element appeared in a sequence. First time same element occurs is 0, then 1, etc.

7. CID: Count ID (0, 1, 2, ...)

   Sequential count, begining with 0, of elements in determinate context (Nesting level, Sequence, etc.)

8. MvtID: Movement ID

   Signals start (S), inside (I), outside (O) or end (E) movement in a statement chain.

2. Example:

• Linear Form:

( superPart ( part ( ( superPart ) ( subPart ( part ( superPart ) ) ) ) ) NID: 0 1 2 2 3 4 SeqID: 0 1 0 2 1 0 OccID: 0 0 1 0 1 2 CID: 0 1 2 3 4 5 MvtID: S I O I O E

• XML Example:

<superPart NID="0"> <part NID="1"> <superPart NID="2"/> <subPart NID="2"> <part NID="3"> </superPart NID="4"> </part> </subPart> </part> </superPart>

• Another Example:

( head ( face ( ( head ) ( eyes ( face ( head ) ) ) ) ) NID: 0 1 2 2 3 4 SeqID: 0 1 0 2 1 0 OccID: 0 0 1 0 1 2 CID: 0 1 2 3 4 5 MvtID: S I O I O E

3. Composite IDs:

Combining CID, NID, SeqID and OccID, other IDs for easier retrieval of elements in statement can be achieved.

For example: NID + OccID = CID (Count of elements inside a specific nesting level)

( head ( face ( ( head ) ( eyes ( face ( head ) ) ) ) ) NID: 0 1 2 2 3 4 SeqID: 0 1 0 2 1 0 OccID: 0 0 1 0 1 2 CID: 0 1 2 3 4 5 OrderID: (0.0) (1.0) (2.0) (2.1) (3.0) (4.0)

4. Terms (Parts) Relationships and Roles:

In specific context of container part, another part plays a role or function in the context of container part. This is the semantics of the containment relationship, for example: John, inside a specific Team, is a player, more specificaly, a goalkeeper.

Parsing Example:

[previousElement]:[role/type] => [actualElement]:[role/type] => [nextElement]:[role/type]

5. Measurement units:

superUnit (eg.: Kilometer) unit (eg.: Meter) subUnit (eg.: Centimeter) Ratio: superUnit (1) => unit (1/n) => subUnit (1/n : n)

In a specific Context which contains Type(s) of entities, one Entity playing a specific Role (which are part of a Type definition) have one and only Identifier which determines its identity.

Context := [Type]* Type := [Role]* Role := [Entity]* Entity := [PlayerType] [ActorType] => (Identity) PlayerType := 'sender' | receiver ActorType := 'active' | 'pasive'

In a Dialog made of Statement(s) which are compound with Term(s), the Identity of a Player/Actor determines which Role the entity plays, determined with it's Type interactions/operations (Message*).

ENGLISH: Symbols sequencing/identification (stream): 1. Map sucesive symbols with numbers (starting at 0) 2. Symbol repeated, use the identifier used the first time the simbol appeared 3. After a repeated symbol, continue with id sequence if next symbol is new, use last otherwise 4. Apply recursively from contained symbol structures to containers (letter / word ; word / sentence) Example: String: ASDFAEIOUS Encoding: 0123045671 Part-Whole Composition Rules: ---------------------------- 1. Letter - Word = SINTAX 2. Word - Statement = GRAMMAR SINTAX- META-MODEL GRAMMAR - MODEL One level sintax is next level grammar. Symbol sequencing: 1. Rules by symbols order of occurence 2. ALPHABET Construction (META-MODEL) 3. DICTIONARY Construction (MODEL) SPANISH: Secuenciamiento Simbolos cadena/stream (Algoritmo): 1. Identificar simbolos con secuencia numérica (comenzando desde 0) 2. Al repetirse simbolo, repetir identificador previamente usado 3. Luego de repetirse simbolo, si el simbolo subsiguiente es nuevo, utilizar identificador siguiente en secuencia 4. Aplicar identificacion simbolos recursivamente (ej.: letras > palabras > oraciones) Ejemplo: Cadena: ASDFAEIOUS Encoding: 0123045671 Reglas de composición Parte-Todo: -------------------------------- 1. Letra - Palabra = SINTAXIS 2. Palabra - Oración = GRAMATICA SINTAXIS- META-MODELO GRAMATICA - MODELO Recursividad: La sintaxis de un nivel es la gramatica del nivel subsiguiente. Secuenciamiento de símbolos: 1. Reglas segun orden de aparicion simbolos. 2. Construccion de ALFABETO (META-MODELO) 3. Construccion de DICCIONARIO (MODELO)
View this message in context: identification semantics algorithm
Sent from the IETF - dix mailing list archive at Nabble.com.

_______________________________________________
dix mailing list
dix <at> ietf.org
https://www1.ietf.org/mailman/listinfo/dix

I'd be interested to hear if people think the ph-off plugin is useful or not.... If not why not?

If people think it's useful then I will happily extend it and make it more usable and I will put it into whatever open source project would like to house it.

I built it as a proof of concept that it _could_ be done... Now the question of _should_ it be done

http://chile.ootao.com/phoff/


Andy Dale
ooTao, Inc.

Phone: 877-213-7935
Fax: 877-213-7935

i-name: =Andy.Dale
http://xri.net/=andy.dale

***************************************************************************
If you don't have an i-name yet use this link to visit one of our partners and buy one:

  http://www.ezibroker.net/partners.html

***************************************************************************

Chris Drake <christopher <at> pobox.com> 10/18/2006 07:20 PM Please respond to Digital Identity Exchange <dix <at> ietf.org>

To Scott Kveton <scott <at> janrain.com> cc specs <at> openid.net, general <at> openid.net, Mike Glover <mpg4 <at> janrain.com>, Digital Identity Exchange <dix <at> ietf.org> Subject Re[2]: [dix] Re: Gathering requirements for in-browser OpenID support

Hi Scott,

All solutions for client-based MITM and phishing prevention can easily
be built on top of OpenID 2.0 if we adopt the OpenIDHTTPAuth proposal.

We can then leave these people to build their tools and protection
howsoever they like, safe in the knowledge that when it's *done*,
there will be a range of new plugins that will immediately work with
all OpenID 2.0 enabled sites - and best of all - it does not have to
hold up the OpenID 2.0 development in the meantime.

The only thing we need to give to these tools is a way to get the
login process started - that is - OpenIDHTTPAuth: the downloaded
plugin needs to be able to get an entry point for the OpenID CGI code
on the web site.

-----------

Here is a copy of my vote to include the above proposal, which
contains more info abut it too:


Hi,

Why's this proposal "depreciated" ?
( http://www.lifewiki.net/openid/OpenIDProposals )

I'm casting my vote here:

+1 to [PROPOSAL] bare response / bare request

Besides the listed uses, it also allows IdPs to layer privacy and
delegation easily on top of OpenID, as well as permitting cool future
features (like letting a user change something at their IdP, and have
that change be "pushed out" to all relevant RPs).

This is a small and simple to implement "hook" which I believe will be
the dominating bit of OpenID protocol use in future.

Alternatively - if we can standardize a way for the OpenIDHTTPAuth
proposed extension to discover the RP's OpenID "entry point" [so as to
reliably eliminate the "optional" first step proposed here
http://www.lifewiki.net/openid/OpenIDHTTPAuth ] - this is a good
working alterative way to accommodate the "bare response" part that we
need.

So...

+1 to OpenIDHTTPAuth - on the proviso RP's publish an endpoint URL
                      that's somehow available to scripts, plugins,
                      software agents that encounter OpenID login
                      pages.

                      Suggestion: (for OpenID-enabled login pages):-

 <link rel="openid.httpauth" href="http://my.rp.com/openid/blah.cgi">

-----------


Kind Regards,
Chris Drake


Thursday, October 19, 2006, 6:07:08 AM:

>> It is vulnerable to a man in the middle attack - the RP, instead of
>> redirecting to the IdP redirects to itself or some other site in
>> cahoots, then proxies the conversation between the user and the IdP
>> thereby compromising the users (global) credentials as they pass through.

SK> Right, we've known about this for quite some time unfortunately there hasn't
SK> be a particularly easy solution to it and I classify this as one of those
SK> "The Internet Sucks" problems.  I'm not saying we shouldn't/couldn't do
SK> anything about it I just think the right solution that mixes
SK> ease-of-implementation and user need hasn't been found yet.

>> There really needs to be user-agent support to avoid that - either
>> something CardSpace like, or browser plugin that only ever presents a
>> pre-authenticated user.

SK> I think we're headed in this direction.  However, we have to crawl before we
SK> can walk.  At least solving a big chunk of the use cases, getting some
SK> momentum behind the platform and solving a specific problem for users
SK> *today* is better than trying to build the perfect tool.  We can talk and
SK> talk on these lists but we really don't know how users are going to use this
SK> stuff (or abuse it for that matter) until its out there and working in the
SK> wild.

SK> I can't emphasize more the fact that with every passing day that we don't
SK> have OpenID v2.0 out the door, we're losing momentum from fixing specific
SK> user problems that are solved in the existing specification.

SK> - Scott

SK> _______________________________________________
SK> general mailing list
SK> general <at> openid.net
SK> http://openid.net/mailman/listinfo/general




_______________________________________________
dix mailing list
dix <at> ietf.org
https://www1.ietf.org/mailman/listinfo/dix

_______________________________________________
general mailing list
general <at> openid.net
http://openid.net/mailman/listinfo/general

_______________________________________________
dix mailing list
dix <at> ietf.org
https://www1.ietf.org/mailman/listinfo/dix

The point of a standards process is not what you put into the spec, its what you leave out.

Well said!

Joaquin





(And certainly true.  It has to be understood, of course.  Example: A bolt standard lists many combinations of diameter and thread pitch.  Many.  But a vanishingly small percentage of the possible combinations, almost all of which are left out of that standard. 

(In our business, a very effective way to ensure there is   n o t  interoperability is to provide many options.)

_______________________________________________
dix mailing list
dix <at> ietf.org
https://www1.ietf.org/mailman/listinfo/dix