Re: graph names as third argument

As somebody who built a successful production system based on quads, I'd 
hazard to say that there is a special case for place #4, and also a good 
reason to stop there.  It's been well established that the triple is 
enough to encode any kind of data.  The fourth place simply gives the 
triple store a method for knowing which triples to delete and/or replace.

All data stores have the temporal problem -- is this closed world 
representative of a point in time or a record of events?  RDF to me 
doesn't look like the place to resolve this question.  What place four 
does is provides a means to ease implementation and make a set of 
triples work in practical applications.

I'm not frankly sure if this is the place for this kind of input, being 
new to the process, but I'd support a view of place #4 as 
'implementation dependent' so as to enable a wide variety of data store 
types.

Charles



On 11/08/2011 01:31 AM, William Waites wrote:
> Hi Pat, I hope you are rapidly recovering and feeling better.
>
> Reading this idea about repurposing the fourth column to talk about
> time, or generally to support ternary predicates, I wonder if I'm just
> pointing out the obvious that as useful as it is, how long before
> people start wanting 4, 5, ... n place predicates? And then have we
> just started reinventing relational databases or prolog, only with
> URIs? (not that that would necessarily be a bad thing...)
>
> I guess it would be pretty easy to modify the n-quads parsers to
> handle n-tuples at any rate, the '.' record delimiter is easy to
> spot...
>
> Cheers,
> -w
>


-- 
Charles Greer
Senior Engineer
MarkLogic Corporation
charles.greer@marklogic.com
Phone: +1 707 408 3277
www.marklogic.com

This e-mail and any accompanying attachments are confidential. The information is intended solely for the use of the individual to whom it is addressed. Any review, disclosure, copying, distribution, or use of this e-mail communication by others is strictly prohibited. If you are not the intended recipient, please notify us immediately by returning this message to the sender and delete all copies. Thank you for your cooperation.

Received on Tuesday, 8 November 2011 18:09:43 UTC