Re: FW: Jena in Haystack

Dennis Quan wrote:

> > If you use the internal shortcut of directly refering to a statement
> from
> > another statement then the referred-to statement will effectively be
> treated as
> > a bNode with a UUID generated as an anonymous ID. Internally that is
> enough to
> > retrieve the statement. It is probably right that that functionality
> is
> not
> > exposed through the API but it would be easy enough to add it.

[snip]

> If possible, can you give me an example piece of code that would allow
> me to
> continue to assign statements MD5 URIs and be able to pull up a
> statement
> given an MD5 URI, preferrably without reification?

As I said above you have the two choices at present in jena - use explicit
reification (in which case you can assign your MD5 URIs to the node which
reifies the stating of the statement) or use the
statement-referencing-a-statement shortcut in which case the stating is
effectively represented as if it were a bNode with some internal UUID
identifier. You could then attach your MD5 URI to this bNode via a property.

If this latter sounds like what you are looking for then I could hack up some
example code.

> I interpret the limitation that predicates must be QNames as more a
> limitation of the S (syntax) in the M&S rather than of the M (model). 

Agreed, it is a syntax rather than a model limitation. I assumed that you might
at some point want to write your RDF out, if only to a log file for safe keeping
and so keeping within the syntax limitations would be useful.

> In
> fact, the model only states that Properites be a subset (not even
> necessarily a proper subset) of Resources. It does not give any
> syntactic
> restriction on the use of URIs there for naming Properties

At least one reasonable interpretation of the original M&S was that by requiring
serialization via qnames it was restricting the set of URIs that could be
property names to a proper subset. The RDFCode WG has, as far as I understand,
now clarified this and confirmed that any legal URIref can be used as a property
name which presumably has the consequence that some legal property names cannot
be written out in RDF/XML.

> In any event, the most malformed URI we use for a predicate is something
> like <urn:some:test:predicate> or <test>. If the system would just strip
> this down to the last colon (or perhaps in the first example, take the
> first
> character? or maybe <test> is simply not a feasible class of property
> URIs),
> or perhaps have a switch that would turn off this decomposition (since
> N3
> doesn't require it), it would ease our integration.

<urn:some:test:predicate> is a legal URI and is fine whereas <test> is not an
(absolute) URI I don't think - doesn't rfc2396 require there to be a scheme:
component?

I'm not sure why you are are seeing the split algorithm anyway. As I put in my
follow up msg this morning the normal way to define properties through the jena
api is:
  model.createProperty(namespace, localname)
So for the split you are proposing then just call:
  model.createProperty("urn:some:test:", "predicate")

Does that not work?

There is at least one change needed to this part of jena. Now that the WG has
said that property names can use any URIref, even ones that can't be qnames,
then the check that createProperty makes that it's localname is not-empty needs
to be removed. We can do that in CVS now if that would help you but do be
careful of what violating this means for serialization of your data.

> [Concurrrency discussion for RDB snipped]

> So does this mean that the Berkeley DB implementation should at least
> not
> cause queries to fail (a la ConcurrentModificationException) if we
> perform
> simultaneous addition and deletion during a query?

The Berkeley DB implementation is a different matter from the relational
database interface. All that discussion on transaction support for RDBs was just
that - for RDBs. We don't currently support transactions for Berkeley DB because
we couldn't make it work reliably in time :-(
I thought that was fairly up front in the documentation but if not we should
make it so.

If transactions for Berkeley DB are a requirement then we'd need to check with
Brian (who is responsible for this sub-system) how feasible that is.

Cheers,
Dave

Received on Friday, 19 July 2002 10:35:26 UTC