[Mulgara-dev] File based resolver

Andrae Muys andrae at netymon.com
Wed Feb 7 07:11:19 UTC 2007


I don't have time to give this email the attention it deserves, but I  
just wanted to pose a couple of questions now.  Hopefully I will have  
time later to address it in more detail.  This email ends up sounding  
more negative than I had intended, I apologise in advance for that -  
these are just the questions I didn't feel have been addressed yet.

On 07/02/2007, at 4:38 PM, Paul Gearon wrote:
> Adding a file could be done by asserting a triple in the resolver:
>   <file://you/path/goes/here/file.pdf> <rdf:type>  
> <fileresolver:File> .
> This would take a copy of the file and store it in the Mulgara  
> controlled directories somewhere with read-only permission.  There  
> are a few options, but I guess a hash-based name could be used for  
> the copy.  A mapping of the original path to the new path can be  
> kept in the local RDF store.  Resolvers always map to a typed model  
> which until now is always empty.  In this case we could add some  
> data (such as the suggested URI -> new-path mapping) into the model.

Assuming the user inserts

<file://file1> <rdf:type> <fileresolver:File>
<file://file2> <rdf:type> <fileresolver:File>
<file://file3> <rdf:type> <fileresolver:File>

I'm curious how you plan for Mulgara to access these files on a  
remote client?

> Getting the path for a file could be a constraint like:
>   <file://you/path/goes/here/file.pdf> <fileresolver:hasPath> $path
> as well as:
>   $fileuri <fileresolver:hasPath> $path
> The returned path would then be openable (for read-only access) by  
> the client.

I'm a little concerned about this.  It appears we are talking about  
running various remote file-access services from inside mulgara?  I  
am also concerned about the apparent need to make mulgara's database  
directory accessible directly to local clients.  More-over if Mulgara  
is going to be managing these files, then whatever scheme we choose  
will have to be able to be ultimately integrated with our security  
model - which is currently based on graphs, proposed to ultimately  
include triples, but no-one has yet suggested should include the  
filesystem.

> Deleting all statements in the resolver which use the file URI  
> would result in it being unlinked from the filesystem.  This would  
> normally require a callback from the stringpool to inform the  
> resolver that the URI is gone, but in this case the data that can  
> be inserted or deleted is well defined, so the resolver can spot  
> this for itself.

As soon as we provide the ability to store files in Mulgara (and give  
it a name), they are going to be referred to in other (non-file- 
resolver) models.  This means that the resolver won't have all the  
information it requires to guarantee this.

> That's basically it.  The difficulty isn't in the implementation,  
> it's in the justification.  Any comments?

Have you considered treating files as typed-literals?  This was the  
direction I was heading when I was looking at this problem.   
Certainly this is the only place I see files fitting cleanly into the  
rdf datamodel.

Files aren't URI's - although a URI might reference a File and a File  
may have one or more URI's that name it.  I think we are going to  
have to be very careful we don't conflate these two concepts.

> Of course, once this were set up, it would be trivial to create a  
> set of predicates to reading metadata about the file, and even  
> reading data from the file.  eg:
>   <file://you/path/goes/here/file.txt> <fileresolver:line_8> $line
> Would return the string of text appearing between the 7th and 8th  
> newline characters.  I don't know that these features would be  
> necessarily useful, but they sound like fun.  :-)

Now that sort of thing would be cool.  Although I would consider

<some:unique:urn:file.txt> <fileresolver:line_8> $line

to probably be cleaner architecturally and less likely to get us into  
trouble later.

Andrae

-- 
Andrae Muys
andrae at netymon.com
Principal Mulgara Consultant
Netymon Pty Ltd





More information about the Mulgara-dev mailing list