localization and context?
Bruce D'Arcus
1) localization. If I define, say, dc:title as an rdfSingle, then what
happens if I have two title properties, each with a different language
tag? Wondering if maybe something like this would be valuable?
title = rdfSingle(DC['title'], localized=True)
... where by default it would return the property for the current
locale, but where one could also specify a language?
2) contexts: my understanding is that rdflib will by default create
separate subgraphs for each file it loads into a ConjunctiveGraph. But
from what I understand, RDFAlchemy ignores those subgraphs and only
deals with the default main graph. Would there be value in RDFAlchemy
providing some abstraction for this?
Bruce
Philip Cooper
On May 25, 2008, at 9:14 AM, Bruce D'Arcus wrote:
>
> Two issues I'm wondering about:
>
> 1) localization. If I define, say, dc:title as an rdfSingle, then what
> happens if I have two title properties, each with a different language
> tag? Wondering if maybe something like this would be valuable?
>
> title = rdfSingle(DC['title'], localized=True)
>
> ... where by default it would return the property for the current
> locale, but where one could also specify a language?
This kind of abstraction is probably a good thing to handle in an orm
I've pondered this and similar issues and I'm not sure I know which
way to handle it.
The basic issue is that there is not a single response to bibitem[DC
['title']]
I think what is required is a new descriptor that is basically
rdfMultiple that filters the responses to find the "best" one
In this case the "best" response would be in the preferred Locale
(using python locale module?)
rdfBest(self, pred, selectFun, range_type=None)
where selectFun is a callable
Your rdfLocaleSingle descriptor should be rdfBest with a "stock"
selectFun.
I've created a ticket here: http://www.openvest.com/trac/ticket/27
and put you on the "cc" list.
Need the new descriptor since rdfMultiple loses the lang info during
v.toPython().
Similar issues come up if there is a container of type rdf:Alt.
I also think a verson of rdfContainer that acts as a Stack would be
useful (only retreiving the "top" or one rdf:first by default)
More descriptors will improve rdfalchemy moving forward ... contribs
welcome.
>
> 2) contexts: my understanding is that rdflib will by default create
> separate subgraphs for each file it loads into a ConjunctiveGraph. But
> from what I understand, RDFAlchemy ignores those subgraphs and only
> deals with the default main graph. Would there be value in RDFAlchemy
> providing some abstraction for this?
RDFAlchemy stores the ConjunctiveGraph in the rdfSubject.db attribute.
The context behavior should be whatever you would expect from rdflib.
rdfSubject.db.parse or .load just calls the rdflib method and the
context *is* set for all of the imported items (not ignored).
All direct writes through rdfSubject.db.add or assignment through a
descriptor (bibItem.isbn='1234567899') will use the defaultGraph
generated during the open method (an ugly bnode by default). You can
control the public_id of the default graph if you open the
ConjunctiveGraph yourself and then assign the graph to rdfSubject.db
I haven't seen any clear winner among the candidates for a better
default public ID
__name__
__file__
uuid
dburi+timestamp
For "real" projects I use a modified create_engine that records the
above info and more in a context that is essentially a "graph_info
context". If I add those triples in the default create_engine, I'll
just end up with a bunch of "what's this doing in by triplestore"
questions.
--
Phil