Introduction - USGS



Machine-actionable web linking: datasets, services, metadataWorking concept development document for discussionS.M. Richard steve.richard@azgs. 2011-09-06IntroductionThe basic issue is how to assert associations (referred to as links) between resources for machine processing. Metadata descriptions are the context of interest. Specifically, a web context document (common operating picture, OWS context) provides links to a collection of resources that constitute a workspace environment, e.g. a map mash-up bringing a variety of service-based spatial data together to convey some interpretation.A metadata record for a data granule links to a metadata record describing the collection that contains the granuleA dataset metadata descriptions contains links to one or more services that provide access to the dataA service metadata record contains links to metadata for the datasets the service distributes or utilizes.A workflow description describes a chain of services An Atom feed describing an information resource provides links enabling a variety of human and machine interactions with the resource that access different representations and interfaces.This issue impacts a variety of current activities considering use of Atom, GeoRSS, or csw:record for metadata associations between resources, including (among others) the OWS context Standards Working Group, the ESIP-discovery cluster, energy industry ISO19115 metadata profile, the protocol for Web Description Resources (POWDER), and USGS CGI Web Application Integration Framework group.The basic web architecture is designed to account for human-directed navigation of links to obtain resources that for the most part were intended for display and visual processing by human users. With the increasing adoption of service-based architecture and semantic web technology, machine interpretation and processing of resources is becoming an integral part of an evolving distributed computation system. Simply clicking on a link to see what you get does not work for this application. Links between resources for machine processing require additional information about the nature of the target resource, its capabilities, data structure, and content.The web works on http and html. MIME type in content type header parameter in response to an ‘http GET’ is used to pick handler for a response document (message), handler has to know characteristics of that encoding scheme to utilize the response content. This works for responses. We want the inverse: given a choice of several URIs to deference (typically using http framework, with implication that http header parameters may be involved), which one(s) exposes the representation or interface that the software client requires.Use cases:Link to directly access the dataset; want URL that will return dataAnswer question—does this service present the same data as that service… want to get metadata for dataMetadata description of service resource has links to metadata for datasets it servesMetadata description of service has identifiers for datasets that it serversMetadata for a dataset contains actionable link/description of services providing the dataa service cast entry specifies what datasets it "serves"a dataset (or collection) cast specify what services are available to query, access, or transform each dataset.ESIP-Discovery discussionBased on e-mail esip-discovery Brian Wilson (Aug 30, 2011, at 6:07 PM), revised by SMR.The list of datasets to which a particular service provides access to might be lengthy and computed using a search or semantic lookup process. Trying to 'name' (assign identifiers to) datasets provided by the service cast is problematic. The proposed solution is to provide a URL that retrieves a list of the data sets. This process is functionally equivalent to a catalog search in which the criterion is ‘find datasets served by service instance Z’. The request URL might access any of a number of search services—OpenSearch, CSW, …, and results could be returned in any of a variety of metadata encoding schemes—Atom, GeoRSS, ISO19115, csw:record etc. The ESIP proposed solution is to use and OpenSearch URL that returns an Atom feed document.So the scast entry would contain a <DEFANGED_link> tag as follows:<DEFANGED_link rel="" type="application/atom+xml" xmlns:esip="" esip:serviceType="" esip:outputScheme="" href="<specific OpenSearch URL that does the appropriate search>" />The "collection" rel URI is used in this example, but a more specific one like "collectionsServed" could be defined and registered. The important convention is that a known link (with rel=) can be identified that contains the URL to get the list of datasets.The fact that this <DEFANGED_link> is an OpenSearch is expressed in the 'protocol' attribute using the usual URI for versioned opensearch protocol. The key is to include information indicating the encoding scheme and metadata content model that will be used in the data set list returned by the URL. This information has two (maybe more?) facets—the serviceType (OpenSearch, CSW, …), and resultSchema (ATOM, ISO19139, some JSON scheme…). The format for the encoding is indicated by the “type” attribute on the link. One would assume that in the OpenSearch case, the OpenSearch target must offer the media type specified in the link ‘type’ attribute.The beauty of hiding the collectionsServed question behind a search link is that the list of collectionsServed is available on demand, can be updated without having to alter and re-publish the service cast, and metadata describing the datasets is available in one or more known formats. Service metadata and dataset metadata are strictly separated into their respective casts, and are presented in known formats. This metadata can be used for presentation to users in a GUI or (if it is structured with sufficient information) to automatically connect client application software to a particular collection (dataset) from the service.Behind the search URL, implementers are free to innovate any way they want to, but in the meantime ESIP can move forward with standardizing the casting formats by using OpenSearch and Atom. Implementers can also choose alternate service types and metadata encoding for the benefit of clients using those protocols.Linkage from a dataset description to services that provide the dataset can be solved in the same way.A link to 'servicesAvailable' could appear in each entry in a collection cast, as in:<DEFANGED_link rel="" type="application/atom+xml" xmlns:esip="" esip:serviceType="" esip:outputScheme="" href="<specific OpenSearch URL that does the appropriate search>" />In this example, the OpenSearch URL yields a service cast listing the services available for that dataset, with the metadata in the requested outputScheme and media type.This indicates why conventions for the type, serviceType and outputScheme attributes need to be adopted. Given this flexibility and extra power, clients can provide solutions to thorny problems outlined above. URI's for the attributes will be explicitly defined or reused from W3C, and ultimately could be de-referenceable for more information if that serves additional purposes.Defining 'vendor-specific' MIME types for the casting (extended Atom) formats should be considered. For example: "application/vnd.esip.discovery.cast.collection" and "application/vnd.esip.discovery.cast.service". However, this conflates actual encoding (the intention of MIME), and content scheme, and would likely create more confusion that having and explicit output scheme attribute.The scheme in a HREF simply doesn't specify the specific service protocol being used in a HTTP URL. The mime type in the 'type' attribute also doesn't have enough information about the content scheme in the retrieved resource. Thus, we need specific attributes to indicate serviceType, version, and outputScheme in order to fully enable clients to utilize service metadata. (See also ISO 19115, and ISO19115 CI_OnlineResource element).To be compatible with implementations outside the community utilizing our conventions, we need to honor the allowed 'rel' attributes, like icon and enclosure, which are commonly used. More specific attributes can contain the more specific sub-purposes we need.Proposed link attributes:hrefthe link URLtypeMIME type of response. Specifies encoding and optionally the native software application environment relURI from IANA rel vocabulary for for consistency with IETF5988titlefree text to label link in GUIesip:protocolftp, http, …. Default is http if attribute not specifiedesip:serviceTypeURI that identifies a service protocol and version (one attribute or two?)esip:purposeanalogous to ISO19115 CI_OnlineFunctionCodeesip:outputschemeprofile for content of message retrieve by href URL; may be WFS feature name, URI for xml schema or JSON scheme, other description of data structure and content? Need conventions, clear definition.Based on conflation of IETF 5988, ISO19115 CI_OnlineResource, and ISO19119 service metadata More concretely, some examples would be: rel="enclosure" esip:outputScheme="...data#" esip:serviceType="" type=”” href="..."rel="enclosure" esip:outputScheme="...data#" esip:protocol=”ftp” href="<http/ftp link to data file>"rel="icon" esip:purpose="...browse/image#" esip:serviceType="urn:ogc:service:wms:1.3.0" type=”tif” href="..."rel="icon" esip:purpose="...browse/image#" type=’png’ href="<http link to png file>"rel="describedBy" esip:purpose="...metadata#" esip:serviceType="OpenSearch" type=’application/xml+atom outputScheme=’’ href="..."rel="describedBy" esip:purpose="...metadata#" type="html" href="<documentation web page>"rel="search" esip:purpose="...search#" esip:ServiceType="OpenSearch" type=’application/xml+atom outputScheme=’’ href="..." href="..."rel="related" esip:purpose="...service#" esip:ServiceType="WMS" esip:outputScheme="getCapabilities" type=’application/xml’ href="..."[to add] other examples… put hereThe rel="via" might also be useful. Need esip:purpose vocabulary to distinguish between a related service, here denoted with "service#", and a service cast denoted "serviceCast#", which contains metadata for a list of services. That last link type is exactly what would be used in a collectionCast to point to the list of available services. Similarly, perhaps "collection#" should be used to point back to the collection in a data granule cast, and "collectionCast#" indicates the usual datasets cast.Supplemental information and backgroundrel link types ESIPfrom HYPERLINK "" . Describes links to external information. These links include a relation and type. Link type Description Default data link. Data Casting Granules. OpenSearch Granules response. Appropriate for smaller browse images. See following for alternate browse links. Default documentation. See following for alternate documentation links. Data, collection, and service metadata. Data Casting Collection. Not for OpenSearch Collection response which uses OSDD instead. Service Casting. Micro-articles of natural phenomenon. Feed of various feeds. Enables hierarchy of feeds. ISO19115-1 online resourceName / Role NameDefinitionDomainCI_OnlineResourcelinkagelocation (address) for on-line access using a Uniform Resource Locator/ Uniform Resource Identifier address or similar addressing schemeURLprotocolconnection protocol to be used e.g. http, ftp. See IETF registry at textapplicationProfilename of an application profile that can be used with the online resource [e.g. CSW 2.0.2, WFS 1.1.1, WMS 1.3.0, OpenSearch 1.1, OpenDAP. If URL returns a document, this could be the application that created the document, e.g. MS Word 7, Oracle 11, MS Excel]Free textnamename of the online resourceFree textdescriptiondetailed text description of what the online resource is/doesFree textfunctioncode for function performed by the online resourceCI_OnLineFunctionCodeprotocolRequestprotocol used by the accessed resource [ISO definition is not clear; this could be interpreted to use for MIME-type of response]Free textWeb Linking rfc5988In this specification, a link is a typed connection between two resources that are identified by Internationalised Resource Identifiers (IRIs) [RFC3987], and is comprised of:A context IRI,a link relation type (Section 4),a target IRI, andoptionally, target attributes.A link can be viewed as a statement of the form "{context IRI} has a {relation type} resource at {target IRI}, which has {target attributes}". Note that in the common case, the context IRI will also be a URI [RFC3986], because many protocols (such as HTTP) do not support dereferencing IRIs. Likewise, the target IRI will be converted to a URI (see [RFC3987], Section 3.1) in serialisations that do not support IRIs (e.g., the Link header).This specification does not place restrictions on the cardinality of links; there can be multiple links to and from a particular IRI, and multiple links of different types between two given IRIs. Likewise, the relative ordering of links in any particular serialisation, or between serialisations (e.g., the Link header and in-content links) is not specified or significant in this specification; applications that wish to consider ordering significant can do so.Target attributes are a set of key/value pairs that describe the link or its target; for example, a media type hint. This specification does not attempt to coordinate their names or use, but does provide common target attributes for use in the Link HTTP header.Additionally, specific applications of linking may require additional data to be included in the registry. For example, Web browsers might want to know what kinds of links should be downloaded when they archive a Web page; if this application-specific information is in the registry, new link relation types can control this behavior without unnecessary coordination. To accommodate this, per-entry application data can be added to the Link Relation Type registry, by registering it in the Link Relation Application Data registry.Applications that don’t wish to register a relation type can use an extension relation type, which is a URI [RFC3986] that uniquely identifies the relation type.The Link entity-header field provides a means for serialising one or more links in HTTP headers. It is semantically equivalent to the <LINK> element in HTML, as well as the atom:link feed-level elementin Atom [RFC4287].Link = "Link" ":" #link-valuelink-value = "<" URI-Reference ">" *( ";" link-param )link-param = ( ( "rel" "=" relation-types )| ( "anchor" "=" <"> URI-Reference <"> )| ( "rev" "=" relation-types ) ;deprecate in this spec| ( "hreflang" "=" Language-Tag )| ( "media" "=" ( MediaDesc | ( <"> MediaDesc <"> ) ) )| ( "title" "=" quoted-string )| ( "title*" "=" ext-value )| ( "type" "=" ( media-type | quoted-mt ) )| ( link-extension ) )link-extension = ( parmname [ "=" ( ptoken | quoted-string ) ] )| ( ext-name-star "=" ext-value )ext-name-star = parmname "*" ; reserved for RFC2231-profiled; extensions. Whitespace NOT; allowed in between.Link-value is target IRIAnchor parameter assigns context different than the IRI of the requested resource.Relation-types is from IANA registry of Atom link relations at , references IETF Web Linking RFC (). Original Atom registry maintained by IANA and initially contains five values: "alternate", "related", "self", "enclosure", and "via" (). RFC5988 expands the pilation and alignment of rel attribute values. ESIP link TypesIANA Link relations (from registry xml, 2011-09-04)edisc11:data# Default data link. Data Casting Granules. OpenSearch Granules response. ??edisc11:browse# Appropriate for smaller browse images. See following for alternate browse links. ??edisc11:documentation# Default documentation. See following for alternate documentation links. DescribedbyRefers to a resource providing information about the link's contextedisc11:metadata# Data, collection, and service metadata. ??edisc11:collection# Data Casting Collection. Not for OpenSearch Collection response which uses OSDD instead. ??edisc11:service# Service Casting. ??edisc11:event# Micro-articles of natural phenomenon. ??edisc11:feed# Feed of various feeds. Enables hierarchy of feeds. ??paymentIndicates a resource where payment is accepted. It is meant as a general way to facilitate acts of payment, and thus this specification makes no assumptions on the type of payment or transaction protocol. Examples may include a web page where donations are accepted or where goods and services are available for purchase. rel="payment" is not intended to initiate an automated transaction. In Atom documents, a link element with a rel="payment" attribute may exist at the feed/channel level and/or the entry/item level. For example, a rel="payment" link at the feed/channel level may point to a "tip jar" URI, whereas an entry/ item containing a book review may include a rel="payment" link that points to the location where the book may be purchased through an online retailer.SearchRefers to a resource that can be used to search through the link's context and related resourcesAlternateRefers to a substitute for this contextAppendixRefers to an appendix.ArchivesRefers to a collection of records, documents, or other materials of historical interest.AuthorRefers to the context's author.BookmarkGives a permanent link to use for bookmarking purposes.CanonicalA "canonical" URI is the preferred version of a set of URIs with highly similar content. It is intended to help search engines when the same or highly similar similar content is available at different URIs. In and the authors state that Ask, Bing, Google, and Yahoo supported canonical URIs as of February, 2009.ChapterRefers to a chapter in a collection of resources.ContentsRefers to a table of contents.CopyrightRefers to a copyright statement that applies to the link's contextCurrentRefers to a resource containing the most recent item(s) in a collection of resourcesDuplicateRefers to a resource whose available representations are byte-for-byte identical with the corresponding representations of the context IRI. This relation is for static resources. That is, an HTTP GET request on any duplicate will return the same representation. It does not make sense for dynamic or POSTable resources and should not be used for them.EditRefers to a resource that can be used to edit the link's contextedit-mediaRefers to a resource that can be used to edit media associated with the link's contextenclosureIdentifies a related resource that is potentially large and might require special handlingfirstAn IRI that refers to the furthest preceding resource in a series of resourcesglossaryRefers to a glossary of termshelpRefers to context-sensitive helphubRefers to a hub that enables registration for notification of updates to the contexticonRefers to an icon representing the link's contextindexRefers to an indexlastAn IRI that refers to the furthest following resource in a series of resourceslatest-versionPoints to a resource containing the latest (e.g., current) version of the contextlicenseRefers to a license associated with this context. For implications of use in HTML, see: to a resource that can be used to monitor changes in an HTTP resource.monitor-groupRefers to a resource that can be used to monitor changes in a specified group of HTTP resources.NextIndicates that the link's context is a part of a series, and that the next in the series is the link target.next-archiveRefers to the immediately following archive resourcenofollowIndicates that the context’s original author or publisher does not endorse the link targetnoreferrerIndicates that no referrer information is to be leaked when following the linkpredecessor-versionPoints to a resource containing the predecessor version in the version history.PrefetchIndicates that the link target should be preemptively cachedPrevIndicates that the link's context is a part of a series, and that the previous in the series is the link target.PreviousRefers to the previous resource in an ordered series of resources. Synonym for "prev"prev-archiveRefers to the immediately preceding archive resourcerelatedIdentifies a related resourcerepliesIdentifies a resource that is a reply to the context of the link.SectionRefers to a section in a collection of resourcesSelfConveys an identifier for the link's context.ServiceIndicates a URI that can be used to retrieve a service document. When used in an Atom document, this relation type specifies Atom Publishing Protocol service documents by default. StartRefers to the first resource in a collection of resourcesStylesheetRefers to a stylesheetSubsectionRefers to a resource serving as a subsection in a collection of resourcessuccessor-versionPoints to a resource containing the successor version in the version history.TagGives a tag (identified by the given address) that applies to the current document.UpRefers to a parent document in a hierarchy of documents.version-historyPoints to a resource containing the version history for the context.ViaIdentifies a resource that is the source of the information in the link's context.working-copyPoints to a working copy for this resourceworking-copy-ofPoints to the versioned resource from which this working copy was obtained.The "hreflang", "media", "title", "title*", "type", and any link-extension link-params are considered to be target attributes for the link.The "hreflang" parameter, when present, is a hint indicating what the blanguage of the result of dereferencing the link should be. Note that this is only a hint; for example, it does not override the Content-Language header of a HTTP response obtained by actually following the link. Multiple "hreflang" parameters on a single linkvalue indicate that multiple languages are available from the indicated resource.The "media" parameter, when present, is used to indicate intended destination medium or media for style information (see [W3C.REC-html401-19991224], Section 6.13). Note that this may be updated by [W3C.CR-css3-mediaqueries-20090915]). Its value MUST be quoted if it contains a semicolon (";") or comma (","), and there MUST NOT be more than one "media" parameter in a link-value.The "title" parameter, when present, is used to label the destination of a link such that it can be used as a human-readable identifier (e.g., a menu entry) in the language indicated by the Content-Language header (if present). The "title" parameter MUST NOT appear more than once in a given link-value; occurrences after the first MUST be ignored by parsers.The "title*" parameter can be used to encode this label in a different character set, and/or contain language information as per [RFC5987]. The "title*" parameter MUST NOT appear more than once in a given link-value; occurrences after the first MUST be ignored by parsers. If the parameter does not contain language information, its language is indicated by the Content-Language header (when present).If both the "title" and "title*" parameters appear in a link-value, processors SHOULD use the "title*" parameter’s value.The "type" parameter, when present, is a hint indicating what the media type of the result of dereferencing the link should be. Note that this is only a hint; for example, it does not override the Content-Type header of a HTTP response obtained by actually following the link. There MUST NOT be more than one type parameter in a link-value.Aside on the interpretation of URIs (httpRange14 again?)This use of the term `resource' for both referring to non-Web accessible things and for naming Web-accessible things is continued in URI RFC 3986, which states that “this specification does not limit the scope of what might be a resource; rather, the term `resource'... likewise, abstract concepts can be resources, such as the operators and operands of a mathematical equation, the types of a relationship (e.g., `parent' or `employee'), or numeric values (e.g., zero, one, and infinity)” “The key feature of the Semantic Web is not its use of knowledge representation technologies like ontologies and inference per se, but the introduction of these technologies to operate over Web resources as defined by URIs… It is this ability to name things with URIs that aren't Web-accessible that defines both the Semantic Web and Linked Data. However, unlike traditional Semantic Web applications, Linked Data allows Web-accessible associated descriptions, in both machine and human-readable forms, to be accessed from a URI for a non-information resource.” Halpin and Presutti, 2009Berners-Lee broadened the concept of resource in RFC 2396, stating that “a resource can be anything that has identity. Familiar examples include an electronic document, an image, a service (e.g., `today's weather report for Los Angeles'), and a collection of other resources. Not all resources are network `retrievable'; e.g., human beings, corporations, and bound books in a library can also be considered resources"There has been an ongoing debate in the W3C community on how to distinguish a URI that identifies the particular resource that will be retrieved when the URI is dereferenced from a URI that identifies a resource that cannot be transmitted electronically, but will return some representation of that resource (http range-14, recently reignited as awwsw/issue57). Both the range14 ‘303 redirect’ solution and the hash-tag pattern are in use, both with semantic implication as well as based on the original web page navigation conventions under which 303 and hash tags were originally defined. Thus, in order to correctly interpret information vs. non-information URIs still requires a priori agreement on the conventions that are used by a particular URI minter.Minters of URI schemes should define what URIs identify/name an information resource (direct access) and what URIs name a non information resource. For non information resource, URI minter dictates what the representation options are. Various URI schemes should have equivalent of MIME type that identifies a URI handler that is familiar with that particular scheme and knows how to deference to get correct representation in a given context, and what to do with the response message.A given namespace may employ either the hash convention or 303 redirection, since according to the W3C, namespace resources are not information resources but an abstract space of infinite names (Halpin and Presutti, 2009). This suggests that conventions should be defined as part of a namespace definition, and a resolvable namespace URI should provide some indication of the convention for that namespace in the namespace representation.Protocol for Web Description Resources (POWDER) purpose of the Protocol for Web Description Resources (POWDER) is to provide a means for individuals or organizations to describe a group of resources through the publication of machine-readable metadata, as motivated by the POWDER Use Cases [USECASES]. This document details the creation and lifecycle of Description Resources (DRs), which encapsulate such metadata. These are typically represented in a highly constrained XML dialect that is relatively human-readable. The meaning of such DRs is underpinned by formal semantics, accessible by performing a GRDDL Transform.POWDER has evolved from the data model developed for the final report [XGR] of the Web Content Label Incubator Group [WCL-XG], from which we define a Description Resource as: "a resource that contains a description, a definition of the scope of the description and assertions about both the circumstances of its own creation and the entity that created it."POWDER takes a very broad approach so that it is possible for both the resource creator and third parties to make assertions about all kinds of things, with no architectural limits on what they are making claims about. In practice, POWDER associates a description with one or more IRIs [IRI] that must then be interpreted as being descriptions of the resources dereferenced from those IRIs. The tension between what can be processed by humans and what can be processed by machines is resolved by defining both operational and formal semantics of Description Resources, and by bridging much of the gap between the two by way of a GRDDL transform that is associated with the root POWDER namespace.Trust is a central theme of POWDER. POWDER provides support for, and is amenable to, a variety of methods through which users and user agents can establish trust.ATOM LinkThe "atom:link" element defines a reference from an entry or feed to a Web resource. This specification assigns no meaning to the content (if any) of this element.atomLink = element atom:link { atomCommonAttributes, attribute href { atomUri }, attribute rel { atomNCName | atomUri }?, attribute type { atomMediaType }?, attribute hreflang { atomLanguageTag }?, attribute title { text }?, attribute length { text }?, undefinedContent }atomCommonAttributes = attribute xml:base { atomUri }?, attribute xml:lang { atomLanguageTag }?, undefinedAttribute*undefinedAttribute = attribute * - (xml:base | xml:lang | local:*) { text }undefinedContent = (text|anyForeignElement)*anyForeignElement = element * - atom:* { (attribute * { text } | text | anyElement)*atomUri = textContent elements4.2.7.1. The "href" AttributeThe "href" attribute contains the link's IRI. atom:link elements MUST have an href attribute, whose value MUST be a IRI reference [RFC3987].4.2.7.2. The "rel" Attributeatom:link elements MAY have a "rel" attribute that indicates the link relation type. If the "rel" attribute is not present, the link element MUST be interpreted as if the link relation type is "alternate".The value of "rel" MUST be a string that is non-empty and matches either the "isegment-nz-nc" or the "IRI" production in [RFC3987]. Note that use of a relative reference other than a simple name is not allowed. If a name is given, implementations MUST consider the link relation type equivalent to the same name registered within the IANA Registry of Link Relations (Section 7), and thus to the IRI that would be obtained by appending the value of the rel attribute to the string "". The value of "rel" describes the meaning of the link, but does not impose any behavioral requirements on Atom Processors.This document defines five initial values for the Registry of Link Relations:alternate: signifies that the IRI in the value of the href attribute identifies an alternate version of the resource described by the containing element. related: signifies that the IRI in the value of the href attribute identifies a resource related to the resource described by the containing element. For example, the feed for a site that discusses the performance of the search engine at "" might contain, as a child of atom:feed: <link rel="related" href=""/>. An identical link might appear as a child of any atom:entry whose content contains a discussion of that same search engine.self: signifies that the IRI in the value of the href attribute identifies a resource equivalent to the containing element.enclosure: signifies that the IRI in the value of the href attribute identifies a related resource that is potentially large in size and might require special handling. For atom:link elements with rel="enclosure", the length attribute SHOULD be provided.via: signifies that the IRI in the value of the href attribute identifies a resource that is the source of the information provided in the containing element.4.2.7.3. The "type" AttributeOn the link element, the "type" attribute's value is an advisory media type: it is a hint about the type of the representation that is expected to be returned when the value of the href attribute is dereferenced. Note that the type attribute does not override the actual media type returned with the representation. Link elements MAY have a type attribute, whose value MUST conform to the syntax of a MIME media type [MIMEREG].4.2.7.4. The "hreflang" AttributeThe "hreflang" attribute's content describes the language of the resource pointed to by the href attribute. When used together with the rel="alternate", it implies a translated version of the entry. Link elements MAY have an hreflang attribute, whose value MUST be a language tag [RFC3066].4.2.7.5. The "title" AttributeThe "title" attribute conveys human-readable information about the link. The content of the "title" attribute is Language-Sensitive. Entities such as "&amp;" and "&lt;" represent their corresponding characters ("&" and "<", respectively), not markup. Link elements MAY have a title attribute.4.2.7.6. The "length" AttributeThe "length" attribute indicates an advisory length of the linked content in octets; it is a hint about the content length of the representation returned when the IRI in the href attribute is mapped to a URI and dereferenced. Note that the length attribute does not override the actual content length of the representation as reported by the underlying protocol. Link elements MAY have a length attribute.ReferencesGregorio, J.C., and deHora, B., editors, 2007, The Atom Publishing Protocol: IETF RFC 5023.Halpin, Harry, and Presutti, Presutti, 2009, An Ontology of Resources for Linked Data: LDOW 2009, April 20–24, 2009, Madrid, Spain, ACM 978-1-60558-487-4/09/04. <accessed at , 09/03/2011>Nottingham, M., IETF, 2010, Web Linking: IETF RFC 5988, ISSN:2070-1721.ISO19115 WG, in prep, ISO 19115-1 Geographic information — Metadata – Part 1: Fundamentals: ISO TC211 N3071ISO19119, 2005-02-15, Geographic Information—Services.ISO19119:2005/Amd.1, 2008-05-01, Geographic information — Services, AMENDMENT 1: Extensions of the service metadata model.Archer, Phil, Smith, Kevin, Perego, Andrea, 2009, Protocol for Web Description Resources (POWDER): Description Resources: accessed at (2011-09-03). ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download