Re: [Aperture-devel] Data Sources and ConfigurationUtil

[<ant...@gm...>]

Grant Ingersoll pisze:
> Is the current trunk considered stable enough to build against?

It is. We have some issues in the tracker, and minor tweaks are added to 
the NIE ontology but there is strong will to make a release within two 
weeks so there won't be any major changes. You may take a peek at the 
sourceforge tracker.

<http://sourceforge.net/tracker/?group_id=150969&atid=779500>
<http://sourceforge.net/tracker/?group_id=150969&atid=779503>

We will strive to resolve the priority-9 issues before the release.

Also, there is a detailed changelog of what's happening in NIE at the 
moment.

<http://dev.nepomuk.semanticdesktop.org/repos/trunk/ontologies/nie/CHANGELOG.txt>

The content of the aperture.vocabulary package is periodically updated 
with the latest state of NIE.

> Also, is there any plan/support for just deprecating old RDF  
> triples?  That is, does the RDF implementation make copies of the  
> data, or does it just store references, such that it would be  
> feasible to maintain (and deprecate) the old URIs while adding in the  
> new ones at least for some well-defined set of releases such that  
> existing applications aren't necessarily broken by changes introduced  
> within the same minor build?

The move from the old DATA vocabulary to the nie NIE has been abrupt 
indeed. It's definitely not a minor build. Notice that the previous 
release has also been a complete rewrite - from using the Sesame API 
directly to RDF2Go. That's why we've tagged the next one as beta1. That 
is: the most important parts of the API are stable, aperture IS commited 
to NIE and the the future changes will either be evolutionary or the 
version number is incremented accordingly.

BTW. The current versioning scheme
<year-of-release>.1-<(alpha|beta)>-<consecutive-number>

doesn't seem to distinguish between major and minor builds. Both maven 
and osgi allow the user of an aperture-dependent application to specify 
a range of versions it supports. With this versioning scheme, specifying 
a range is difficult, since the <consecutive-number> appears after 
(alpha|beta). What do you think?

> Also, does this mean more of the RDF stuff will be hidden from  
> me?  :-)  The less I have to worry about RDF the happier I am.  For  
> instance, I would love to just be able to instantiate the various  
> factories and tell it either to use an in-memory store or a file- 
> store and have all the RDF magic happen behind the scenes.  Sure, it  
> would be useful to have access to the stores if I want to via an  
> "expert" API, but writing SPARQL queries to get at the extracted data  
> is not my personal cup of tea.

This is difficult since aperture strives to be RDF-store-agnostic, i.e. 
it is supposed to work with ALL stores for which RDF2Go drivers exist. 
The functionality of RDF-stores varies greatly. The range of available 
storage media (in-memory, file, db, http) and the inference options 
differ. Such utility methods
(e.g. createAFileBasedStoreWithRDFSInference(File file)) would have to 
be implemented below aperture on the RDF2Go level. Otherwise this would 
introduce a dependency on a concrete RDF store implementation.

Aperture developers are also involved in the RDF2Go community though and 
the head of the RDF2Go project (Max Völkel) is a good friend of ours so 
don't loose your spirits :)

--
Antoni Myłka
ant...@gm...