[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