Here's a brief description of the changes that I've made to the relational layer of JRDF. Basically, it now tries to closely follow the concepts of relations and tuples. So far, I think it's closer than previous attempts such as, "A relational algebra for SPARQL". One of the ideas that I keep coming back to is that having duplicates are indicative of using bags/multisets not sets - and RDF is all about sets. There's a whole stream of research on the power of bag languages ("Query Languages for Bags", which claims bag oriented languages can't do transitive closure for example) that I've yet to look at more fully.
- Type name - integer, char, sno, name.
- Attribute Name - status, city, sno, sname.
- Attributes - status:integer, char:city, sno:sno, sname:name
- Attribute:Value - sno sno('s1'), sname name('smith'), status 20, city 'london'
- Heading - sno sno, sname name, status integer, city char.
Proposed Types for RDFBasic interface:
- isAssignableFrom - return true if the object is a super-type of the given type. Similar to Java's and Rel's.
- getName - the name of the type.
- Object -> Subject -> Predicate. Meaning that Object is a super-type of Subject, which is a super-type of Predicate. This allows joining columns of different but compatible types.
- URI Reference, Literal and BNode are all incompatible types of each other - you won't be able to join these.
They are all nodes. In the future this will allow selecting certain types or certain operations to be performed only on certain types.
Proposed JRDF TuplesComponents:
- Types - subject, predicate, object, uri, literal, bnode. As defined above.
- Attribute name - variable name or default name.
- Attribute - s?:subject, P1:predicate, O1:object, P2:predicate, ?p:object, P3:predicate, ?city:object
- Attribute:Value - s?:subject(#s1), P1:predicate(#name), O1:object('smith'), p?:predicate(#p1)
- Heading - s? subject, P1 predicate, O1 object.
Proposed JRDF RelationComponents:
- Heading/Attributes - set of attributes.
- Body/Tuples - set of tuples
An aspect of this is that the heading of the relation doesn't modify the type in the attribute of the tuple. This means you always know the position of where in the graph the value came from. This used to bug me in Kowari/TKS that the underlying layers didn't know this information.
select ?sno ?pno ?city
where ?sno #sno s1
?sno #sp ?pno
?pno #city ?city
First and Second:
First and Second and Third: