Added the csvw prefix to the RDFa initial context. #594
Conversation
|
is this really intended for the current revision? if not it would make more sense to rebase and merge this into the 5.0.0-dev branch... |
Well… it depends when the 5.0.0 branch will be released. If it is a matter of a few weeks, then it is of course fine. If it is longer, then probably it is better to get this particular issue out as soon as possible; RDFa processors are supposed to update themselves to the latest version of the initial context as soon as possible. It all depends on the release plans. |
|
How about adding a method for updating the RDFa processor context manually in between releases? Something like this could be added to the from rdflib import Graph, Namespace, RDF
RDFA = Namespace('http://www.w3.org/ns/rdfa#')
def update_initial_context():
for context_uri, context in initial_context.items():
graph = Graph().parse(context_uri, format="rdfa")
wrapper = initial_context[context_uri]
for mapping, uri in graph.resource(RDFA.uri).subject_objects():
uri = unicode(uri)
prefix = mapping.value(RDFA.prefix)
if prefix:
prefix = unicode(prefix)
assert mapping[RDF.type:RDFA.PrefixMapping]
assert wrapper.ns.setdefault(prefix, uri) == uri
else:
term = unicode(mapping.value(RDFA['term']))
assert mapping[RDF.type:RDFA.TermMapping]
assert wrapper.terms.setdefault(term, uri) == uriA user could then do: from rdflib.plugins.parsers.pyRdfa import initialcontext
initialcontext.update_initial_context()(Something nicer might be to call this automatically at times and cache the results. But that'd be more complex, and failures hard to understand, so I suggest beginning with this.) |
|
Yeah… I actually had a much more complicated version at a time when we had the notion of a profile in RDFa (which we removed later) which allowed the user to dynamically such a set of prefixes. That version did a little bit what you suggest in the last line, namely checking dates, loading the prefixes and such only when necessary, otherwise using some local cache. But the code has been removed when the feature was removed. (It may be somewhere deep down in one of the pre-RDFlib commits, but it may even precede my move to github.) As for this thing: there is an update once, say, every 18 months. There may be an oa prefix coming up at the end of this year, then… well, I do not know. Frankly, for a 5 minute update once every 18 months I did not feel like doing this. The new versions of RDFLib are released more often… But… if you want to do this, of course!:-) Ivan
Ivan Herman |
|
that would be an option, even though i have to say that from a dev perspective i remember that i was actually confused by that local caching before (different systems gave different results for the very same code)... so doing this automagically definitely has some disadvantages. i don't want to revive the discussion about depending on a standalone package here, but that would solve that without magic in a standard way and without the potential to bash w3.org with requests, potential to fail when there's no connection, ... |
Of course, a separate module could be considered to be more agile in this sense, ie, the new releases would come up more easily, but that is a matter of release policy rather than anything else. |
|
yes, the benefit lies solely in decomposition and using the features of automated installers such as pip. The semver.org release policy in RDFLib would probably dictate that such a prefix update has a new major release, as it could potentially break code in a backwards incompatible way if prefixes disappear for example... |
I think the danger of breaking application is very low. Indeed, there is no way a prefix can disappear. Any change is restricted to the addition of prefixes, per RDFa policy. |
See
https://lists.w3.org/Archives/Public/semantic-web/2016Feb/0017.html
for the details.