rdf-related built-ins (and a few others)

Dave Reynolds <der@hplb.hpl.hp.com> writes:
> ** RDF manipulation
> 
> We intend to include a means for representing RDF data in Core based on 
> the frame syntax and some additional datatypes. We will need a 
> corresponding set of builtin functions.
> 
> I suggest a minimum would be to support the SPARQL [2] functions:
>     isIRI
>     isBlank
>     isLiteral
>     lang
>     datatype
>     langMatches
>     str
> 
> Plus we would need constructors for our mapped version of the RDF 
> datatypes - iri, blankNode, plain-literal-with-lang-tag.
> We need to complete the RDF embedding proposal before we can properly 
> define this latter group.

I agree we need the complete RDF embedding proposal before we can
properly define this latter group, but let me raise a basic concern with
this group.   As I understand it, these functions operate on the 
syntactic structures of RDF graphs, rather than on the knowledge
expressed about the domain of discourse.  They're a bit like prolog's
var/1 -- very useful, but not really a part of the logic.

To illustrate the difference, as I understand it, one might have a
funtion like "odd" which takes an integer and tells you if it's odd or
not.  That is, you could syntactically apply "odd" to a literal data
value which denoted an integer, or to a bound variable, or another
function term which returns an integer, or to a URI-term which denotes
an integer, etc.  By contrast, the 'datatype' function doesn't "take" an
integer; it operates more directly on a literal data value term or a
variable bound to one.  The number one, itself, is odd -- but the number
one does not have a datatype.  It can be expressed in several different
literal data value terms, including "1"^^xsd:nonNegativeInteger,
"1"^^xsd:int, and "1"^^xsd:integer.   

>From a software engineering perspective, these functions seem to violate
modularity, in a sense poking through the logical abstraction of the
language..  On the other hand, I bet users want them.


> ** Output
> 
> Gary has suggested [3] that a minimal feature to enable test cases to be 
> written in RIF would be the ability to output a data value (the output 
> then being used to indicated success of the test case). Thus we would need:
> 
>      rif:print
>
> [3] http://www.w3.org/2005/rules/wg/wiki/Arch/Test_Cases

I wouldn't expect this to be in Core.  I'd expect it to be in an
extension which the test cases use.

> ** Lists
> 
> There will need to be builtins associated with the List datatype once 
> that is settled.

Yeah.   I come back to wondering whether core should really just have an
opaque list datatype, not supporting unification, because it's probably
a lot easier to implement in some styles of rule engine.    (ponder, ponder.)

     -- Sandro

Received on Friday, 22 June 2007 14:16:30 UTC