W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > April to June 2004

RE: UC&R draft: 1.31 -- Requirement 4.1

From: Seaborne, Andy <andy.seaborne@hp.com>
Date: Tue, 4 May 2004 14:32:55 +0100
Message-ID: <E864E95CB35C1C46B72FEA0626A2E808028A3341@0-mail-br1.hpl.hp.com>
To: Jean-François Baget <jean-francois.baget@inrialpes.fr>, public-rdf-dawg@w3.org

-------- Original Message --------
> From: public-rdf-dawg-request@w3.org <>
> Date: 
> About requirement
> > 4.1 Multi-edged Paths
> > A query language must include the ability to match paths through an
> RDF graph where the number of arcs > traversed is greater than one, as
> well as single one-edge paths. The query language may still
> only have >
> paths of fixed length in the query or may cover paths of
> variable length
> (e.g. transitive closures).
> I think we have discussed and agreed on the fact that a query should
> include multiple triples (i.e. The query is an arbitrary RDF graph/set
> of triples instead of a single atomic triple).
> This goes a bit further: Am I right to assume that you intend to match
> "variable length triples" such as:
> ex:someUrirefSubject (ex:someUrirefProperty)+ _someVariable .
> Where _someVariable must be matched to a node being the end
> of a path of
> one or more arcs labelled by ex:someUrirefProperty, the first node of
> the path being labelled by  ex:someUrirefSubject .

Firstly, I found it hard to come up with good wording for the whole
community.  In trying to writeup what I thought the requirements was (not
what it could be), I may not have captuted the essence very well.  Your
"multiple triples" covers it quite well - maybe this is a better

It was not my intention to have an opinion one way or the other on (prop)+
(hence the transisitive closure example).  I was trying to say that query is
not just single triples.  I wanted to allow for later decisions of fixed
path length expressions or for transitiveity in the query.

Maybe it would be better to change (after the publication for community
discussion) from talk of paths to talk about graph patterns then discuss the
graph pattern capabilities.

Examples of "paths":

(?x vcard:N ?a) (?a vcard:familyName "Smith")
This a simple path of length 2.  Reads as forward arcs.
May be nice to write as (?x vcard:N-->vcard:familyName "Smith") where ?a is
not used elsewhere.

(?x foaf:name "Name") (?x foaf:mbox mailto:...)
Its path of length two if you allow reverse arcs but not if the def of path
means forward arcs.

(?x foaf:name "Name") (?x foaf:mbox mailto:...) (?x foaf:knowns ...)
Not a linear pattern.

> In that case, should the query be an arbitrary set of "variable length
> triples" or just "atomic variable length triples"?
> Then, since we already included all the algorithmic
> difficulty, could it
> be interesting to express the "variable length property" by
> any algebric
> expression?

Also, from a syntax point of view (it maybe sugaring but we have a
requirement for readable queries) do we include value constrainst in the

> I do not remember this to be discussed in Amsterdam... But it could be
> interesting. Any use case that is covered by this?

The discussion came up on list before the F2F:

IIRC it was more about being clear we were not limited to the simple case of
triples from one node in the graph - my memory may be off on this.

> Jean-François Baget
> INRIA Rhône-Alpes
> jean-francois.baget@inrialpes.fr
> Tel: 04 76 61 53 27

Thanks for bringing this up - we are going to have to be clear,

Received on Tuesday, 4 May 2004 09:33:57 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:00:26 UTC