Hello Tim,
[Copying the fresnel-dev_at_simile list]
Tim Berners-Lee wrote:
[...]
> I was looking at Fresnel for possible use with the AJAR tabulator I
> have been playing with.
>
> http://www.w3.org/2005/ajar/tab
>
> The Fresnel language seems to make sense. I was concerned about FSL,
> though, not really wanting to have to write a new parser.
I'm not sure I understand what you mean here. Are you concerned about
having to support FSL in a Fresnel implementation you would write ? What
we say in the Fresnel spec is that FSL *should* be supported by Fresnel
implementations, as SPARQL *should* be, but it is not a *must* to employ
W3C REC terminology. Only basic selector support *must* be implemented.
Now, if you are more concerned about FSL by itself as a path language
for RDF, here are more specific answers to your questions.
> 1. I find the format in which a type has to be given at every step in
> the path is odd. I have used paths quite often but always strings of
> properties. The data I use doesn't always have types marked explicitly
> ... they would follow of course from the range and domain of
> properties, but those are given in the path to a certain extent.
I am considering RDF models as graphs here, and I am using a terminology
close to the one used in the XPath spec, as we clearly took inspiration
there:
- there are node location steps and arc location steps. Since we do not
have x//y in FSL (as you can find in XPath), it follows naturally that
in an FSL path expression such as a/b/c/d/e:
* a, c and e are node location steps (they select resources, or literals)
* b and d are arc location steps (they select property arcs)
If I understand you correctly, you are concerned about having to specify
these node location steps (a, b and e). Is that right ?
What you have to bear in mind is that FSL is really a language for
expressing traversal paths in graphs. When doing that, you want to be
able to express constraints on both the nodes and arcs the path should
traverse. And this is something we expect of a selector language for
Fresnel. If you really don't care about the type of the resource nodes
you traverse, you can use *. And as in XPath, you can specify other
selection conditions by grouping predicate (in the XPath sense of the
term) expressions between square brackets. e.g.:
*/foaf:knows/*[airport:iataCode/text() = "CDG" and count(foaf:knows) >
3]/foaf:name
This expression models paths that start at any resource node, then go
through foaf:knows property arcs (only), that end to resource nodes, no
matter the type of these nodes, but provided that they are the subject
of at least 3 foaf:knows statements and that they are the subject of an
airport:iataCode property whose value is "CDG". From these nodes, the
last location step selects foaf:name property arcs.
If you don't have node location steps, but only strings of properties,
how can you express such traversal expressions?
> 2. Couldn't the same information be encoded in N3? My understanding of
> FSL is limited but it seems that the mapping would look like eg
>
> x/y [a x]!y or [is y of[a x]]
> x/y/z/w [a z; is w of [a x]!y]
> */x/*/y/* !x!y
>
>
> I would naturally express that sort of selector as a rule
>
> { ?x order [ item [ cost ?y ] } => { ?y style my:AmountStyle }
>
> Is there anything in FSL whose semantics could not be expressed in rules?
>
> Tim
I am not familiar enough with rules to answer this question with 100%
certainty. But the mapping examples you give illustrate the reason why
FSL exists: having a language dedicated to modeling traversal paths in
RDF graphs, inspired by existing and well-accepted technologies (i.e.,
XPath) using a concise syntax and offering enough expressive power.
FSL may have a significant overlap in expressive power with RDF query
languages and other languages that make it possible to select data and
navigate in RDF models such as what N3 provides. But this does not mean
FSL is not useful. In my opinion, it is important to have specialized
languages that are good at doing specific things in a simple way.
Looking at the mapping you give above, I find the FSL expressions much
simpler than the N3 expressions. You also say that you would "naturally
express that sort of selector as a rule". I have no doubt you would. But
I think there is a significant amount of people out there (perhaps a
majority) to whom this does not look that natural, including myself,
whereas the FSL path expressions do (maybe because I have a stronger
XPath/XSLT/XML background, but many people do !).
In a way, it is the same old debate we've seen about XPath vs. XQuery a
few years ago. They overlap, but it is good to have both, as one
language will be better at addressing problem A while the other language
will better handle problem B.
Emmanuel
--
Emmanuel Pietriga
INRIA Futurs - Projet In Situ tel : +33 1 69 15 34 66
Bat 490, Université Paris-Sud fax : +33 1 69 15 65 86
91405 ORSAY Cedex FRANCE http://www.lri.fr/~pietriga
Received on Thu Dec 15 2005 - 21:18:09 EST