The Fresnel Selector Language (FSL) is a language for modeling traversal paths in RDF graphs. It is used as a selector language for the Fresnel display vocabulary for RDF. FSL does not depend on a specific serialization of RDF. It is inspired by the XPath Recommendation [XPath] and RDFPath language proposals but is not intended to be a full RDFPath language, though it could be extended to become one.
The Fresnel Selector Language (FSL) is a language for modeling traversal paths in RDF graphs. FSL is inspired by the XPath Recommendation [XPath] and RDFPath language proposals but is not intended to be a full RDFPath language, though it could be extended to become one. It has been designed to address the specific requirements of a path language for the Fresnel RDF display vocabulary and tries to be as simple as possible, reusing as many XPath concepts and syntactic constructs as possible while adapting them to the graph-based RDF data model.
FSL considers RDF models as directed labeled graphs according to the Resource Description Framework (RDF): Concepts and Abstract Syntax Recommendation and does not depend on any serialization of RDF. FSL expressions represent traversal paths in RDF graphs.
FSL is syntactically and semantically compatible with Fresnel's Basic Selectors (Simple RDF Naming) and the latter can be considered as a very limited subset of what can be expressed with FSL.
RDF models are considered as directed labeled graphs, made of nodes (resources and literals) and arcs (properties). In the remainder of this document we will use the general term graph entity to refer to both nodes and arcs of a graph.
An FSL expression represents a path from one graph entity to another. A path is made of location steps. Locations steps are made of an optional axis specifier (see 2.3 Axes), a type test (see 2.2 Location Steps), and optional predicates following this syntax:
The term predicate is to be interpreted as a filtering condition on a location step, as XPath predicates. It is not to be interpreted as the RDF reification term (as in "statements are made of a subject, a predicate, and an object").
The term QName refers to qualified names as defined by the W3C Recommendation on Namespaces in XML.
The Notation 3 syntax for RDF is used throughout this document to show examples.
This section is an informal introduction to FSL and contains examples that should give a general idea of the language to the reader. A more formal definition of the language's syntax and semantics is presented in sections 2 to 6.
FSL uses a syntax close to that of XPath 1.0 [XPath]. The main difference is that arcs are explicitly represented as location steps in FSL paths, contrary to XPath. The latter only represents nodes as location steps, as there is only one kind of relation between nodes in an XML tree: the parent-child relation, which is thus implicit.
As an example of this explicit representation of arcs as location steps in FSL, the following expression represents a path starting at a resource, traversing a foaf:knows arc, reaching a resource, traversing an rdf:type arc and reaching a resource. The exact interpretation of such a path depends on its context of use. Location steps representing nodes (i.e. resources) are colored in blue, location steps representing arcs (i.e. properties) are colored in red.
The following are examples of FSL expressions and their interpretation depending on their context of use in Fresnel.
:exampleLens a fresnel:Lens; # exampleLens' domain: all resources :exampleLens fresnel:instanceLensDomain "*"^^fresnel:fslselector. # exampleLens' domain: all resources of type foaf:Person :exampleLens fresnel:instanceLensDomain "foaf:Person"^^fresnel:fslselector. # exampleLens' domain: all resources of type foaf:Person that foaf:knows another resource :exampleLens fresnel:instanceLensDomain "foaf:Person[foaf:knows]"^^fresnel:fslselector. # exampleLens' domain: all resources of type foaf:Person that foaf:knows another resource of type foaf:Person :exampleLens fresnel:instanceLensDomain "foaf:Person[foaf:knows/foaf:Person]"^^fresnel:fslselector. # properties to be shown for resources handled by this lens: dc:title :exampleLens fresnel:showProperties "dc:title"^^fresnel:fslselector. # properties to be shown for resources handled by this lens: all properties :exampleLens fresnel:showProperties "*"^^fresnel:fslselector. # properties to be shown for resources handled by this lens: foaf:knows properties, provided that # their value is a resource typed as a foaf:Person :exampleLens fresnel:showProperties "foaf:knows[foaf:Person]"^^fresnel:fslselector.
All FSL expressions are paths that link graph entities (i.e., nodes or arcs) to other graph entities in the same graph. Paths describe how to reach a target entity from a source entity. FSL expressions can be used to point at target entities from known entities or more generally model conditions on the selection of entities in an RDF model.
In all cases, an FSL expression is to be evaluated against of set of entities that represent potential starting points for the path. This set, called the primary selection, can either be a set of nodes in the graph or a set of arcs. A full RDFPath language needs to offer means to explicitly specify this set. When used in Fresnel, the primary selection associated with an FSL expression is defined implicitly by its context of use as follows:
FSL could be extended so as to allow the explicit specification of the primary selection. Such an extension is however not described here, as our primary goal is to keep the language as simple as possible in the context of its use in Fresnel.
An FSL expression represents a path from a graph entity (i.e. a node or arc) to another graph entity, passing by an arbitrary number of other graph entities. Each step on the path is called a location step. As mentioned earlier, FSL paths explicitly represent both nodes and arcs as location steps, as it is desirable to be able to constrain the type of arcs a path should traverse (something that is not relevant in XPath as the only relation between the nodes of an XML tree is the parent-child relation which bears no explicit semantics). In the following FSL expressions, node location steps are colored in blue, arc location steps are colored in red.
A node location step can only be followed by an arc location step. An arc location step can only be followed by a node location step.
Having two kinds of location steps introduces ambiguities. For instance, there is an ambiguity about what the following expression selects:
Does it select the foaf:knows property instances of any subject resource? Or does it select the resource foaf:knows (of type rdf:Property as it might occur in a model using the RDF-S vocabulary), provided that it is the object of at least one statement involving any property? In other words, is it to be interpreted as */foaf:knows or */foaf:knows ?
Such ambiguities are solved in Fresnel by the context of use of the FSL expression, which gives the nature of the primary selection and thus constrains the first (and therefore all) location step(s) (see First Location Step in Fresnel later in this document for details). The interpretation of FSL expressions outside the Fresnel context is out of the scope of this document, and is the prerogative of each application that wants to use or extend FSL.
In XPath, a QName used as a location step is to be interpreted as an equality constraint on the name of XML elements. The name of an XML element reflects its type. It is not a unique element identifier. A natural adaptation of this to RDF and FSL is to interpret QNames used as node location steps as constraints on the type (i.e. the class) of RDF resources.
Note: the other option would have been to interpret QNames as node location steps as constraints on the URI of RDF resources, rather than constraints on their type. This intepretation is however conceptually further away from the XPath/XML model, and more importantly is less relevant, as constraining the URI of a resource on the path is seldom interesting (and can still be achieved with predicates involving function uri() as shown in 4 Core Function Library).
Symbol * as a type test has the following meaning:
A QName as a type test has the following meaning:
Therefore, location steps of the form:
could also be written as (verbose syntax):
More generally, location steps of the form:
where "..." represent a set of predicates applied to the location step could also be written as (verbose syntax):
Function exp() takes a QName and returns the corresponding fully expanded URI (see 4 Core Function Library). The use of function exp() is not mandatory. It is possible instead to use the full URI directly, as shown in the examples below.
The following examples illustrate both the standard and verbose syntaxes. The verbose syntax is presented only to illustrate the semantics of the standard syntax and show that resource type conditions can be expressed in an alternate way. However, although expressions using the verbose form will be interpreted by an FSL engine, there is no advantage in using it.
# properties to be shown for resources handled by this lens: foaf:knows provided # that the value if of type foaf:Person (all three expressions are equivalent) foaf:knows[foaf:Person] foaf:knows[*[rdf:type/*[uri(.) = exp('foaf:Person')]] foaf:knows[*[rdf:type/*[uri(.) = 'http://xmlns.com/foaf/0.1/Person']] # exampleLens' domain: all foaf:Person instances that foaf:knows something # (all three expressions are equivalent) foaf:Person[foaf:knows] *[rdf:type/*[uri(.)=exp('foaf:Person')] and foaf:knows] *[rdf:type/*[uri(.)='http://xmlns.com/foaf/0.1/Person'] and foaf:knows] # exampleStyle's domain: all resources of type rss:item grouped in a list, that # have both a title and a description (all three expressions are equivalent) */rdf:li/rss:item[rss:title and rss:description] */rdf:li/*[rdf:type/*[uri(.) = exp('rss:item')] and rss:title and rss:description] */rdf:li/*[rdf:type/*[uri(.) = 'http://purl.org/rss/1.0/item'] and rss:title and rss:description]
A path can start with a node location step or an arc location step. A path can end with a node location step or an arc location step, no matter the type of the initial location step. However, the first location step must be compatible with the primary selection:
In the context of Fresnel, the start and end location steps should also meet the following requirements depending on the FSL expression's context of interpretation:
Some examples follow (we only give the FSL expressions, not the full Fresnel statements).
# properties to be shown for resources handled by a lens: foaf:knows foaf:knows # properties to be shown for resources handled by this lens: foaf:knows provided # that the value is of type foaf:Person foaf:knows[foaf:Person] # properties to be shown for resources handled by this lens: the Class of things # known by the current resource. More formally, this will show the class of things that are the # object of a foaf:knows statement involving the current resource as their subject foaf:knows/*/rdf:type # exampleLens' domain: all foaf:Person instances older than 60 foaf:Person[ex:age/text() > 60] # exampleStyle's domain: all resources of type rss:item grouped in a list, that # have both a title and a description */rdf:li/rss:item[rss:title and rss:description]
The following table summarizes these requirements.
Expression Evaluation Context | Primary Selection | First location step | Last location step | Returns |
fresnel:showProperties | All properties associated with the current resource | Arc | Arc | The properties identified by the last location step |
fresnel:hideProperties | All properties associated with the current resource | Arc | Arc | The properties identified by the last location step |
fresnel:instanceLensDomain | All resources in the RDF model to be displayed | A single node location step | The resources identified by the location step | |
fresnel:instanceFormatDomain | All resources in the RDF model to be displayed | A single node location step | The resources identified by the location step | |
fresnel:sublens | All resources typed as fresnel:Lens (or a subclass of) in the Fresnel transformation RDF model | A single node location step | The resources identified by the location step |
XPath features axes such as descendant, ancestor, and parent to address the context or content of a node. FSL features two axes that are used to walk the graph forward or backward, respectively named out and in.
In the above definitions, the term current resource/node refers to:
The term current property/arc refers to:
The axis can be omitted for any location step. An arc location step missing explicit axis information is considered to be on the out axis. A node location step missing explicit axis information is considered to be on the same axis as the previous arc location step. A node location step at the beginning of a path (i.e. for which there is no such previous arc location step) is not considered to be on any particular axis.
# All foaf:knows properties which have the current resource as their subject. # This will display all resources known by the resource on which the lens is applied. :exampleLens fresnel:showProperties ("out::foaf:knows"^^fresnel:fslselector). # The above can be abrreviated :exampleLens fresnel:showProperties ("foaf:knows"^^fresnel:fslselector). # All foaf:knows properties which have the current resource as their object. # This will display all resources that know the resource on which the lens is applied. :exampleLens fresnel:showProperties ("in::foaf:knows"^^fresnel:fslselector). # The surname of all resources that know the resource on which the lens is applied. :exampleLens fresnel:showProperties ("in::foaf:knows/*/out::foaf:surname"^^fresnel:fslselector). # Note that in the previous example, the axis of the 2nd location step (a node location step) # is in according to the above-stated rule, since the axis of the previous # arc location step is in. The previous expression could have been written as: :exampleLens fresnel:showProperties ("in::foaf:knows/in::*/out::foaf:surname"^^fresnel:fslselector). # The domain of this lens is all ex:Pet known by other resources typed as foaf:Person :exampleLens fresnel:instanceLensDomain "ex:Pet[in::foaf:knows/in::foaf:Person]"^^fresnel:fslselector. # Removing axis declarations that can be omitted, we get: :exampleLens fresnel:instanceLensDomain "ex:Pet[in::foaf:knows/foaf:Person]"^^fresnel:fslselector. # The domain of this lens is all foaf:Person resources that know resources that belong to any class # but that are themselves known by at least one other foaf:Person resource (i.e. at least two including # the current one). The out axis is already omitted in this example. :exampleLens fresnel:instanceLensDomain "foaf:Person[foaf:knows/*[count(in::foaf:knows/foaf:Person) > 2]]"^^fresnel:fslselector.
As we have seen in several prior examples, predicates can be associated with each location step of a path to express further selection conditions on nodes and arcs. As in XPath, predicates are syntactially grouped together between square brackets after the location step's type test (see 1.1 Terminology).
# the domain of this lens is all resources that have both # a foaf:surname property and a foaf:firstName property :exampleLens fresnel:instanceLensDomain "*[foaf:surname and foaf:firstName]"^^fresnel:fslselector. # the domain of this lens is all foaf:Person resources that are # known by another resource, that know another resource, or both :exampleLens fresnel:instanceLensDomain "foaf:Person[foaf:knows or in::foaf:knows]"^^fresnel:fslselector.
The conditions that make the predicates of a location step can be intepreted conjunctively or disjunctively using keywords and and or, respectively. Each condition is an expression. There are different kinds of expressions:
FSL path expressions: an FSL path expression as a predicate is interpreted as an existential condition on the nodes or arcs described by this path, intepreted relatively to the current node or arc, i.e. the node or arc selected by the location step on which the predicate applies. The condition is considered as fulfilled if the path points to at least one existing graph entity. The last location step of an FSL path used in this context can refer to a literal as shown in the following example.
# domain: all foaf:Person resources that have an ex:age property value of "47"
:exampleLens fresnel:instanceLensDomain "foaf:Person[ex:age/"47"]"^^fresnel:fslselector.
text() can be used as the last location step and represents any literal value.
# domain: all foaf:Person resources that are older than 60
:exampleLens fresnel:instanceLensDomain "foaf:Person[ex:age/text() > 60]"^^fresnel:fslselector.
As shown in the previous example, function number() defined in 4 Core Function Library can be used to convert a literal's value into a number that can be used as an operand of a number comparison operation.
Comparison expressions are evaluated by comparing the objects that result from evaluating the two operands. The comparison of the objects resulting from the evaluation is defined as follows:
An or expression is evaluated by evaluating each operand and converting its value to a boolean as if by a call to the boolean function. The result is true if either value is true and false otherwise. The right operand is not evaluated if the left operand evaluates to true.
An and expression is evaluated by evaluating each operand and converting its value to a boolean as if by a call to the boolean function. The result is true if both values are true and false otherwise. The right operand is not evaluated if the left operand evaluates to false.
As a reminder, the term graph entity refers indifferently to nodes and arcs. We use graph-entity-set to refer to a set of nodes or a set of arcs (but not a set of nodes or arcs).
Function: number count(graph-entity-set)
The count function returns the number of nodes or arcs in the argument node-set or arc-set.
# Lens domain: all foaf:Person resources that are # the subject of more than 2 foaf:knows statements :exampleLens fresnel:instanceLensDomain "foaf:Person[count(foaf:knows) > 2]"^^fresnel:fslselector. # Show foaf:knows properties that point to resources that themselves # are the subject of at least 4 foaf:knows statements :exampleLens fresnel:showProperties ("foaf:knows[*[count(foaf:knows) >= 4]]"^^fresnel:fslselector).
Function: string local-name(graph-entity-set)
The local-name function returns the local part of the expanded-name of the node or arc in the argument graph-entity-set that it finds first (order is not guaranteed). If the argument node-set or arc-set is empty or the first node or arc has no expanded-name, an empty string is returned.
Function: string namespace-uri(graph-entity-set)
The namespace-uri function returns the namespace URI of the expanded-name of the node or arc in the argument graph-entity-set that it finds first (order is not guaranteed). If the argument node-set or arc-set is empty or the first node or arc has no expanded-name, or the namespace URI of the expanded-name is null, an empty string is returned.
Function: string uri(graph-entity-set)
The uri function returns the full URI of the expanded-name of the node or arc in the argument graph-entity-set that it finds first (order is not guaranteed). If the argument node-set or arc-set is empty or the first node or arc has no expanded-name, an empty string is returned.
# Apply the lens to the resource identified by http://example.org/foo#bar :exampleLens fresnel:instanceLensDomain "*[uri(.) = 'http://example.org/foo#bar']"^^fresnel:fslselector. # Apply the lens to the resource of type foaf:Person, identified by http://example.org/people#john :exampleLens fresnel:instanceLensDomain "foaf:Person[uri(.) = 'http://example.org/people#john']"^^fresnel:fslselector.
Function: string exp(string)
The exp function returns the fully expanded URI corresponding to the QName given as the argument string. Namespace prefix bindings used for this operation are the same as the ones used to expand location step type test QNames (see Namespace Prefix Binding Resolution).
# Apply the lens to the resource identified by http://www.foo.org#bar
# (prefix foo: is bound to namespace URI http://www.foo.org#)
:exampleLens fresnel:instanceLensDomain "*[uri(.) = exp('foo:bar')]"^^fresnel:fslselector.
Function: string literal-value(arc-set)
The literal-value function takes property instances as argument and returns the property value associated with the arc it finds first (order is not guaranteed), provided that the object is a literal. If the object is not a literal, an empty string is returned. If the argument arc-set is empty, an empty string is returned.
# The lens applies to foaf:Person resources that know # foaf:Person resources, whose surname is Smith :exampleLens fresnel:showProperties ("foaf:Person[foaf:knows/foaf:Person[literal-value(foaf:surname) = 'Smith']]"^^fresnel:fslselector). # This is equivalent to: :exampleLens fresnel:showProperties ("foaf:Person[foaf:knows/foaf:Person[foaf:surname/text() = 'Smith']]"^^fresnel:fslselector).
Function: string literal-dt(arc-set)
The literal-dt function takes property instances as argument and returns the property value's datatype URI associated with the arc it finds first (order is not guaranteed), provided that the object is a literal. If the object is not a literal, an empty string is returned. If the argument arc-set is empty, an empty string is returned.
Function: boolean starts-with(string, string)
The starts-with function returns true if the first argument string starts with the second argument string, and otherwise returns false.
# The lens applies to resources that have a dc:title that starts with "How to"
:exampleLens fresnel:instanceLensDomain "*[starts-with(literal-value(dc:title), 'How to')]"^^fresnel:fslselector.
Function: boolean contains(string, string)
The contains function returns true if the first argument string contains the second argument string, and otherwise returns false.
# The lens applies to resources that have a dc:title that contains "improving"
:exampleLens fresnel:instanceLensDomain "*[contains(literal-value(dc:title), 'improving')]"^^fresnel:fslselector.
Function: string concat(string, string, string* )
The concat function returns the concatenation of its arguments.
Function: string substring-before(string, string)
The substring-before function returns the substring of the first argument string that precedes the first occurrence of the second argument string in the first argument string, or the empty string if the first argument string does not contain the second argument string. For example, substring-before("1999/04/01","/")
returns 1999
.
Function: string substring-after(string, string)
The substring-after function returns the substring of the first argument string that follows the first occurrence of the second argument string in the first argument string, or the empty string if the first argument string does not contain the second argument string. For example, substring-after("1999/04/01","/")
returns 04/01
, and substring-after("1999/04/01","19")
returns 99/04/01
.
Function: string substring(string, number, number?)
The substring function returns the substring of the first argument starting at the position specified in the second argument with length specified in the third argument. For example, substring("12345",2,3) returns "234". If the third argument is not specified, it returns the substring starting at the position specified in the second argument and continuing to the end of the string. For example, substring("12345",2) returns "2345".
More precisely, each character in the string is considered to have a numeric position: the position of the first character is 1, the position of the second character is 2 and so on.
NOTE: This differs from Java and ECMAScript, in which the String.substring method treats the position of the first character as 0.
Function: number string-length(string)
The string-length returns the number of characters in the string.
# Display dc:title properties that are no longer than 50 characters
:exampleLens fresnel:showProperties ("dc:title[string-length(literal-value(.)) <= 50]"^^fresnel:fslselector).
Function: string normalize-space(string)
The normalize-space function returns the argument string with whitespace normalized by stripping leading and trailing whitespace and replacing sequences of whitespace characters by a single space. Whitespace characters are the same as those allowed by the S production in XML.
# Display dc:title properties that are no longer than
# 50 characters after white space normalization
:exampleLens fresnel:showProperties ("dc:title[string-length(normalize-space(literal-value(.))) <= 50]"^^fresnel:fslselector).
Function: number number(object)
The number function converts its argument to a number as follows:
a string that consists of optional whitespace followed by an optional minus sign followed by a Number followed by whitespace is converted to the IEEE 754 number that is nearest (according to the IEEE 754 round-to-nearest rule) to the mathematical value represented by the string; any other string is converted to NaN
a literal node is converted to a string by taking its lexical value. That string is converted to a number following the above rule.
Function: boolean boolean(object)
The boolean function converts its argument to a boolean as follows:
a number is true if and only if it is neither positive or negative zero nor NaN
a node-set or arc-set is true if and only if it is non-empty
a string is true if and only if its length is non-zero
Function: boolean not(boolean)
The not function returns true if its argument is false, and false otherwise.
# The lens' domain is all resources that do not have a Dublin Core subject property :exampleLens fresnel:instanceLensDomain "*[not(boolean(dc:subject))]"^^fresnel:fslselector. # The lens' domain is all resources that do not have a Dublin Core subject property # and do not have a Dublin Core title property :exampleLens fresnel:instanceLensDomain "*[not(boolean(dc:subject) or boolean(dc:title))]"^^fresnel:fslselector.
Function: boolean true()
The true function returns true.
Function: boolean false()
The false function returns false.
RDF Schemas and OWL ontologies describe the concepts of a domain in terms of classes and the relationships that exist between these concepts in terms of properties. Classes can be defined as subclasses of other classes using rdfs:subClassOf. Similarly, properties can be defined as subproperties of other properties using rdfs:subPropertyOf. Provided that an RDF Schema or OWL ontology is available and retrievable at the time of execution for a given vocabulary, FSL implementations should exploit subclass and subproperty relationships explicitly stated in these models when the type test QName is prefixed by ^:
FSL engines should take into account RDFS/OWL subclass/subtype information when available, but are not required to.
# properties to be shown for resources handled by this lens: all foaf:knows properties # as well as properties declared as subproperties of foaf:knows (in the associated schema) ^foaf:knows # exampleLens' domain: all instances of class foaf:Person (or any of its subclasses) older than 60 ^foaf:Person[ex:age/text() > 60] # properties to be shown for resources handled by this lens: foaf:knows and any subproperty of foaf:knows, # provided that the value is an instance of class foaf:Person or one of its subclasses ^foaf:knows[^foaf:Person]
Instances of subclasses should only be selected when the type test QName is prefixed by ^. The same applies to properties/subproperties. The default behaviour (i.e., when there is not prefix in front of the QName) is not to select instances of subclasses/subproperties.
The RDF abstract syntax reflects RDF's graph-based data model which is independent of any serialization syntax. FSL operates on an RDF model as a directed labeled graph.
The graph contains nodes and directed labeled arcs. There are three types of nodes:
Literals can be plain or typed. Typed literal have a datatype URI. See [RDF-CAS] 6.5 RDF Literals for more details.
FSL path expressions whose last location step is a node location step return the set of nodes in the graph that can be reached following the path(s) described by the FSL expression starting from a graph entity in the primary selection. FSL does not allow location steps describing literals, except as the last step of path expressions used in predicates of other location steps. This means that an FSL expression never returns literals.
An arc represents a property and is labeled by a URI reference which indicates the property's type.
It is important to understand that FSL considers every arc as a first class object. Thus,
*[uri(.) = 'http://example.org/foo']/foaf:knows
refers to the set of arcs labeled by the URI whose QName is foaf:knows, and that originate from the resource whose URI reference is http://example.org/foo. What the following expression returns is a set containing all these arcs, considered here as property instances, which all share the same property type: the one identified by URI http://xmlns.com/foaf/0.1/knows.
Property URIs as arc location steps are represented by QNames using namespace prefix bindings, as shown in all examples in this document. The binding declarations occur outside the FSL expression. In Fresnel, bindings are declared explicitly in the RDF model (not just in its RDF/XML serialization). An FSL processor is free to get binding declarations from the RDF/XML document (if it exists), but in case of conflicting declarations between the RDF model level and the RDF/XML document, the RDF model bindings prevail.
The same thing applies to node location steps, which use QNames as class/type constraints (type test), to literal datatype URI references written as QNames, and to QName expansion with function exp().
IsaViz has an implementation of the FSL grammar based on ANTLR. It can be downloaded from the IsaViz CVS Repository. A compiled version will be made available as a JAR file soon. The grammar is given here using the EBNF notation.
LocationPath | ::= | Step ('/' Step)* |
Step | ::= | (Axis)? Test (Predicate)* |
| AbbreviatedSelf | ||
| Literal | ||
| 'text()' | ||
Axis | ::= | AxisName '::' |
AxisName | ::= | ('in' | 'out') |
Test | ::= | TypeTest |
TypeTest | ::= | AnyName |
| ('^')? ((NCName)? ':')? NCName | ||
AnyName | ::= | ((NCName)? ':')? '*' |
Predicate | ::= | '[' OrExpr ']' |
OrExpr | ::= | AndExpr ('or' OrExpr)? |
AndExpr | ::= | CompExpr ('and' AndExpr)? |
CompExpr | ::= | UnaryExpr (Operator UnaryExpr)? |
UnaryExpr | ::= | FunctionCall |
| Number | ||
| LocationPath | ||
Operator | ::= | ('=' | '!=' | '<' | '>' | '<=' | '>=') |
FunctionCall | ::= | FunctionName '(' Arguments ')' |
Arguments | ::= | (UnaryExpr ("," UnaryExpr)*)? |
Literal | ::= | '"' [^"]* '"' (Datatype)? |
| "'" [^']* "'" (Datatype)? | ||
Datatype | ::= | '^^' NCName ':' NCName |
AbbreviatedSelf | ::= | '.' |
Number | ::= | Digits ('.' Digits?)? |
| '.' Digits | ||
Digits | ::= | [0-9]+ |
[XPath]World Wide Web Consortium. XML Path Language (XPath) Version 1.0. W3C Recommendation. See http://www.w3.org/TR/xpath.
[IEEE 754] Institute of Electrical and Electronics Engineers. IEEE Standard for Binary Floating-Point Arithmetic. ANSI/IEEE Std 754-1985.
RDFPath Language Proposals and Related Work
$Id: Overview.html,v 1.5 2005/11/18 17:41:46 ryanlee Exp $