There is a lot of redundancy here. Nesting depth should be infered
rather than specified if you ask me. superPart and subPart are already
just parts. Whether they are sub- or super parts can be inferred from
the containment structure. Suppose you have a superpart defined, a
camera say and you wrap it in a box, which you put in a sea container.
This would make the camera a sub part again. Therefore, part as a type
alone would just do.
How do sequence id's differ from rdf:seq types?
I think most of your ??id's really prevent expansion. If you want to do
this, use rdf containres instead.
Rikkert Koppes (mophor)
tianxama wrote:
>
>
> 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 around 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:
>
> [previusElement]:[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)
>
>
> _sebastián samaruga._
>
> ------------------------------------------------------------------------
> View this message in context: part-whole semantic relationship
> <
http://www.nabble.com/part-whole-semantic-relationship-tf3896550.html#a11046368>
> Sent from the w3.org - semantic-web mailing list archive
> <
http://www.nabble.com/w3.org---semantic-web-f11665.html> at Nabble.com.