Re: [UCR] ISSUE-12 and ACTION6198

Sandro Hawke wrote:
>> Let us pick one of the boundary cases to ground the discussion. What 
>> about the set of builtins/functions such as one for access to an 
>> external SPARQL data source.
> 
> Good idea -- can you flesh this out a little more, though?  Do you have
> a feature like this in Jena Rules? 

No but that's partly because it pre-dates SPARQL [I've held off doing 
any language updates due to pressure of other work and in case RIF might 
end up having relevance].

We do have more modest builtins that are specific to the RDF model 
(isBNode, makeTemp (i.e. mint a new bNode[*]) etc).

We have other strange things driven by our rules-for-RDF design centre, 
specifically that there are only triples (no n-ary predicates) but we 
provide some of the convenience of n-tuples by supporting structured 
literals:

    subject predicate f(a,b,c) .

which in prolog-like-syntax would be:

    predicate(subject, f(a,b,c))

where a ground f(a,b,c) turns into a single typed literal value of type 
Functor which contains a data structure comprising a name (f) and a list 
of arguments (a,b,c). The Functor type is Jena-specific and we go to 
some lengths to prevent instances of it escaping from Jena unless a user 
is really certain that's what they want.  [**]

> Can you show an example -- even if
> it's not in Jena rules -- what might it look like?  

For example, one version might look something like:

   sparql(srcURL, query, ?X, ... ?Z)

where the ?X..?Z variables would be bound to the corresponding query 
variables, e.g.

   sparql("http://jena.hpl.hp.com/somedata",
          "PREFIX vcard:      <http://www.w3.org/2001/vcard-rdf/3.0#>
           SELECT ?y WHERE { ?y vcard:Family 'Smith' }",
          ?y)

You might also want some mechanism by which sets of RDF facts could be 
named for reference in the srcURL to permit you to query data sets which 
are not accessible as SPARQL service end-points.

Of course there are lots of variants to this that could be imagined and 
lots of details left unspecified.

> My hypothesis is that there's nothing users particularly need that is
> specific to a "Semantic Web" rule language.  

As well as any specific features like this one that we've picked on here 
there is also the difference that a "standard" semantic web rule 
language should involve tasteful design choices about the whole set of 
features and choice of semantics (a recommendation of a good subset or 
two to pick), whereas RIF supports everything. I don't see all possible 
RIF dialects being equal in this regard. Specifically I doubt all will 
be equal in terms of how nicely they play with OWL. I rather glossed 
over this in my original message because there are others much better 
equipped to delve into that sort of issue.

Dave

[*] I don't want to restart the "that's just a Skolem constant and 
bNodes are different discussion" here, I acknowledge that is not a 
correct approach to bNodes it is just a practically useful one.

[**] Again I'm not proposing any such thing for RIF so don't let the 
details of this divert you, I'm just pointing out an example of where we 
did something differently because of the design centre.

Received on Thursday, 4 January 2007 07:31:10 UTC