1 / 31

Web Architecture Part 3

Web Architecture Part 3. http://www.w3.org/TR/2004/REC-webarch-20041215/. Web Architecture – so far. Collection of details of how technology works At a rather shallow level Now : Underlying principles Objectives : Reflection Re- assessment Connecting the dots. Identification.

allegra-lawrence
Download Presentation

Web Architecture Part 3

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Web Architecture Part 3 http://www.w3.org/TR/2004/REC-webarch-20041215/

  2. Web Architecture – so far • Collectionofdetailsofhowtechnologyworks • At a rathershallowlevel • Now: • Underlyingprinciples • Objectives: • Reflection • Re-assessment • Connectingthedots

  3. Identification

  4. Principle: Global Identifiers • thevalueof an identifierincreasesthemoreitisusedconsistently • Analogousinterestingexample: no (!) proliferationofontologies • Every objectaddressable[Engelbart 1990, http://www.dougengelbart.org/pubs/augment-132082.html#2a1] Global namingleadsto global networkeffects.

  5. Goodpractice: Identifywith URIs Tobenefitfromandincreasethevalueofthe World Wide Web, agentsshouldprovide URIs asidentifiersforresources. • A resourceshouldhave an associated URI ifanotherpartymightreasonablywantto • createa hypertext link toit, • makeorrefuteassertionsaboutit, • retrieveorcache a representationofit, • include • all or • partofitbyreferenceintoanotherrepresentation, • annotateit, or • performotheroperations on it. • Software developersshouldexpectthatsharing URIs acrossapplications will beuseful, evenifthatutilityis not initially evident. Much morethanhypertextlinking!

  6. URI Syntax • Fullspecification: http://www.ietf.org/rfc/rfc3986.txt • Examples: • ftp://ftp.is.co.za/rfc/rfc1808.txt • http://www.ietf.org/rfc/rfc2396.txt • ldap://[2001:db8::7]/c=GB?objectClass?one • mailto:John.Doe@example.com • news:comp.infosystems.www.servers.unix • tel:+1-816-555-1212 • telnet://192.0.2.16:80/ • urn:oasis:names:specification:docbook:dtd:xml:4.1.2

  7. URI, URL, URN, IRI • Uniform Resource Identifier • Uniform Resource Locator • Uniform Resource Name • IRI • http://ヒキワリ.ナットウ.ニホン

  8. Cool URIs don'tchange • Whatmakes a cool URI? • A cool URI isonewhichdoes not change. • Whatsortsof URI change? • URIs don'tchange: peoplechangethem.

  9. Cool URIs don'tchange • Idea: URIs are an abstractspace • Different fromfileordatabasespace • Do‘s: • Describeyourdocumentswithstableproperties/pubs/2012/DellschaftHypertextPaper.htmlwill neverhavetochange • Don‘ts: • Describingyourdocumentsaccordingto • thesoftwareyouusenow: /cgi-bin/paper?nr=1234 • theownerofthedocument: /fb4/AGStaab/Publications • ownership, access, archivelevelsecuritylevel, ...

  10. The troublewithidentifiers • Experience: Knowledgeacquisitionfortheknowledgeacquisitioncommunity • V. Richard Benjamins, Dieter Fensel, Stefan Decker, Asunción Gómez-Pérez: (KA)2: buildingontologiesforthe Internet: a mid-term report. Int. J. Hum.-Comput. Stud. 51(3): 687-712 (1999) • Steffen Staab, Jürgen Angele, Stefan Decker, Michael Erdmann, Andreas Hotho, Alexander Maedche, Hans-Peter Schnurr, Rudi Studer, York Sure: Semanticcommunity Web portals. Computer Networks 33(1-6): 473-491 (2000) • Fewhundredfacts, yet • 3 identifiersfor Dieter Fensel!

  11. URI aliases • Web architectureallowstheassociationofmorethanone URI with a resource. • URIs thatidentifythe same resourcearecalled URI aliases. • Goodpractice: Avoiding URI aliases • A URI owner SHOULD NOT associatearbitrarily different URIs withthe same resource. • Goodpractice: Consistent URI usage • An agentthatreceives a URI SHOULD refertotheassociatedresourceusingthe same URI, character-by-character. • Ifaliasesareused, then • selectoneofthemas • Server-sideredirecttheotherbythe web server (e.g. 30x errorcode)

  12. Aliasing vsDereferencing URIs • Dereferencing • http://www.koblenz.de/weather/current/ • http://www.koblenz.de/weather/2012-11-02 • May giveidenticalresults, but therearenoaliases, because on Nov 3 they will have different content • The meaningofthetwo URIs is different! • Even on November 2, 2012

  13. URI collision • URI forthewebpageof Steffen Staab • is not the same as • URI for Steffen Staab • Theyhave different • Creationdates • Creationmethods • Interfaces • .... • KA2 Experience (andbeyond): oftendonewrongly

  14. Semanticsofidentity • "Web Ontology Language (OWL)" [OWL10] definesRDF properties • sameAstoassertthattwo URIs identifythe same resource • inverseFunctionalPropertytoimplyit

  15. Interaction/Protocols

  16. Accessingresources • Usinga URI to Access a Resource • URI typicallyprefixedby a protocolscheme, e.g. • http://west.uni-koblenz.de • Withdefaultprotocolmethods, e.g. get, post,... • Access torepresentationdepends on • WhetherURI ownermakesavailableanyrepresentationsat all; • Whethertheagentmakingtherequesthasaccessprivileges • Ifthe URI ownerhasprovidedmorethanonerepresentation (in different formats such as HTML, PNG, or RDF; in different languages; ortransformeddynamicallyaccordingtothehardwareorsoftwarecapabilitiesoftherecipient), theresultingrepresentationmaydepend on negotiationbetweentheuseragentandserver. • The time oftherequest; theworldchangesover time, so representationschange

  17. Representationtypes & Internet mediatypes • A representationisdatathatencodesinformationaboutresourcestate. • Goodpractice: Reuse representationformats • New protocolscreatedforthe Web SHOULD transmitrepresentationsasoctetstreamstypedby Internet mediatypes.

  18. Separation ofConcerns / Orthogonality • Body understoodby HTML processor(does not knowabout SVG) • Link extracted, clickedbyuser • Image servedasimage/svg+xml • SVG processorrendersimage (does not knowaboutHTML) • SVG processorinterprets „#hat“ appropriately <body> ... <a href="http://www.example.com/images/nadia#hat">Nadia's hat</a> ... </body>

  19. Content Negotiation • User agent (browser) informstheserverwhatmediatypesitunderstandswithratingsofhowwellitunderstandsthem Accept HTTP header Accept-Language: de; q=1.0, en; q=0.5 Accept: text/html; q=1.0, text/*; q=0.8, image/gif; q=0.6, image/jpeg; q=0.6, image/*; q=0.5, */*; q=0.1

  20. Availabilityandconsistencyof URI dereferencing In practice, URIs arebookmarked, forwarded, stored; dereferencingthemshouldleadtopredictableperformance • Goodpractice: Availablerepresentation • A URI owner SHOULD providerepresentationsoftheresourceitidentifies • Goodpractice: Consistentrepresentation • A URI owner SHOULD providerepresentationsoftheidentifiedresourceconsistentlyandpredictably.

  21. Linking andaccesscontrol • Don‘tassumethat a pageisunaccessiblebecauseithas not beentoldabouttoanyone • E.g. browsersstorewhereyou last havebeen • Server logsandsearchenginesextract such links • Search enginesthus find partsofthehidden web • Ratheruse • Access control • Login + password

  22. Formats

  23. Whentouse an XML-basedformat Design constraintsthatsuggesttheuseof XML include: • Requirementfor a hierarchicalstructure. • Need for a widerangeoftools on a varietyofplatforms. • Need fordatathatcanoutlivecurrentapplications • Abilitytosupportinternationalization in a self-describingwaythatmakesconfusionovercodingoptionsunlikely. • Early detectionofencodingerrorswithnorequirementto "workaround" such errors. • A high proportionof human-readabletextualcontent. • Potential compositionofthedataformatwithother XML-encodedformats. • Desirefordataeasilyparsedbybothhumansandmachines. • Desireforvocabulariesthatcanbeinvented in a distributedmannerandcombinedflexibly.

  24. Binary dataformats

  25. ArchitecturalPrinciples

  26. Principle: Orthogonality Orthogonal abstractionsbenefitfrom orthogonal specifications. Applicationoftheprinciple: Identification, interaction, andrepresentationare orthogonal concepts, theirtechnologiesmayevolveindependently. Examples: • Resources areidentifiedwithURIs (noneedforknowingabout ist representationoravailability). • Generic URI syntaxoftendoes not requireknowingspecificsof URI schemes • Representationof a resourcemaybechangedwithoutdisruptingreferencestotheresource(eg, bycontentnegotiation). • Even orthogonal specificationsmaychangeindependently (e.g. whenadopting SVG)

  27. Principle: Extensibility • Nestingoflanguages • E.g. Web ontologylanguage: OWL 2 • Every legal OWL Lite ontologyis a legal OWL DL ontology. • Every legal OWL DL ontologyis a legal OWL Fullontology. • Every valid OWL Lite conclusionis a valid OWL DL conclusion. • Every valid OWL DL conclusionis a valid OWL Fullconclusion. • Try toavoidcompatibilityproblembyignoringunknownlanguageconstructsofthemore expressive language • Still beableto „do something“ • E.g. showtextonlyifyoucannotdisplaygraphics

  28. Principle: Error recovery Agentsthatrecoverfromerrorbymaking a choicewithouttheuser'sconsentare not acting on theuser's behalf. • Consentmaybepre-configured • Error correction • Repairtheerrortomakeitunhappen • E.g. request packet againifitfailstoarrive in time • Error recovery • Continueworkingbylivingwiththeerror Web is a softwareenvironmentwheretheuserisexpectedtobeawareofsomeerrors!

  29. Protocol-basedInteroperability • interfacesaredefined in termsofprotocols, • syntax, • semantics, and • sequencingconstraints • (time outs) • ofthemessagesinterchanged. • Contrast: APIs • Protocol-based design • Agentsaredevelopedfasterthantheprotocols • Makeprotocolsvisible • Allowforunderstandingandengineering

More Related