by
Jerey R. Van Dyke
Submitted to the Department of
Electric al Engineering and Computer Sc ienc e
InPartial Fulllment of the Requirements
for the Degree of
Master of Engineering inElec tric al Engineering and Computer Sc ienc e
at the
Massachusetts Institute of Technology
June, 1995
c
MassachusettsInstituteof Technology, 1995
MassachusettsI nstituteof Technology
Laboratoryfor ComputerScience
Cambridge, Massachusetts02139
Agencyof theDepartmentof DefenseunderContract No. DABT63-92-C-0002.
by
Jerey R. Van Dyke
SubmittedtotheDepartmentof Electrical EngineeringandComputerScience
onMay30, 1995
inpartial fulllmentof therequirementsfor thedegreeof
Masterof EngineeringinElectrical EngineeringandComputer Science
Abstract
The notionof alink torepresent anexplicit relationshipor associationbetweenen-
titieshas beenutilizedbynumeroushypertextsystems toprovideavarietyof capa-
bilities, includingquotation, navigation, annotationandknowledgestructuring. The
link mechanismdescribedhereinprovides the abilityto relate entities ina global
informationinfrastructure, theI nformationMesh.
Theimplementationof alinkarchitectureshows thefeasibilityof aminimummech-
anismto provide a richset of relationshipexpressions as an element of a global
informationinfrastructure. Meshobjects are shownto require a composite object
mechanismandenhancements to their substructure interface. Meshlinkendpoints
allowthe descriptionof anobject, some aspect of anobject or acomponent of an
object. The resulting Meshlinkimplementationprovides rst-order linkinginan
extensibleandexiblearchitecture.
Thesis Sup ervisor: Dr. Karen R. Sollins
Title: ResearchScientist,Lab oratory for Computer Science
Special thanks to mythesis advisor, KarenSollins for her guidance andsupport.
Her vision of anI nformationmeshprovidedthe foundation for this eort. This
thesiswouldnothavebeenpossiblewithoutherpatientencouragementandocassional
prodding.
ThankstoBienvenidoVelez-RiveraandAlanBawdenfortheirdetailedexplanations
of theMeshkernel andMeshobjectsystem. Theireorts providedaspringboardto
theimplementationof thelinkmechanismdescribedinthis thesis.
ThankstoMitchCharityandChrisLefelhoczforreadingandcommentingonvarious
portions of this document.
Thanks to the members of the AdvancedNetworkArchitecture groupat the MI T
Laboratoryfor Computer Science. DaveClark, JohnWroclawski, JaneyHoe, Lewis
Girod, TimShepard, TimChien, Matt Condell, Robert Minnear, Lisa Trainor and
GarretWollmanall createdanatmosphereof motivationandsupport.
Finally, adeepfeltthank-youtomyparents, RogerandDianeVanDyke, andbrother,
Bryan, for theirloveandcare.
1 Introduc tion 9
1.1 Background : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 9
1.2 LinkArchitecture : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 10
1.3 Organization : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 10
2 RelatedWork 11
2.1 Memex: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 12
2.2 Xanadu : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 12
2.3 WorldWideWeb : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 14
2.4 Aquanet : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 16
2.5 Dexter : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 17
2.5.1 DexterStorageLayer : : : : : : : : : : : : : : : : : : : : : : : 18
2.5.2 DexterComponent I nformation : : : : : : : : : : : : : : : : : 18
2.5.3 DexterBaseComponents: : : : : : : : : : : : : : : : : : : : : 20
2.5.4 DexterStorageLayerFunctions : : : : : : : : : : : : : : : : : 22
2.5.5 DexterRuntimeLayer : : : : : : : : : : : : : : : : : : : : : : 23
2.5.6 DexterSystemI nvariants: : : : : : : : : : : : : : : : : : : : : 23
2.5.7 DexterLimitations : : : : : : : : : : : : : : : : : : : : : : : : 24
2.6 Observations: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 25
2.7 Summary : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 30
3 InformationMeshPro jec t 31
3.1 Goals: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 32
3.2 Constraints : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 32
3.3 I mplementationRequirements : : : : : : : : : : : : : : : : : : : : : : 34
3.4 I nformationMeshKernel : : : : : : : : : : : : : : : : : : : : : : : : : 35
3.5 I nformationMeshObjectSystem: : : : : : : : : : : : : : : : : : : : 35
3.5.1 MeshObjects : : : : : : : : : : : : : : : : : : : : : : : : : : : 36
3.5.2 Roles : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 36
3.5.3 I mplementations : : : : : : : : : : : : : : : : : : : : : : : : : 37
3.5.4 Actions : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 38
3.5.5 Parts : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 39
3.6 Summary : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 41
4.1 Naming : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 43
4.2 Typing: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 43
4.3 SubstructureI nterface : : : : : : : : : : : : : : : : : : : : : : : : : : 43
4.3.1 Selector Exposure : : : : : : : : : : : : : : : : : : : : : : : : : 44
4.3.2 ContentManipulation : : : : : : : : : : : : : : : : : : : : : : 46
4.3.3 SubstructureI nterfaceSummary: : : : : : : : : : : : : : : : : 47
4.4 Composites : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 48
4.4.1 Need : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 48
4.4.2 CompositeOptions : : : : : : : : : : : : : : : : : : : : : : : : 49
4.4.3 CompositeI mplementation: : : : : : : : : : : : : : : : : : : : 51
4.5 NodeExamples : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 52
4.5.1 DexterComponent Role : : : : : : : : : : : : : : : : : : : : : 52
4.5.2 AquanetNodeRole: : : : : : : : : : : : : : : : : : : : : : : : 53
4.5.3 AquanetStatementRole : : : : : : : : : : : : : : : : : : : : : 54
4.5.4 WorldWideWebHTMLDocumentRole : : : : : : : : : : : : 54
4.6 Summary : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 55
5 LinkArchitec ture 56
5.1 LinkAttributes : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 57
5.2 I mplementation : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 59
5.2.1 LinkUtilization: : : : : : : : : : : : : : : : : : : : : : : : : : 61
5.2.2 Relationshipdescription : : : : : : : : : : : : : : : : : : : : : 61
5.2.3 LinkI ndependence : : : : : : : : : : : : : : : : : : : : : : : : 62
5.2.4 Endpointcapabilities : : : : : : : : : : : : : : : : : : : : : : : 63
5.3 LinkExamples : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 65
5.3.1 NamedLink : : : : : : : : : : : : : : : : : : : : : : : : : : : : 65
5.3.2 OrderedLink : : : : : : : : : : : : : : : : : : : : : : : : : : : 66
5.3.3 Binarylink : : : : : : : : : : : : : : : : : : : : : : : : : : : : 67
5.3.4 LinkExampleSummary : : : : : : : : : : : : : : : : : : : : : 68
5.4 ExtendedExample : : : : : : : : : : : : : : : : : : : : : : : : : : : : 68
5.4.1 LCSEntityObjects: : : : : : : : : : : : : : : : : : : : : : : : 68
5.4.2 LCSEntityLinks : : : : : : : : : : : : : : : : : : : : : : : : : 69
5.4.3 Summary : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 71
5.5 Summary : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 71
6 Conc lusions 73
6.1 MeshLinks : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 73
6.2 Overall LinkingI ssues Addressed : : : : : : : : : : : : : : : : : : : : 74
6.3 OpenI ssues : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 75
7 Objec t-Role 77
8.1 VersioningOptions : : : : : : : : : : : : : : : : : : : : : : : : : : : : 79
8.2 VersioningI mplementation: : : : : : : : : : : : : : : : : : : : : : : : 80
9 LCSEntities and Semantic Links 81
Int roduct ion
This thesis examines alink mechanismfor describingobject relationships inalong
lived, global informationinfrastructure, theI nformationMesh. TheresultingMesh
linkimplementationprovides arichandexiblemechanismtorelateinformationin
the Mesh. Minimumlink, object andsystemcapabilities necessarytosupport such
capabilitiesaredescribed.
1.1 Background
The I nformationAge has createdaneedtomanipulate avast andever increasing
amount of data. As anexample, consider the I nternet: the trac relatedto infor-
mationmanipulationhas increasedtremendouslyinthe past fewyears [1]. Corre-
spondingtothisgrowthhasbeenanincreasingneedfortools tomanageinformation,
particularlyamechanismtoconnect andrelateknowledge.
Thenotionof connectingandrelatingknowledgehasbeenacompellingvision
since at least 1945 when Vannevar Bush suggestedthe implementationof a vast
knowledgebase[6]. These ideas havebeenfurther developedinhypertext systems,
suchas Xanadu[17], Aquanet[16] andWorldWideWeb[1], wherelinks areutilized
toexplicitlyrepresentarelationshiporassociationbetweenentities.
Hypertext links provideapowerful mechanismto relate information. I nthe
WorldWideWeb, links provideameans of informationnavigation. Xanaduutilizes
links for quotation, navigation, annotationandcommentary. Aquanet links areuti-
includes: navigation, quotation, annotationandknowledgerepresentation.
1.2 LinkArchitecture
Wedescribealinkmechanismtodescribeobjectrelationshipsinalonglived, global
informationinfrastructure. Our frameworkfor this eort is the I nformationMesh
Project: aneort toprovideaminimumset of universal commitmentsnecessaryto
providealong-livedglobal architecturefornetwork-basedinformationreference, ma-
nipulationandaccess. TheI nformationMeshObject Systemprovides Meshobjects
as thenodes of Meshlinks.
The overall goal is to describeaminimumlinkmechanismwhichprovides a
exibleandrich setof relationshipexpressions. Oneresultofthiseortisadescription
of theminimumsystem, nodeandlinkcapabilitiesnecessarytosupport Meshlinks.
1.3 Organization
The examinationof Meshlinks begins withadescriptionof several representative
hypertext systems inChapter 2. Systemrequirements, node capabilities andlink
characteristicsaredescribedinthissection. Thesecharacteristicsandtheconcluding
observationsareutilizedthroughouttheremainingchapters. Chapter 3describesthe
overall I nformationMesh, theMeshkernel andtheMeshObjectSystem. Thesystem
requirements of the I nformationMeshare describedand the capabilities of Mesh
objectsaredescribed. Chapter4examinesenhancementstotheMeshObjectSystem
tobetter utilizeMeshobjects as nodes of Meshlinks. Chapter 5describes aMesh
linkarchitectureanddemonstrates the exibilityof Meshlinks inseveral examples.
Chapter 6summarizetheoverall results andopenissues.
Notethatsecurityandprivacyissueswill notbeexaminedexceptwherethey
directlyaect overall linkdesign.
Relat ed Work
Thenotionof alinktorepresentanexplicitrelationshiporassociationbetweenentities
hasbeenutilizedbyhypertexttoprovideavarietyof capabilities,includingquotation,
navigation, inclusion, annotation and knowledge structuring. I nthis chapter, we
examine a varietyof hypertext systems: Memex, Xanadu, the WorldWide Web,
AquanetandtheDexter HypertextReferenceModel. Weexaminetheir useof links
anddescribehowtheyconfronthypertextissues, including:
1. Systemissues: Howdosystemcharacteristics enhanceor limitlinking?
minimumrequirements: basicsystemexpectations andrequirements
sc alability: mechanismstodeal withlargesystemissues
exibility: provisions for avarietyof hypertextnodes andlinks
sec urity: mechanismstopreventunauthorizedaccess
privac y: mechanismstoensureprivacy
2. Node attributes: Howdonodes support linking?
naming: identicationof nodes
typing: describingnodecharacteristics, semanticsandinvariants
substruc ture interfac e: exposingnodesubstructurefor linking
c omposites: combiningnodes
versioning: supportingnodechanges
linkutilization: overall useandcharacteristicsof alink
linkrelationships: abilityof linkto\talkabout" orexpressrelationships
betweenentities(includingother links)
linkindependenc e: abilitytoexistseparatefromnodes
endpoint c apabilities: what canlinksassociate?
Note that we focus onthe issues of scalability, node typing(as ameans of achiev-
ingexibilityamongother things), substructureinterface, endpoint capabilities and
overall linkutilization.
2.1 Memex
Thenotionof relatingavast domainof informationusingsomeassociatedstructure
was rst describedinVannevar Bush's visionof theMemex: \Adeviceinwhichan
individual stores his books, records, andcommunications, andwhichis mechanized
sothat it maybe consultedwithexceedingspeedandexibility. I t is anenlarged
intimatesupplementtohis memory[6]."
Bush'sworkwasdistinguishableforitsinclusionof anassociationmechanism:
the examinationof one iteminthesystemwouldsuggest another. Bushenvisioned
this mechanismworkingina fashionsimilar to the humanbrain: \Withone item
inits grasp, it snaps instantlyto the next that is suggestedbythe associationof
thoughts, inaccordance withsomeintricatewebof trails carriedbythe cells of the
brain[6]."
I t is largely agreedthat one outgrowthof Bush's visionwas hypertext, an
informationmanagement mechanisminwhichdatais storedinnodes connectedby
links.
2.2 Xanadu
TedNelson's XanaduProject [17] is aninuential examinationof alargehypertext
system. Xanaduutilizeslinkstoprovide\aconnectionbetweenpartsof textorother
overall goal of Xanaduis adistributedsystemof documentsconnectedbylinks.
Xanadudocumentsarethefundamental unitof storage. I ndeed, everythingin
theXanadusystemis adocument. Xanadudocuments\maycontaintext, graphics,
links... or anycombinationof these... [17]." Xanadudocuments providenoinfor-
mationhidingor abstractionlayer; theyexpose their entirestructureandcontents,
alongwithassociatedversioninginformation, inamanner allowingXanadulinks to
relateanyportionof adocument.
Xanadulinks arecomposedof \end-sets". Eachend-set indicates \spans" or
regions of text inXanadudocuments. Thus, Xanadusupports span-to-spanlinking
byallowingits links to relate regions of text. The typical Xanadulinkis a three
end-set structure: a\from-set" whichis anarbitrarycollectionof spans specifying
the source of alink, a\to-set" whichspecies the destinationof a link, anda set
specifyingthelinktypeor relationshipbeingexpressed.
Xanadulinks are containedinnodes: \Eachlink resides inone place, the
document that contains it. Links, just liketext, are owned. Everylinkis part of
a particular [document] and has anowner [17]." Links can relate other links by
connectingtothelinkportionof adocument.
Xanadulinks maintainassociations across document versions. \Essentially,
thelinkseizes apoint or span(or anyotherstructure) inthe[document] andholds
onto it. Links maybe refractivelyfollowedfromapoint or spaninone versionto
correspondingplacesinanyotherversion. Thusalinktooneversionof a[document]
is alinktoall versions[17]."Unfortunately, themechanismforalinkto\hold"onto
anodeacrossversionsisdependentonspeciccharactersremaininginvariant: \alink
is attached.... tospeciccharactersandsimplystays withthesecharacterswherever
theygo [17]." Note that this mechanismwill breakunder a varietyof conditions,
includingwordingchanges.
The greatest weakness of the Xanadusystemis its expectationof complete
availabilityof certainsysteminformation: \..everychangemustbeknownthroughout
the networkthe instant it happens [17]." I nparticular, Xanaduexpects that all
shouldbeabletoask, foragivendocument, `Whatconnectsherefromall fromother
documents?' {andbeshownall theseoutsideconnectionswithoutappreciabledelay
[17]."
I nsummary, Xanaduprovidesalinkmechanismtoallowreaderexplorationof
documents. Xanadudocumentsexposetheirentiresubstructureinamannerallowing
linkstorelateanyportionof adocument. Xanadulinksarecomposedof end-setsand
arecontainedinnodes. Xanadulinksmaintainassociationsacrossdocumentversions
andprovideamechanismfordeterminingall linkstoaparticularXanadudocument.
2.3 WorldWide Web
The WorldWide Web[1] is perhaps the best known, most widespreadandmost
successful exampleof adistributedhypertextsystem. TheWeballowsnavigationvia
linksacrosstheI nternetandbetweendocuments. Theincrediblegrowthandsuccess
of theWorldWideWebhasexhibitedthepowerof adistributedhypermediasystem
connectingvarious sites using\links".
The overall WorldWideWeb(WWW) paradigmis documentsconnectedby
links. WWWlinksexistintheWWWdocumentsthataretheirsources. EachWWW
linkspecies arelationshipbetweentwoentities: thedocument inwhichthelinkis
contained, andanidentieddestinationdocument. WWWdocumentsarespecied
inHTML[5].
WorldWideWebdocumentsareidentiedthroughtheuseof location(aUni-
versal ResourceLocationor URL[2]) rather thaninalocationindependent manner
suchasUniversal ResourceNames[21].
1
Thispreventstherelocationof Webobjects
{theycannot bemovedfromthelocationdescribedbytheirURL. Fortransmission
purposes, WWWdocumentcontentisspeciedusingI nternetMediaTypes[18].
WWWdocuments emphasizehumanbrowsing, anddonot explicitlyencode
semantics. There is, for instance, no mechanismto specify that aspecic page is
1
The latest draft of HTML 3.0 [19] proposes the addition of the (optional) URN attribute to
describe theuniversal resource nameforanHTMLdocument.
fromtheURLassociatedwiththeWebpage. I narelatedmanner, HTMLprovides
minimummechanisms toassist browsers inpresentingnewmarkupstructures. I f a
particularHTMLmarkupisencounteredforwhichtheWebbrowserlacksknowledge,
thereislittleornofall-back; theWebbrowsercaneitherignorethemarkupordisplay
theASCII text representation. I nshort, thereis nostandardwaytoclassifyaWeb
document; anymeaningmustbedeterminedfromtheaccompanyingHTMLwhich,
at leastpresently, providesminimumcapabilitiesforsuchdescriptions.
2
Documentsexposeinternal contentforlinkingthroughtheuseof ananchor. I n
theWWW, ananchorspeciedsectionof theWWWdocumentisthesourceand/or
destinationof aWWWlink. Ananchor HREFattribute species the beginningof
alink. AnanchorNAMEattributespecies anidentier whosereferenceallowsthe
anchortobethetargetof alink. Anchorscannested, butcannotoverlaponeanother.
Anchorsarelimitedinthattheyaremerelyarbitraryportionsof document{thereis
nodocumenttypingmechanismwhichwouldallowassociatinganchorswithacertain
documenttype(suchastheaforementioned\homepage")ordocumentsubstructure.
3
I nshort, WWWanchorslacktheabilitytobeassociatedinsomeformal mannerwith
ageneralizedstructure, suchas aparticular documenttype.
WWWlinks are one-way, two-endedanddocument-based. Links always de-
scribe arelationshipbetweenexactlytwodocuments; there are no mechanisms to
relatemorethantwoentities. Links mustbecontainedinoneof thetwodocuments
theyassociate. TheWebprovidesamechanismtoallowserverstoaddlinkstodocu-
ments\bythosewhodonot havetherighttoalterthebodyof adocument[4]", but
serversarenotrequiredtoprovidethisfunctionality. Therearenomechanismstolink
twodocumentsif theservers of bothdocuments refusetheadditional links. WWW
links arenot rst class andthereforecannot exist independentlyof thedocuments
theylink.
2
The latest draft of HTML3.0[19] suggests the utilizationof a\ROLE"attribute whichis a
listingof SGMLnametokens\thatdene the rolethisdocumentplays[19]."
3
Thelatestdraftof HTML3.0proposes theadditionof anIDmechanismtoassociatedocument
elementswithanchors. Further,thedraftsuggests the additionof aCLASSmechanismtosubclass
HTMLelements.
useof WWWlinkrelationshipnames isextremelylimited. This is particularlyfrus-
tratingbecause earlyWWWdocumentation[3] suggestedseveral linknames to de-
scribe\relationships betweendocuments"and\relationships about subjectsof docu-
ments". ThecurrentHTML2.0draft[4] hasminimal discussionof linkrelationships,
merelystating: \Relationshipnames andtheir semantics will be registeredbythe
W3Consortium. Thedefault valueisvoid." Thelatestdraft of HTML3.0[19] sug-
gests anexpandeduseof linkrelationships toprovidespecicnavigationbuttons or
equivalentmechanisms.
WWWlinkscanbecome\dangling"links. Forexample, areferencedWWW
documentmayrenameor removethenecessaryanchor. Worse, thereferenceddoc-
umentmaymoveor beremovedinamanner that \breaks"its prior URL. Thereis
nomechanismfor areferencedWWWdocument toexposeinvariants inanchors to
allowalinktoensureit is lesslikelytobecome\dangling".
I nsummary, the WWWallows navigationvialinks across the I nternet and
betweendocuments. WWWdocuments are identiedbylocation, emphasize hu-
manbrowsingandexpose internal content for linkingthroughthe use of anchors.
WWWlinks are one-way, two-ended, document-basedandcanbecome \dangling"
links. WWWlinktypesarespeciedbyarelationshipname.
2.4 Aquanet
Aquanet [16] is a hypertext knowledgestructuring tool designedto allowusers to
graphicallyrepresent informationandexploreitsstructure. Aquanetallowsusers to
interpretandorganizeideasusingAquanet'slinkingstructuretoconnectandexpress
ideas. Overall, Aquanet provides anexaminationof utilizinghypertext facilities in
therealmof knowledgerepresentation.
Aquanetobjects (bothnodes andlinks)aretyped, structuredframe-likeenti-
ties. EveryAquanet object is aninstanceof sometype. Atype'sdenitionspecies
slots, type(s)of objectsthatcanll eachslot, andthegraphical appearanceof theob-
objects of agiventypeincludenot onlytheslots denedbytheir typebut alsothe
slots that theyinherit fromtheir supertype(s) [16]." The inheritance rules of the
Aquanet type hierarchyare takendirectlyfromthe CommonLispObject System
specication[14].
Aquanetnodesandlinksaredistinguishedbytheiruseof slots. Nodeslotval-
uesareanamedsetof contentsrestrictedtoprimitivedatatypessuchastext, images,
numbers, strings, etc. Linkslot valuesmaybeprimitivedatatypes or other Aquanet
objects. Aquanet linkscanbeviewedas containingnamedandtypedendpoints.
Aquanetlinksareutilizedaspartof thedenition, developmentanddisplayof
\knowledgestructures".
4
Asanexample, an\Argumentrelation"is expressedas an
Aquanetlinkcontainingthreeslots: theConclusion, theGrounds andtheRationale.
Eachslot canbelledbyeithera\Statementnode"(anAquanet object containing
atextslot) or another Argumentrelation.
I nsummary, Aquanet utilizes atypehierarchyto describe object types and
multi-endedlinkstoprovideenhancedknowledgestructuringcapabilities.
2.5 Dexter
TheDexterHypertextReferenceModel providesanabstract model of hypertextsys-
temswhichdescribestheentitiesandmechanismswhichallowuserstocreate, manip-
ulateandexaminehypertext[12]. Theoverallgoal of Dexteristwo-fold. First,Dexter
formalizessomeof thehypertextnotions wehaveexamined, thusprovidingavocab-
ularythat canbe utilizedto describe aparticular hypertext system's functionality
andcharacteristics. Second, Dexter provides amodel of the importantabstractions
foundinawidevarietyof hypertextsystems, andthusnecessarytoincorporateinto
aexiblelinkmechanism.
I nthis section, weexamineDexter inconsiderabledetail. First, weexamine
4
The term knowledge structure refers to \..aninterconnected networkof information-bearing
nodes that areusedtoreprese nt theprimitiveobjects andtheir interconnectioninsomedomainof
discourse [16]."
separatelyexaminethecompositeinformationandbasecomponents whichtogether
construct all Dexter components. Additionally, wedescribe Dexter's storage layer
functions andruntimelayer. Finally, wedescribe Dexter invariants andsummarize
Dexterlimitations.
2.5. 1 DexterStorageLayer
The Dexter storage layer models the node/linknetworkstructure of hypertext. I t
is composedof a database of data-containing components interconnectedby rela-
tional links. Thestoragelayerfocusesonthemechanismsbywhichlinkandnon-link
componentsare`glued-together' toformhypertextnetworks.
The fundamental entityinthe storage layer is a component. Components
are what aretypicallythought of as `nodes' and`links' inahypertextsystem. The
storage layer of Dexter doesn't attempt tomodel the overall content andstructure
of components, but treats componentsas largelygenericcontainersof data. Despite
theoverall indierencetocomponentcontents, Dexterrequiresthateachcomponent
exposecomponentinformationandutilizeabasecomponent. Componentinformation
is describedinSection2.5.2andbasecomponentsaredescribedinSection2.5.3.
Alsoassociatedwiththe storage layer are twofunctions: aresolverfunction
andanaccessorfunction. Together theyare jointlyresponsible for retrievingcom-
ponents fromthe storage layer basedonthespecications of thecomponents. The
exact natureof thesemechanismsisdescribedinSection2.5.4.
2. 5. 2 DexterComponentInformation
Dexter requires that eachcomponent inthe storage layer expose component infor-
mation. Componentinformationdescribes certainproperties of thecomponent and
provides afundamental interfacetothecomponent.
Component informationincludes: unique identication, anchoring, presenta-
tionspecicationandattribute/valuepairs.
EachDextercomponenthas auniqueidentier(UI D)assumedtobe\uniquely
assignedtocomponentsacross theentireuniverseof discourse[12]."
Anchors
EachDextercomponentcontainsasequenceof anchorsthatindexintothecom-
ponent. Dexteranchorsprovideanindirectaddressingmechanismforspecifying
the internal structureof acomponent inamanner whichdoes not dependon
knowledgeof theinternal structureof adocument. Dexterlinksutilizeanchors
torelatecomponentsubstructure.
ADexter anchor consists of two parts: ananchorid, andananchorvalue.
The anchorid is anidentier whichuniquelyidenties ananchor withinthe
scopeof thecomponentitoccupies. Theanchorvalueisanarbitraryvaluethat
species somelocation, region, itemor substructurewithinacomponent. The
anchor valueis interpretableonlybythe applications responsiblefor handling
thecontent/structureof thecomponent. Dexteranchors canoverlap.
AnchorsallowDextertosupport linkingacross componentversions. Asacom-
ponent changesovertime, theanchor valuechanges toreectmodications to
theinternalstructureof thecomponent, \[t]heanchorid, however, remainscon-
stant, providingaxedreferent that canbe usedto specifyagivenstructure
withinacomponent[12]."
PresentationSpecication
Thepresentationspecicationisaprimitivevaluecontaininginformationabout
howthenodecontentsshouldbepresentedtotheuser. Presentationspecica-
tionsaredescribedinmoredetail inSection2.5.5.
Attribute-ValuePairs
Finally, Dexter components provide the abilityto set andretrieve arbitrary
attribute/value pairs. The attribute/value pairs can\be usedto attachany
beattachedtoacomponentusingmultiple`keyword' attributes [12]."
Note that Dexter does not provide a formal component type model. Some
componentattributes canbedeterminedbyexaminingattribute-valuepairs, but no
formal type systemmechanismis specied. Some descriptions of Dexter suggest
modelingacomponenttypesystemby\addingtoeachcomponenta`type' attribute
withanappropriatetypespecicationas its value[12]."
2. 5. 3 DexterBaseComponents
Dexter componentsarecomposedof abasecomponenttogether withthecomponent
informationdescribedinSection2.5.2. The basecomponentsintheDexter storage
layerare: atomiccomponents, compositecomponentsandlinks.
Atomic Components
Atomiccomponentsarethenest grainmembers of thestorage layer. Atomiccom-
ponents arelargelyopaqueobjects; thestoragelayerknowslittleabout thecontents
of atomic components or the \within-component" layer. Atomiccomponents may
containchunksof text, graphics, images, etc.
Composite Components
Composite components are constructedout of other components. The composite
relationshipis restrictedto adirectedacyclicgraph(DAG) of basecomponents; no
component maycontainitself either directlyor indirectlyandcomposites are only
composedof basecomponents.
Finally, it isnot clearhowthelinkingmechanismis providedwithcomposite
components. Dexter does not describe howanchors are relatedto composites; no
mentionis madeof howanchorsshouldrefer tobasecomponentsinacomposite.
LinksassociateDextercomponentsbydescribingarelationshipbetweencomponents.
Dexter links describe their relationshipusing asequence of twoor more speciers.
Eachspecier describes the entities being related, the directionof the relationship
andthe presentationmechanismbywhichto displaythe entities. Dexter links are
rst classandDexterlinks canrelateDexter links.
Dexterutilizes composites tomodel hypertextsystemsinwhichlinksarenot
independent, but areembeddedinnodes. Anexampleof thisapplicationof compos-
ites is theKMS[20] hypertext system: \All links inKMSare embeddedwithinthe
frame (component) containingthe source anchor. Since links are also components
intheDexter model, it maybearguedthat aframeinKMSis actuallyacomposite
component[15]."
Dexterutilizesspecierstodescribethelinkrelationship. Thespecierstruc-
turecontains: acomponentspecication, ananchorid, adirectionandapresentation
specication.
componentspecicationprovidesadescriptionof thecomponent beinglinked.
This descriptioncanbeutilizedbythestorage layer'sresolverfunctiontopro-
duceaset of componentUI Dsmatchingthedescription.
anchoridspeciestheanchor tobeutilizedintheresolvedcomponent.
directionencodes linkendpointsasFROM, TO, BI DI RECTorNONE. Dexter
allowsduplicatedirectionvalues withtheconstraint that at least onespecier
haveadirectionof TOor BI DI RECT.
Therearemanydierentnotionsof directionality. GrnbaekandTrigg[11] have
identiedatleastthreetypes: semanticdirection, creationdirectionandtraver-
sal direction. Dexterdoesexplicitlyutilizeaparticularnotionof directionality;
Dexterprovidesdirectionalityas amechanismtosupportdirectionalityseman-
tics inexistinghypertext systems withDexter's two-waylinks. For example,
Dexter models aone-waylinksystem(suchas HyperCard[10]) byusingtwo-
endhavingadirectionvalueof TO. 5
presentationspecicationis aprimitivevaluethat helps the runtimelayer de-
termine howthe associated descriptor shouldbe presentedto the user. We
will discuss the presentationspecicationinmore detail inthe discussionof
Run-TimeissuesinSection2.5.5.
Note that for a particular specier, the component specicationallows the
returnof asetof UI Ds, buttheotheraspectsof aspecierstructurearesinglevalued
andstaticallydetermined. Thisimpliesthatall componentsresolvablefromapartic-
ular componentspecicationmustsupport thesameanchor idandpresentation.
6
2. 5. 4 DexterStorageLayerFunctions
As wehavepreviouslymentioned, the storage layer utilizes aresolver andaccessor
functiontoretrievecomponents.
AccessorFunction
Theaccessor functionof thehypertext is responsiblefor \accessing"acompo-
nent, givenits UI D. That is theaccessor functionis responsiblefor retrieving
thecomponentcorrespondingtoagivenUI D.
DexterResolverFunction
The resolver functionmust be able to produce all possible validcomponent
UI Ds for anygivendescriptionor \componentspecication".
Dexter remains silentonthemechanismandimplementationof resolver func-
tions, includingthedomainandsyntaxof specications, butjustiestheirneed:
5
HyperCardlinkscanonlybe traversedfromsource todestination. \Thisisbecause HyperCard
links are implementedas `GO' statements inascript inthe link's source component. This also
meansthat linkscannot normallybeseenfromtheir destinationcards [11]."
6
In[25], Penzo, SolaandVitali propose modicationstoDexter tosupport dynamicdetermina-
tionof anchorids.
strictive. Rather, when[thecomponentspecicationdescribedinaspecier of
a] linkisfollowed, thespecicationmustbe`resolved', if possible, toaUI D(or
set of UI Ds)whichthencanbeusedtoaccessthecorrect component(s)."
2. 5. 5 DexterRuntimeLayer
The runtimelayer species the tools for auser to access, viewandmanipulatethe
node/linknetworkstructure. Theruntimelayertools cantreat componentsasmore
thangenericcontainersof data{utilizingtheactual contents.
Theruntimelayerutilizesthepresentationspecicationvaluesassociatedwith
componentsandlinkspecierstodeterminehowacomponentshouldbepresentedto
anenduser. \Thus, thewayinwhichacomponentispresentedtotheuser canbea
functionnotonlyof thespecichypertexttool thatisdoingthepresentation(i.e., the
specicrun-timelayer), butcanalsobeapropertyof thecomponentitself and/or of
theaccess path(link) takentothatcomponent[12]." Thus, theruntimelayeris the
layerat whichdynamicmechanismis determined, whilethestorage andcomponent
level mechanismspreviouslydescribedimplementhypertextas anessentiallypassive
datastructure.
2. 5. 6 DexterSystemInvariants
TheDexter model requires that several invariantsbemaintainedat all times bythe
hypertextsystem. Theseinvariants areexpectedtobe implementedinafashionto
ensuretheyaremaintainedwhencreating, modifyingor utilizingcomponents.
AmongtheDexterinvariantsare:
Link speciers must have at least one specier withthe directionof TOor
BI DI RECT. Thus, all linksmustpoint tosomecomponent.
TheaccessorfunctionsmustbeaninvertiblemappingfromUI Dstocomponents.
This implies that everycomponentmusthaveexactlyoneUI D.
pliesthatanypossiblecomponentdescriptionsmustberesolvabletoacomplete
set of componentUI Ds.
Compositecomponentsmustcontainnocyclesinthecomponent/subcomponent
relationship. Thus, nocomponentmaybeasubcomponent (directlyor transi-
tively)of itself.
Links maynot be`dangling'. The speciers of alinkmustalways resolveto a
setof componentscontainingtheassociatedanchorid. Anycomponentchanges
mustbereectedinlinks. Thus, anyDexter-basedhypertextsystemmusten-
surethat anycomponent changes result intheimmediateupdateandmodi-
cationof links toreectthechanges.
2. 5. 7 DexterLimitations
Dexteris limitedinseveral respects.
1. The Dexter systeminvariants ignore large distributedsystemissues, suchas
unavailability. For instance, the needto prevent `dangling links' ignores the
dicultyof providingandmaintainingsuchinformationacross a widelydis-
tributedsystem.
2. Dexterdoesnotexplicitlyprovideacomponenttypingmechanism. Somecom-
ponent attributes canbe determinedfromexaminationof the component in-
formationsuchas attribute-value pairs, but thereis noformal mechanismto
associateacomponenttypewithinvariantssuchas theanchorsavailable.
3. Dexteranchorsarelittlemorethanarbitraryidentiersof values. Dexter pro-
vides no mechanismto associate formallya particular set of anchors witha
particular typeof component. Nor is thereanywaytospecifycertaincontent
characteristics withparticular anchor ids. Finally, Dexter anchors donot pro-
videanycontext; Dexter assumes that all component anchors arevalidat all
times.
tion{thecomponentspecicationportionpermitsthedynamicdetermination
of a set of UI Ds, but the other specier portions are single valuedandstati-
callydetermined. Thus, all componentsresolvablefromaparticularcomponent
specicationmustsupportthesameanchoridandpresentation.
5. Dexterprovidesonlylimited motivationforlinkdirectionality. Dexterdirection-
alityismotivatedasamechanismtosupportdirectionalitysemanticsinexisting
hypermediasystems, but, asshownbyGrnbackandTrigg, itisinsucient\to
model thewayspeopleinterpretlinkdirectioninpractice[11]."
2.6 Observations
Several observations about theoverall characteristicsof thepreviouslydescribedhy-
pertext systems:
1. Scalabilityis oftenignored.
Dexter andXanadurequirelinks andother systeminformationbe completely
available{anunrealisticexpectationfordistributedsystems. TheWorldWide
Web'sassociationof documentswithlocationlimitstheabilitytorelocatedoc-
uments.
2. Noconsensus ontypingmechanismstoassociatecharacteristicsandinvariants
withnodes andlinks. Typingmechanisms include:
notyping
Xanaduprovidesnonodetypes. Thelackof anodetypemeansthatthere
isnomechanismtoassociateattributestightlywithadocument.
singlevalue
TheWWWutilizesasinglevalue, arelationname, toexpresslinktypes.
Singlevaluetypesareusuallyselectedfromastandardsetsuppliedbythe
shipnames areregisteredbytheW3Consortium. Amechanismtoallow
individual userstodesignateanewvalueasatypeissometimesprovided,
but suchamechanismisusuallylimited.
Singlevaluetypesgenerallydonotallowpartial knowledgeof aparticular
type: eitheratypeis recognizedor it isnot. All singlevaluerelationships
mustbe madeexplicit bysomeentity; therearenoimpliedrelationships
betweenvalues.
hierarchical types
Aquanet nodes andlinks are instances of a speciedtype ina type hi-
erarchy. Hierarchical types provideamechanismtorelateanewtypeto
prior typesthroughtheplacementof thenewtypeintheinheritancetree.
Careful choicesof inheritanceallowanewtypetoreveal detailsabout its
characteristicsandcapabilities.
Onelimitationof hierarchical types is thedicultyinselectingaposition
inthehierarchytoaddnewtypes. I tissometimesdesirabletoplaceanew
typeat multiplelocations inhierarchy.
attribute-valuepairs
TheWorldWideWebandDexter provideanattribute-valuemechanism
fornodesandlinks. Attribute-valuepairs, whilenotstrictlyatypingmech-
anism, utilizeaset of attributestodescribenodeandlinkcharacteristics.
These characteristics are expressedbyassociating attribute names with
values.
As withsingular values, attributevaluepairs must be limitedto astan-
dardset. Auser canrelate a new\type"to prior types byappending
a newattribute to existing, well understoodattributes. Unfortunately,
most attribute-valuesystems donot provideamechanismtoprevent at-
tribute namingconicts. Further, individual attribute values suer the
samerecognitionproblemsas singlevalue(eitherrecognizedornot recog-
nized).
posure of document invariants. Single value mechanisms limit the expressive
capabilities of individual users. Hierarchical types limit type associations by
requiringa single positioninthe hierarchy. Attribute-value pairs have nam-
ingconictswhichlimitexpressivecapability. Theselimitations emphasizethe
needfor anextensibletypingmechanism.
3. Noconsensus onnode substructure exposure. Substructure exposure mecha-
nismsinclude:
nosubstructureexposure
Theobject is completelyopaque withnogeneralizablemechanisms toal-
lowlinkassociations. Noexaminedhypertextprovidedsuchsubstructure
exposure, but Aquanetonlyallowslinkingatthegranularityof individual
nodes. Alackof substructure exposure limits linkingcapability{ node
substructurecannot belinked.
entirecontentexposure
Nodecontentsarecompletelyexposedforlinking{butnotnecessarilywith
anycontentinvariants. Xanadunodesexposetheircompletestructurewith
noinvariants, witharesultinglinkingschemawhichdepends oncharacter
matching.
arbitraryanchors
Anchorsprovideamechanismbywhichlinkscan\reachinside"nodesand
\hold"ontonodesubstructure. WWWandDexternodesprovidearbitrar-
ilynamed\anchors"withnomechanismtospecifycontextor semantics.
Anchors provideinvariants, allowingnode contents to change while pro-
vidingaconsistentinterface. However, thelackof amechanismtospecify
anchor characteristicslimitsanchors tobeutilizedas arbitraryidentiers
of substructureregions.
syntacticanchors
is asuggestedadditiontoHTMLinthecurrentversion3.0draft [19]. I t
isnot clearif thepresentproposal allows for expressingsemanticcontent.
Alink's abilityto referencenode structureis limitedbythemechanisms pro-
videdbythenodesbeinglinked. I f nodesexposesubstructureinvariants, either
throughanchors or someother mechanism, thenalinkcan\hold"onto those
invariantsacross mutations. I t isunclear whichmechanismisthebestmethod
bywhichnodes shouldexposetheircontentsfor linking. Limitedanchor capa-
bilitiessuggest theneedfor moreformal structures.
4. Noconsensus onlinkendpoint capabilities. Linkendpoint capabilitiesinclude:
nosubstructurelinking
Nosubstructurelinkingimpliesthat linkendpoints connect at the gran-
ularityof nodes. As anexample, Aquanet links relateentireobjects, not
object substructure. Alackof substructure linkinglimits the power of
links toexpressrelationships betweennodes whichinvolvesubstructure.
substructurelinking
The WWWandDexter links utilize \anchors" for substructure linking.
TheWWWlinks usestaticallyspeciedlinkendpoints. Dexter provides
dynamic determinationof link endpoints through the use of speciers.
Substructurelinkingis limitedbytheexposureof nodesubstructures.
computedlinking
Links mayutilizecomputationsonnodesfor linking. Suchapproachesare
useful whentheitemtobelinkedisnot exposedbythenodeasananchor
or equivalentinvariantstructure. Oneexampleis Xanadu's mechanismof
linkingtonodesthroughtheuseof acomputationinvolvinginvariantchar-
acters {presumablysomeformof charactermatching. Equivalentlinking
schemas might utilize character osets or wordcountingto specifythe
endpointof alink. Theproblemwithcomputationsis thattheyfail inthe
not exposecharacteristicsor invariantsthroughsometypingmechanism.
Clearly, apowerful linkendpointmechanismwouldutilizeexposedsubstructure
invariants, yetprovidethecapabilitytoutilizecomputationsonnodes.
5. Noconsensus onminimumlinkcharacteristicsandcapabilities, including:
multi-dimensional links
Xanadu, Aquanet andDexter links canberelatemorethantwoentities.
TheWWWrestrictslinkstotwo-endedstructures.
directionality
Xanaduexpects a distinguishable FROM-SETandTO-SET. Dexter, in
contrast, marksindividual endpointsaseitherTO, FROM, BI DI RECTor
NONE. WWWhasimplicitdirectionalityfromthemarkupinadocument.
Aquanet does not havelinkdirectionality.
presentations
Dexterlinksprovidea\presentationspecier"withboththelinkandeach
endpoint. Aquanetutilizesagraphical appearancespecicationassociated
withnodeandlinktypestodesignatethepresentationof Aquanetobjects.
TheWWWutilizesHTMLasamarkuplanguagetodescribepresentations.
independentlinks
AquanetandDexterlinksareindependenthypertextentities. TheWWW
andXanadurequirethat linksbeembeddedinahypertextnode.
namedendpoints
All Aquanet endpoints are named. Some WWWandXanadulinks are
named. Dexter does not nameits linkspeciers.
Clearly, hypertextsystemsemployavarietyof dierentlinkcharacteristics. I t
is not clearwhichmechanisms areabsolutelynecessary.
andimplementationof aglobal informationinfrastructurelinkingmechanism: I nfor-
mationMeshLinks.
2.7 Summary
I nthis examinationof nodes, links andsystemattributes, we have describedhow
nodeattributessupport linking, howlinkrelationshipsareexposedtotheoverall sys-
tem, andhowparticular systemrequirementsimpactlinkcapabilities. I nparticular,
weobservedtheoverall lackof consensus ontheissuesof nodeandlinktyping, sub-
structure exposure, endpoint capabilityandoverall linkcharacteristics. Associated
withtheseobservations, wenotedtheneedforascalablehypertextsystemproviding
extensibletypingandaformal mechanismfor substructure exposure. Wedescribed
theneedtodetermineminimumlinkcapabilities. Further, wediscussedtheneedfora
powerful endpointmechanismutilizingexposedsubstructureinvariantsyetproviding
thecapacitytoutilizecomputationsonnodes.
I nfor mat i on Mes h Pr oject
The I nformationMeshProject represents a newparadigmfor networkedsystems
whichsupports the visionof widespreadinformationsharing andstructuring. The
central ideaof the I nformationMeshis that the networkexists primarilyto main-
tainrelationshipsamongnodes of information. Thefundamental activityof network
applicationsthus becomesconstructing, manipulatingandusingtheserelationships.
The implementationof this vision has beencenteredaroundthe notion of
supportingnetworkedMeshobjectsinterconnectedbylinks. The overall goal is to
understand the minimumset of informationservices necessary to support sucha
model andpushthemintothe networkinginfrastructure. The result shouldshield
applicationsfromhavingtomanipulatetransport level protocols.
Workfor this projecthas resultedinthecreationof aMeshkernel andMesh
objectsystem. TheMeshkernel provides informationnaming, discoveryandreloca-
tion. TheMeshobjectsystemutilizesthenotionof rolestoprovideexible, evolvable
objectsintheMesh. Rolesprovideanextensivetypingmechanismtodescribeobject
behavior(actions)andobjectstructure(parts). Meshlinks, amechanismtoexpress
relationshipsbetweenMeshobjects, aredescribedinChapter 5.
I nthischapter, wedescribetheoverall goals, constraintsandrequirementsfor
theI nformationMesh. WedescribetheMeshkernel andMeshobject system.
The I nformationAge has createdaneedtomanipulate avast andever increasing
amount of data. As anexample, consider the I nternet: thetracrelatedto infor-
mationmanipulationhas increasedtremendouslythepast fewyears[1]. I ndeed, the
explosive growthandsuccess of the WorldWide Web, Gopher andother I nternet
informationnavigators, combinedwiththerecentcommercializationof theI nternet,
canonlyleadto increasinggrowth. Corresponding to this growthhas beenanin-
creasingawarenessthatcurrentinformationmanipulationtools areinadequatetoan
alreadyvast informationbase.
The I nformationMeshattempts toaddress theproblemof inadequateinfor-
mationmanagementtools byprovidinganetworkingsubstrateinwhichinformation
manipulationis anattribute of the network, not the individual application. The
hope is that \muchas traditional applications utilize adatabase system, theMesh
will becometheprimitiveabstractionaroundwhichapplications arebuilt[8]."
The overall visionof theI nformationMeshProject is toprovidealong-lived
global architecturefor networked-basedinformationreference, manipulationandac-
cess as aubiquitous substratefor distributedandnetworkapplications anddomain-
specic knowledge bases. Theimplementationof this visionis expectedto contain
objectsinterconnectedbyrelationshipsor linksinauniversal andlong-livedinforma-
tionbase.
3.2 Constraints
The constraints tomeet thevisionof aMeshof objects canbe summarizedas uni-
versality, ubiquity, heterogeneity, longevity, evolvabilityandresiliency.
Universality
TheI nformationMeshvisionof \asinglemodel for informationidentication,
locationandaccessasasubstratefordistributedsystemandapplications[22]."
encingobjectsanddosoinahighlyscalablemanner.
Ubiquity
TheI nformationMeshmustsupport \network-basedapplicationsaccessingin-
formationthat is distributedbothphysicallythroughthenet andadministra-
tivelyacrossregions of dieringmanagementpolicies[22]."
Heterogeneity
TheI nformationMeshshouldbepreparedfor changes incommunicationsme-
dia, transport protocols andnetworked-applications. I t mustsupport abroad
set of protocols andapplications, boththoseimplementedandlikelytobeim-
plemented.
Longevity
The Meshmust support long-livedinformation; it cannot requirethat infor-
mationbereformattedanditmustsupportbotholdandnewformats. Objects
mustbeconstructedinamanner that realizes that thesameobject mayexist
for hundredsof years.
Evolvability
The Meshmust be ableto providefor changingsemantics, syntax, structures
andutilizationof information. TheMeshmust beabletoprovidecapabilities
for informationto be utilizedinnewandunexpectedforms. The Meshmust
support newnetworkservices. I t mustprovidefor informationmovingbothin
physical locationandownership.
Meshobjects mustbemadeavailableinamannerthat realizesthat theymay
change location, ownershipand behavior. Thus, we must ensure that Mesh
mechanismsdonot expectanobjecttoremainconstant.
Resiliency
exist inmanysituations of unreliabilitywhere it will be unable to locate or
accessinformation. Thus, theMeshmustbedesignedfromthestarttoprovide
mechanismstodeal withunavailability.
3.3 ImplementationRequirements
The goals andconstraints of the I nformationMeshimply several implementation
requirements: minimal agreement, minimal coordination, andexibility.
MinimumAgreement
Theneedforminimal agreementcomesfromthepragmaticunderstandingthat
\wecannotdependonanyuniversal agreementonissueslikeabestwaytond
information, the internal structureof informationor how informationis inter-
nallymanipulatedbyprograms[24]."Thuswemustminimizetherequirements
imposedonMeshentities.
MinimumCoordination
The needfor minimumcoordination of informationows fromthe needfor
resilience and ubiquity. The Meshneeds to be highly scalable withdiverse
mechanismstond, representandmanipulateinformation. Thesegoalsarebest
metif theoverall coordinationbetweenthesecapabilities{andanyother core
I nformationMeshservices{aredesignedtominimizetherequiredcoordination.
Flexibility
The needfor exibilityis aresult of the needfor heterogeneity, longevityand
evolvability. TheMeshneedstosupportawidesetof global informationarchi-
tectures. Further, theI nformationMeshshouldbe \exibleenoughtoencom-
pass newnetworkservices as theyevolve. I tshouldalsosupport abroadset of
expectations fromapplicationsas well as administrativecontrols.[22]"
straintsof minimal universality, but withaneyetowardsminimumcoordinationand
enormous exibility. Thus, wemustminimizethesetof requiredMeshfunctionality
whilestill providingthesucient exibilitytobuildawiderangeof services ontop
of theMesh.
Notethat theI nformationMeshdoes not directlydeal withsecurityandpri-
vacyissuesexceptwheretheyaect designdecisions.
3.4 I nformationMeshKernel
The rst stepinrealizingtheI nformationMeshProject was theimplementationof
the I nformationMeshkernel [24]. The I nformationMeshkernel addresses several
of theconcerns raisedbytheProject. I nparticular, thekernel providesinformation
naming, discoveryandrelocationasapowerful andevolvablecomponentof theMesh.
TheI nformationMeshkernel'snamingisprovidedthroughtheuseof globally
uniqueidentiers describedas points. I nformationabout thesepoints arestoredin
sets of attribute-valuepairs calledfactoids. I nformationis locatedthroughaexible
andevolvablelocatingmechanismthatutilizesmeta-informationabout wherepoints
have been seen or discussed inthe Mesh. Finally, the kernel provides a generic
proceduredispatchmechanism
TheI nformationMeshkernel ensuresminimumcoordinationbyensuringthat
informationidentication(points) is decoupledfromlocationandretrieval. I npar-
ticular, pointscontainatmosthintsabout location. Theoverall kernel isdesignedto
haveminimumconstraints ondatarepresentationandlocationtoprovideaexible
informationinfrastructure.
3.5 I nformationMeshObject System
TheI nformationMeshobjectsystem[23] providestheMeshwithapowerfulmeansto
createandutilizeMeshobjects{thechief featureof whichisthecapabilityof objects
andmakers. Implementationsprovideobjectswithaconcreterepresentationof arole
capability.
3. 5. 1 MeshObjects
Meshobjects areidentiedthroughtheuseof oids. Oids provideanamingscheme
that ensures that objects canbe uniquelyspeciedthroughout theglobal network.
Our current implementationutilizes thekernel'spoints, but weeventuallyexpect to
provideamoregeneral identicationmechanism, suchas URNs [21].
Objectbehavioris built aroundthenotionof arole. Aroleis aspecication
of anabstract behavior andstructure, similar to anobject class. Anobject plays
aparticular roleif it behaves inthemanner describedbythat role. Tounderstand
the interactionof rolesandplays, imaginehowanindividual plays several roles in
lifesuchasparent, teacher, leader, follower, etc. Thisnotioncapturesthekeynotion
that objects canplaymultipleroles andthat the roles playedcanchange or evolve
throughtime. Roles arefurther describedinSection3.5.2.
All Meshobjectsplaytheobject-role. Theobject-roleprovidesastartingpoint
for all dialogs withI nformationMeshobjects. Sinceall Meshobjects must playthe
object-role, weare guaranteedthat the requiredobject-role actions are answerable
by anyMeshobject. Objects playingthe object-role cananswer questions about
whichroles theycanplay, allowtheadditionof newroles toplay, anddescribe the
implementationobjectsforaroleplayedbytheobject. Theobject-role'sactions and
parts aredetailedinAppendix7.
3. 5. 2 Roles
Roles are composedof actions, partsandmakers. Actions specifytheabstract be-
haviorof arole. Partsspecifythestaticabstract structureof arole. Makersspecify
theabstract mechanismsnecessaryfor creation. Takentogether, thesethreecharac-
teristics (actions, parts andmakers) constitute the necessarycharacteristics for an
objecttoplayaparticular role. Wewill examineactionsandpartsinmoredetail in
Sections 3.5.4and3.5.5. Sincemakersarenot important tothis discussion, wewill
not investigatethemfurther.
Roles arearrangedintoaninheritancehierarchysuchthat if anobject plays
aparticular role, italsoplays all of that role's super roles. Theinheritancerules for
roles are basedonthe hierarchyrules present inthe CommonLispObject System
specication [14]. The single root of all role inheritance is the object-role which
provides roleplayingcapabilitiesas describedinSection3.5.1.
Rolesserveasanextensibleobjecttypingmechanism. Rolesprovideinvariants
inobject interface{objects playingaroleagree toperformthe actions, parts and
makersspeciedbytherole. Furthermore, roleinheritanceprovides user extensible
typing. That is, auser speciedrole's positioninthehierarchydeterminesasubset
of theuser-speciedrole'sfeatures(becauseroleinheritancespeciesthatif anobject
playsaparticularrole, itplaysall of thatrole'ssuperroles). Thus, onecandetermine
asubsetof auser-speciedrole's features fromitspositionintherolehierarchy.
Rolesprovideexibilityandevolvabilitythroughtheabilityof objectstoplay
multipleroles. Objectscanplaymultipleroles simultaneouslyor evendierentroles
at dierent times; the nature of anobject canevolveintimebymakingthe same
objectplaynewrolesthroughitsexistence. Thus, newerapplicationscanhaveaccess
tooldobjectsviatheiroldroles at thesametimethatnewerapplicationscanaccess
thesameinformationbyusingnewerroles [23].
Roles arerstclass Meshobjects; aroleisaMeshobject whichdescribes the
actions, parts andmakers necessaryfor anobject to playa particular role. Mesh
objectswhichprovidesuchservices aresaidtobeplayingtherole-role.
3. 5. 3 Implementations
I mplementationsprovideMeshobjectswiththeabilityto`play' arolebydescribinga
concreterepresentationof aparticular role's actions, parts andmakers. Meshobject
1
We use `role' and`plays' insteadof `class' and`instance' tocapture the notionthat as objects
evolvethroughtimetheymayexhibitdiverse natures byplayingavarietyof roles.
gureout howtoimplementnewnatureonoldobjects.
I mplementations are independent of roles. I ntheory, everyobject playinga
particular role couldutilize adierent implementation. Alternatively, everyobject
implementingarole couldutilizethe sameimplementation. I npractice, it is likely
that implementations will be packagedanddistributedbya varietyof information
providers. I mplementations provideanimplementationinheritancemechanismsuch
that if a particular implementationdoesn't providea descriptionof some concrete
rolecapability, thesuper implementations areexaminedforthecapability.
I mplementations are rst class Meshobjects; animplementationis a Mesh
objectcontainingconcretemethodsfor actions, partsandmakers. Presentlymethods
arerepresentedusingportablelispcode.
3. 5. 4 Actions
Actionsspecifyrole behavior; theyspecifytheformof interactions withanyobject
playingarole. I nthis manner, actionsspecifytheinterfacetomethods. Forall roles
played, the followingactions are special inthat theyare always answerable byan
objectfor whateverroletheyareasked:
(ac tions-supportedobject role) Requiredfor all roles
Returns the list of actions that the object supports whenplayingthe role in
whichasked.
(supports-ac tion? object role action-name) Requiredfor all roles
Returnstrueif theobjectsupportsanactionnamedaction-name whenplaying
theroleinwhichasked. Returnsfalseotherwise.
Note that roles allowoptional actions whichare not requiredto be imple-
mented. Hence, theanswer to `supports-action?' must betruefor requiredactions
andmaybetrueforoptional actions. Theresultforoptional actionsdependsonboth
theimplementationandtheparticulars of theobjectof whichthequestionis asked.
istoallowslightlydierentcapabilitiesamongimplementationsof roles, forinstance,
animplementationof arole whichallows object mutations andanimplementation
whichdoes not allowobject mutations. Suchamechanismis particularlyuseful for
inheritedroles whereit is not alwaysdesirabletopermitsuper rolemutableactions.
Optional actions alsoallowobjects toprovidecertainactions onlyatcertaintimes.
3. 5. 5 Parts
Parts expose theabstract structure of anobject playingarole; theyspecifyanin-
terfacetoobjectstructure. Partsprovideanabilitytoexposeinvariants interms of
objectstructure. Partsaredividedintotwoportions: part-namesandpartinstances.
Part-namesaredescribedbytherole. PartinstancesarecreatedandutilizedbyMesh
objectsandexposedthroughseveral universal actions. Partinstancescanbespecied
throughtheuseof apart-nameandselector.
Part-namesare relativelystatic structure names. I ntheoriginal object im-
plementation, part-namesaresimplyidentiersspeciedbyarole. All possiblepart
namesfor aparticular rolecanbestaticallydetermined.
Part-names maybeeither requiredor optional. Objects mustimplementthe
parts associatedwithrequiredpart-names. As withactions, the existence of part
namesisanswerablebyall Meshobjectsregardlessof therole. The`parts-supported'
actionenumeratesthecurrentlyavailablepart-namesandthe`supports-part?' action
determinestheexistenceof aparticular part-name.
(parts-supportedobject role) Requiredfor all roles
Returns thelist of part-names that theobject supports whenplayingtherole
inwhichasked.
(supports-part? object role part-name) Requiredfor all roles
Returnstrueif theobjectcontainsapart-namewhenplayingtheroleinwhich
asked. Returnsfalseotherwise. Mustreturntrueforall requiredpartsandmay
betruefor optional parts.
mechanismtoexposeadynamicmodel of object substructure. Part instances may
overlaporevencontainoneanother; theycanbedynamicallycreatedanddestroyed.
I t is important to notethat part instances donot havetoformanenumerableset.
Thus, it maynot bepossible toknowall selectors for aparticular part-name. Part
instanceutilizationisdeterminedbytheobjectwhichcontainsthem.
Partinstanceexistencecanbedeterminedthroughtheutilizationof the`has-
part-instance?' action. Note that there is no `supported-part-instances' actionto
enumeratethepart instance selectors (because of the potential innumerablenature
of part instances).
(has-part-instanc e? object role part-name selector) Requiredfor all roles
Returnstrueif theobjectcontainsaninstanceof thepartspeciedforthegiven
selector.
Selectionof partinstancesislargelyprovidedbyspecifyingapart-nameanda
selector. Aselectorcouldbearange, wordsinadocumentobject, etc., butthisisnot
exposedbytherole. Selectorsalwaysspecifyaparticularinstance, butpartinstances
canbeconstructedinamanner suchthat their selectionindicates theutilizationof
several part instances. Thus, apart instancecanbeaset of instances. Regardless,
theoriginal Meshobjectsystemdoesnotprovideamechanismtoexposethecontents
of part instances. We will examineanenhancements to providesuchcapabilityin
Section4.3.
Another limitationof the original object systemis the limitedcapabilityto
exposetheselectorsavailablefor part instances. Thereisnot, forinstance, amecha-
nismtoenumerate(if possible) theset of instances for aparticular part name. Nor
is there amechanismto staticallyexpose part instance selector criteriaintherole
declaration. Oneresultof thislimitationisthatthereisnomechanismtodeclarethat
aparticular part-name canhaveonlyone part instance associatedwithit. I ndeed,
thereis nomechanismtoexposepart instances availablefor anypart-name, nor to
specifythe range of potential selectors. This is not entirelysurprisingas the part
instanceset{andvalidselectors {mightbelarge, arbitraryorunspeciable.
rationof part-names inthe role, the runtime determinationof optional part name
existence andthe abilityto determine the existence of a particular part-instance
throughthe `has-part-instance?' action. Not initiallyassociatedwithparts is the
capabilityforpart content manipulationor part instanceselectionexposure.
3.6 Summary
Theoverall visionof theI nformationMeshProjectisalong-livedglobal architecture
fornetwork-basedinformationreference, manipulationandaccess. Onecomponentof
this visionis thenotionof Meshobjectsinterconnectedbylinks. Theconstraintsto
meetthisvisioncanbesummarizedasuniversality, ubiquity, heterogeneity, longevity,
evolvabilityandresiliency. TheI nformationMeshrequirementsfor basemeshcapa-
bilitiesareminimumagreement, minimumcoordinationandmaximumexibility.
The I nformationMeshobject systemprovides ameans to createandutilize
Meshobjects. Meshobjects are identiedthroughthe use of oids. Meshobject
behavior is built aroundthe notionof arole. Aroleis anabstract specicationfor
objectbehavior. Rolesdescribeabstractfunctionality(actions)andabstractstructure
(parts). Anobject is saidto \play"aroleif it behaves inthemanner describedby
thatrole. Rolesserveasanextensibleobjecttypingmechanism{providingexibility
andevolvabilitytoMeshobjects.
Meshobjectsexposetheirsubstructurethroughtheutilizationof parts. Parts
are composedof part-names andpart instances. Part-names are static names for
objectstructure. PartinstancesaretheMeshmechanismtoexposeadynamicmodel
of object substructure. Selectionof part instances is providedbyspecifyingapart-
nameandselector. Theoriginal Meshobject systemdoes not provideamechanism
toexpose thecontentsof part instances, nor amechanismsto expose selector char-
acteristicsfor apart.
Notethatunfullledfromtheoriginal visionof theI nformationMeshisalink
mechanismtodescriberelationships amongMeshobjects. I nthe next chapter, we
will examinemodicationstoMeshobjects tobetter support Meshlinks.
Mes h Obj ect s as Li nkabl e Nodes
TheI nformationMeshvisionof objectsinterconnectedbylinksrequiresanexamina-
tionof Meshobjects as nodes for linkinginthe Mesh. I nthis chapter, weexamine
Meshobjects usingthe criteriadescribedinChapter 2. Namely, we examineMesh
capabilitytoprovide:
naming
typing
substructureinterface
compositeobjects
ForcapabilitiesalreadyprovidedbytheMesh, wereviewtheimplementation
anddescribe anylimitations or necessaryenhancements. For capabilities not pro-
videdbytheMesh, wedescribeimplementationoptions, their associatedlimitations
andthechosenimplementation. Finally, wedescribeseveral examples of hypertext
nodes implementedutilizingMeshobjects andthe describedenhancements. Note
that versioning, whichis importantbut notcentral toour overall discussionof Mesh
links, isdescribedinAppendix8
Nodes ina hypertext systemneedto be namedor distinguishedinsome manner.
As showninSection3.5, the I nformationMeshensures that all Meshobjects are
associatedwithagloballyuniqueobject identieror oidwhichprovidesobjectiden-
ticationandnaming. Oids containnosemanticsabout object capability, location,
versioningor typing.
Notethat theMeshdoes not haveamechanismsimilar toDexter's Resolver
function(describedinSection2.5.4) to produce oids fromanobject specication.
However, suchamechanismcouldbe implementedas aMeshservice. Weconsider
suchamechanismtobeoutsidethescopeof Meshlinks.
4.2 Typing
Nodetypingprovidesamechanismtodescribenodesemanticsandinvariants. Chap-
ter 2detailedavarietyof hypertext nodetypingmechanisms including: notyping,
single value typing, hierarchal types andattribute-value pairs. This examination
madecleartheneedfor anextensibletypingmechanism.
The I nformationMeshobject systemutilizes roles as its typingmechanism.
Roles provide apowerful typingmechanismsucient for Meshobjects to function
as hypertextnodes. I nparticular, rolesprovideobjectinvariantsanduserextensible
typing. Role exibilitywas previously describedinSection3.5.2. The usefulness
of roles as a node typingmechanismis strengthenedbythe observationthat roles
cansupport all of thetypingmodelsdescribedinChapter 2. Morespecically, single
valueandattribute-valuetypingcanbeprovided throughobjectpartsandhierarchical
types canbeprovidedthroughroleinheritance.
4.3 Substructure I nterface
As describedinChapter 2, links are limitedbythesubstructureinterfaceprovided
bynodes. For example, Dexter links arelimitedbythe anchors exposedbyDexter
nodemodications. Thelackof substructureexposureorinvariantsclearlylimitslink
capability.
I ntheI nformationMeshobjectsystem, objectsubstructureis formalizedinto
parts. Partsprovideamechanismtoexposeobjectstructureinamannersimilartohy-
pertextnodeanchors, butinamoresystematicandgeneralizablemanner. TheMesh
object systemprovides the capabilityto declare part names, determinepart-name
presence through`has-part?' and`parts-supported', anddeterminetheexistenceof
part instancesthroughthe`has-part-instance?' action.
Selector exposureandcontentmanipulationwerenot providedintheoriginal
object systemimplementation. Wedescribemodications toprovidethesecapabili-
ties.
4. 3. 1 SelectorExposure
The Meshobject systemutilizes selectors to specifypart instances anddetermine
theirexistence. However, thereis nomechanismtospecifyselectorcharacteristicsin
arole declarationof apart-name. Wedescribe amechanismutilizingroledeclara-
tions tospecifyselectorcharacteristicsandspecializedactionswhichcanutilizesuch
declarations.
Role declarationof part selector characteristics allows one to describe part
instance capabilities for a speciedpart-name. Thus, role declarations of selector
characteristics constraintheset of possible part selectors for aspeciedpart-name.
Wedescribeselectorcharacteristicsbyprovidingaselectortypewitheachpart-name
inaroledeclaration. Weprovidethefollowingselectortypes:
unspec ied characteristicof selectorsisunspecied
unary-of onepart instance(part selectorisignored)
set-of part instances aregroupedintooneunordered
(noselectionnecessary)
ordered-of part instancesareorderedanddeterminableat run-time.
The declarationof part selector types allows the use of specializedactions
for certainselector types. I nparticular, parts utilizinga`named-of' or `ordered-of'
selector type can(optionally) provide runtime capabilities to create andremove
part instances. `Unary-of' and`set-of' selector typesignoretheselector for anypart
instancemanipulationactions, suchasthecontentmanipulationactionsdescribedin
Section4.3.2.
Part-instanc e-names (`named-of 'ac tions)
(part-instanc e-names object role part-name) Optional for all roles
Enumerates theselectors for part instances associatedwiththe speciedpart
name. Returns falseif there are nopart instances associatedwithpart-name.
Requiresthatthepart-namebedeclaredintheroleasutilizinga`named-set-of'
selector type.
(add-named-part-instanc e! object role part-name instance-name contents) Optional
for all roles
Allowsonetoaddanamedpart instancetothespeciedpart-name. Requires
that part-namebedeclaredas utilizinga`named-set-of' selectortype.
(remove-named-part-instanc e! object role part-name instance-name) Optional for
all roles
Allows one to remove a specied part-instance. Requires that the specied
part-namebedeclaredintheroleas utilizinga`named-set-of' selector.
Parts declaredwitha`named-of' selectortypecanbeutilizedas bothanan-
choringmechanism(namedselectorsserveasanchoridentiersandinstancecontents
serveas anchor values) andattribute-valuepairs (namedselectorsserveasattribute
namesandinstancecontentsserveas values).
