From axel at rauschma.de  Tue Oct  9 02:15:41 2007
From: axel at rauschma.de (Axel Rauschmayer)
Date: Tue, 9 Oct 2007 02:15:41 +0200
Subject: [Rdf2go-devel] RDF2Go Feedback
Message-ID: <94562A73-BF17-478C-AD47-9BA0A43E46CA@rauschma.de>

Hi!

FWIW, these are a few points that I have noticed while working with  
RDF2Go:

!! Web site

* Consolidate documentation links in a single location.
** http://wiki.ontoworld.org/wiki/RDF2Go#Documentation_and_Tutorial
** http://semweb4j.org/site/rdf2go/
* Tutorial: Very useful, but too deeply nested (I love fine-grained  
units when it comes to source code, with wiki pages, bigger is  
sometimes better).
* Section "Developer Workflow": Should probably be not on the first  
page, maybe move it to a snippet/howto. I like howtos and snippets,  
anyway (Jena [1] and Eclipse [2] haven them).

[1] http://jena.sourceforge.net/documentation.html
[2] http://www.eclipse.org/swt/snippets/

!! Packaging

* Provide separate source ZIP/JAR download, don't mix source and  
binaries in the same package.

!! API

!!! Small changes

* *Returning* C<? extends T> is usually discouraged, see the generics  
tutorial (for arguments though, it is the way to go). Better: C<T>.
* QueryResultTable.getVariables() should return a list (and not  
Set<String>). Reason: order is significant.
* URI and URIImpl (similar: Literal, ...)
** Is this level of indirection really needed? Abstract classes are  
sometimes a simpler solution than an interface + a default  
implementation. If there is only ever going to be a single  
implementation, there should be no interface at all, just a single  
concrete class.
** In any case: Shouldn't URIImpl be a class that is completely  
internal? Right now, it is needed if you want to create a static  
constant.
*** There should be a static factory for creating URI and literals  
instances (so that URIImpl can be completely private again).
** getUnderlyingBlankNode() is not accessible via interface. That is,  
one must cast BlankNode to BlankNodeImpl if one wants to access it.  
This completely breaks encapsulation.
* Blank node IDs: Sesame exposes them -- one can extract the blank  
node ID xxx from a blank node (toString() should return _:xxx) and  
create a blank node from a given ID. This is very helpful for Ajax- 
style client-server communication.
* Should Variable really extend Node? Then one can create a Statement  
that contains Variable.ANY (which is something the type system should  
prevent, right?).
* File extensions: class Syntax should store the file extension in  
addition to the mime type.
* toString()
** Literals: Adhere to Turtle syntax? Maybe it should not return the  
getValue() result.
** Blank nodes: return a blank node URI, not just the blank node ID.
* Concurrent modification: throw an exception; now (with Sesame),  
RDF2Go just gets stuck.
** Example: iterating over statements while removing some of them. It  
would be nice, if Iterator.remove() worked here.

!!! Major new features

* FeatureDirectory: Find out what features the underlying engine  
supports.
** Main candidate: If there is a triple store then one probably  
cannot add new models.
* findReifications(). I have a simple implementation, let me know if  
you are interested.
* Namespace support
** Read and write to the underlying repository.
** Use for pretty-printing that honors namespace prefixes.
** Maybe: RAM-only addition of namespaces (without changing the  
repository).
*** Use case: RAM-only namespaces help with the following scenario.  
Allow namespaces to be defined in RDF. That way, they can easily be  
merged in, say in conjunction with a supporting Fresnel vocabulary.

!! Naming

* I've had good experiences with never writing acronyms in caps (even  
though it breaks standard Java API conventions). Example: URIImpl ->  
UriImpl.
* URI should be renamed to something else, it should not clash with  
the standard Java API name that is additionally used in the same  
context. Suggestion: URINode or UriNode.

--
Axel Rauschmayer
http://www.pst.ifi.lmu.de/~rauschma/





From leo.sauermann at dfki.de  Tue Oct  9 13:35:09 2007
From: leo.sauermann at dfki.de (Leo Sauermann)
Date: Tue, 09 Oct 2007 13:35:09 +0200
Subject: [Rdf2go-devel] RDF2Go Feedback
In-Reply-To: <94562A73-BF17-478C-AD47-9BA0A43E46CA@rauschma.de>
References: <94562A73-BF17-478C-AD47-9BA0A43E46CA@rauschma.de>
Message-ID: <470B676D.3040905@dfki.de>

I comment on these...

but beforehand:
==== begin of serious message ====
There are some changes suggested like "rename a class" or
"make it a Bean instead of an interface".
This will not change funcitonality, will not make the code work faster 
or better.
It is just "more beautiful in the eye of the observer"

we are not in a beauty contest.

always keep in mind that the investment in created code using RDF2Go is 
already in the area of 10k-50k Euros,
do you want to break 50.000? of code just because of uppercases???

Looking at all projects that use rdf2go, each company has to rewrite the 
implementations,
re-check the JUnit tests, and recompile everything, make new distributions,
test the distributions, etc. Changes should add new features and improve 
existing ones,
but not break stuff.
Now given that changes are more costly than the initial programming 
(because the developer has done other things in the last months and has 
to learn his own code again), you come up with very high costs.

Please respect that some people here can lose money, go bankrupt, lose 
jobs,
because suddenly their software is rendered useless
I am talking about the companies that are building upon Aperture, which 
builds upon rdf2go.

we are not a bunch of hackers having fun with code, there is companies 
around us that depend on what we decide here.
==== end of serious message ====

ok, now for happily discussing....

It was Axel Rauschmayer who said at the right time 09.10.2007 02:15 the 
following words:
> !! API
>
> !!! Small changes
>
> * *Returning* C<? extends T> is usually discouraged, see the generics  
> tutorial (for arguments though, it is the way to go). Better: C<T>.
>   
haha, music in my ears, I always thought that returning a generics like 
this was wrong,
thanks for pointing it out.
could you give a link to the tutorial part you refer to?

> * QueryResultTable.getVariables() should return a list (and not  
> Set<String>). Reason: order is significant.
>   
correct, sets are unsorted.
This is indeed WRONG in the current version, meaning its a bug.
> * URI and URIImpl (similar: Literal, ...)
> ** Is this level of indirection really needed? Abstract classes are  
> sometimes a simpler solution than an interface + a default  
> implementation. If there is only ever going to be a single  
> implementation, there should be no interface at all, just a single  
> concrete class.
> ** In any case: Shouldn't URIImpl be a class that is completely  
> internal? Right now, it is needed if you want to create a static  
> constant.
> *** There should be a static factory for creating URI and literals  
> instances (so that URIImpl can be completely private again).
>   
All this may be correct, but its too much chnage now, and all our code 
will be invalid.
No way, I am against it.
And, all existing RDF frameworks are built the same way (Jena & Sesame 
have exactly the same thing with
Uri, UriImpl, and Factories, and you work with it the same: you either 
use the factory methods or the
*Impl constructors, both is ok)
Leave as it is, we don't need to be more clever thatn jena & sesame

> ** getUnderlyingBlankNode() is not accessible via interface. That is,  
> one must cast BlankNode to BlankNodeImpl if one wants to access it.  
> This completely breaks encapsulation.
>   
Max always insisted that the way the database handles blank nodes should 
be "unavailable to the developer",
but I think that the developer needs indeed to do somethinbg with blank 
nodes, +1
> * Blank node IDs: Sesame exposes them -- one can extract the blank  
> node ID xxx from a blank node (toString() should return _:xxx) and  
> create a blank node from a given ID. This is very helpful for Ajax- 
> style client-server communication.
>   
yep, similar with jena.
> * Should Variable really extend Node? Then one can create a Statement  
> that contains Variable.ANY (which is something the type system should  
> prevent, right?).
>   
+1
shouldnt be needed, the parameters where variables are used are usually 
"NodeOrVariable" "resourceOrVariable", so Variable can be independent
of node, or?
> * File extensions: class Syntax should store the file extension in  
> addition to the mime type.
>   
+1
> * toString()
> ** Literals: Adhere to Turtle syntax? Maybe it should not return the  
> getValue() result.
>   
-1,
no thats the "toSparql()" method,
toString returns what you would show in a user interface!
> ** Blank nodes: return a blank node URI, not just the blank node ID.
>   
-1
There ARE NO blank node URIs,
you are mixing something up here.
Blank nodes are devined as NOT BEING AN URI.
> * Concurrent modification: throw an exception; now (with Sesame),  
> RDF2Go just gets stuck.
>   
part of sesame, not to be done here,
(impossible to do on rdf2go level, really)
this is hidden DEEP inside the transaction system of sesame, to hack it 
in rdf2go, you would have
to re-build the whole sesame complexion - don't think about it

this will also be solved in the next sesame releases - they allow then a 
better locking model!
this is a known problem, sesames are working on a solution
> ** Example: iterating over statements while removing some of them. It  
> would be nice, if Iterator.remove() worked here.
>   
-1
not possible in any rdf framework,
would be nice, but out of question for now.
> !!! Major new features
>
> * FeatureDirectory: Find out what features the underlying engine  
> supports.
> ** Main candidate: If there is a triple store then one probably  
> cannot add new models.
> * findReifications(). I have a simple implementation, let me know if  
> you are interested.
>   
+1, this misses!!!
Jena has it with getReifiedStatement(), its crucial for the RDF standard
reification is in the standard, independent of how loud you cry "it sucks"
> * Namespace support
> ** Read and write to the underlying repository.
>   
+1, meaning you want to expose the "setnamespacePrefix" method?
> ** Use for pretty-printing that honors namespace prefixes.
>   
-1
done in the underlying implementations already, no changes needed in rdf2go
> ** Maybe: RAM-only addition of namespaces (without changing the  
> repository).
>   
-1
done in the underlying implementations already, no changes needed in rdf2go
> *** Use case: RAM-only namespaces help with the following scenario.  
> Allow namespaces to be defined in RDF. That way, they can easily be  
> merged in, say in conjunction with a supporting Fresnel vocabulary.
>   
-1
done in the underlying implementations already, no changes needed in rdf2go
> !! Naming
>
> * I've had good experiences with never writing acronyms in caps (even  
> though it breaks standard Java API conventions). Example: URIImpl ->  
> UriImpl.
>   
No, URI is also all-caps in java.net.*
> * URI should be renamed to something else, it should not clash with  
> the standard Java API name that is additionally used in the same  
> context. Suggestion: URINode or UriNode.
>   
No, this is manicure.
This is a change that will break tons of code for no reason other
than style.

best
Leo
> --
> Axel Rauschmayer
> http://www.pst.ifi.lmu.de/~rauschma/
>
>
>
>
> _______________________________________________
> Rdf2go-devel mailing list
> Rdf2go-devel at ontoware.org
> http://ontoware.org/mailman/listinfo/rdf2go-devel
>   


-- 
____________________________________________________
DI Leo Sauermann       http://www.dfki.de/~sauermann 

Deutsches Forschungszentrum fuer 
Kuenstliche Intelligenz DFKI GmbH
Trippstadter Strasse 122
P.O. Box 2080           Fon:   +49 631 20575-116
D-67663 Kaiserslautern  Fax:   +49 631 20575-102
Germany                 Mail:  leo.sauermann at dfki.de

Geschaeftsfuehrung:
Prof.Dr.Dr.h.c.mult. Wolfgang Wahlster (Vorsitzender)
Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats:
Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
____________________________________________________



From voelkel at fzi.de  Tue Oct  9 14:50:22 2007
From: voelkel at fzi.de (=?iso-8859-15?Q?Max_V=F6lkel?=)
Date: Tue, 9 Oct 2007 14:50:22 +0200
Subject: [Rdf2go-devel] RDF2Go Feedback
In-Reply-To: <470B676D.3040905@dfki.de>
References: <94562A73-BF17-478C-AD47-9BA0A43E46CA@rauschma.de>
	<470B676D.3040905@dfki.de>
Message-ID: <234535961.20071009145022@fzi.de>

Hi, find my personal opinions below.

LS> ==== begin of serious message ====
LS> we are not in a beauty contest.
Agree.

LS> we are not a bunch of hackers having fun with code, there is companies
LS> around us that depend on what we decide here.
Yes, we should be really careful of changing RDF2Go. Extending is ok.
The difference is well explained in some Java document.

LS> ==== end of serious message ====

>> * *Returning* C<? extends T> is usually discouraged, see the generics
>> tutorial (for arguments though, it is the way to go). Better: C<T>.
LS> haha, music in my ears, I always thought that returning a generics like
LS> this was wrong,
LS> thanks for pointing it out.
LS> could you give a link to the tutorial part you refer to?
Yep, it seems I misunderstood some parts of the tutorial, maybe.

I am not sure how this change is in terms of binary compatibility.

>> * QueryResultTable.getVariables() should return a list (and not
>> Set<String>). Reason: order is significant.
>>   
LS> correct, sets are unsorted.
LS> This is indeed WRONG in the current version, meaning its a bug.
Why?  A  sparql  query  result  is  in fact a set of bindings for variables. You
can retrieve the variables and get the results for each of them.

I guess nowhere in the specs it says: If you ask for
SELECT ?a ?b WHERE .... the result set has to contain "a" before "b".
By  trying  to put the lowest semantic burden on implementations, I deliberately
have NOT choosen a list.

>> * URI and URIImpl (similar: Literal, ...)
>> ** Is this level of indirection really needed? Abstract classes are  
>> sometimes a simpler solution than an interface + a default  
>> implementation. If there is only ever going to be a single  
>> implementation, there should be no interface at all, just a single  
>> concrete class.
>> ** In any case: Shouldn't URIImpl be a class that is completely  
>> internal? Right now, it is needed if you want to create a static  
>> constant.
>> *** There should be a static factory for creating URI and literals  
>> instances (so that URIImpl can be completely private again).
>>   
LS> All this may be correct, but its too much chnage now, and all our code 
LS> will be invalid.
Furthermore,  interfaces  have  much better extensibility than abstract/concrete
classes. Even in my own few programming projects, I was very happy to be able to
write myclass implements rdf2go.URI.

LS> Leave as it is, we don't need to be more clever thatn jena & sesame
Also agree.

>> ** getUnderlyingBlankNode() is not accessible via interface. That is,  
>> one must cast BlankNode to BlankNodeImpl if one wants to access it.  
>> This completely breaks encapsulation.
Maybe  for a good reason. Here I am undecided. Why does one need to access these
internal things?

LS> Max always insisted that the way the database handles blank nodes should
LS> be "unavailable to the developer",
LS> but I think that the developer needs indeed to do somethinbg with blank 
LS> nodes, +1
Hmm,  might  also cause more troubles. Can someone give at least 1 reasons, what
this internal access is needed for?

>> * Blank node IDs: Sesame exposes them -- one can extract the blank  
>> node ID xxx from a blank node (toString() should return _:xxx) and  
>> create a blank node from a given ID. This is very helpful for Ajax- 
>> style client-server communication.
>>   
LS> yep, similar with jena.
Hmm, its clearly 'not clean'. On the other hand its clearly useful.
What  do we do with stores that use no internal blank nodes ids or cannot create
nodes from ids. Throw an exception? Return null?

>> * Should Variable really extend Node? Then one can create a Statement  
>> that contains Variable.ANY (which is something the type system should  
>> prevent, right?).
>>   
LS> +1
S> shouldnt be needed, the parameters where variables are used are usually
LS> "NodeOrVariable" "resourceOrVariable", so Variable can be independent
LS> of node, or?
Hu, right, bug!

>> * File extensions: class Syntax should store the file extension in  
>> addition to the mime type.
>>   
LS> +1
Ok, what are the conventions here?
".rdf.xml" for RDF/XML
".rdf.nt"  for N-triples
".n3" for Turtle ? or ".ttl" ?

>> * toString()
>> ** Literals: Adhere to Turtle syntax? Maybe it should not return the  
>> getValue() result.
>>   
LS> -1,
LS> no thats the "toSparql()" method,
LS> toString returns what you would show in a user interface!
Agree to leo.


>> ** Blank nodes: return a blank node URI, not just the blank node ID.
LS> -1
LS> There ARE NO blank node URIs,
LS> you are mixing something up here.
LS> Blank nodes are devined as NOT BEING AN URI.
Agree with leo.

>> * Concurrent modification: throw an exception; now (with Sesame),
>> RDF2Go just gets stuck.
>>   
LS> part of sesame, not to be done here,
LS> (impossible to do on rdf2go level, really)
LS> this is hidden DEEP inside the transaction system of sesame, to hack it 
LS> in rdf2go, you would have
LS> to re-build the whole sesame complexion - don't think about it

LS> this will also be solved in the next sesame releases - they allow then a 
LS> better locking model!
LS> this is a known problem, sesames are working on a solution
Agree with leo.


>> ** Example: iterating over statements while removing some of them. It
>> would be nice, if Iterator.remove() worked here.
LS> -1
LS> not possible in any rdf framework,
LS> would be nice, but out of question for now.
Agree,  would  be nice. Would be really nice. But if the triple stores cannot do
it, we also cannot promise it.


>> * FeatureDirectory: Find out what features the underlying engine
>> supports.

>> ** Main candidate: If there is a triple store then one probably  
>> cannot add new models.
Well,  that is trivial by calling ModelFactory.createModelSet - if you don't get
one, there is none. If you have a ModelSet, you have to be able to create Models
*in it*.

>> * findReifications(). I have a simple implementation, let me know if  
>> you are interested.
LS> +1, this misses!!!
LS> Jena has it with getReifiedStatement(), its crucial for the RDF standard
LS> reification is in the standard, independent of how loud you cry "it sucks"
Agree,  thats  a  nice  candidate  for  usability  improvement without breakling
anything. Let me know your concrete suggestions.

>> * Namespace support
>> ** Read and write to the underlying repository.
LS> +1, meaning you want to expose the "setnamespacePrefix" method?
Please  educate  me.  To what *are* namespace prefixes registered? To models? to
modelsets? Ca I define the same namespace different for the same modelset but in
different models? If you have API suggestions here, let me know.

>> ** Use for pretty-printing that honors namespace prefixes.
LS> -1
LS> done in the underlying implementations already, no changes needed in rdf2go
yep.

What about persisting the namespaces in the model/modelset via the NAO ontology?
Some serialisations cannot store them, otherwise.


>> !! Naming
>> * I've had good experiences with never writing acronyms in caps (even
>> though it breaks standard Java API conventions). Example: URIImpl ->  
>> UriImpl.
LS> No, URI is also all-caps in java.net.*
>> * URI should be renamed to something else, it should not clash with  
>> the standard Java API name that is additionally used in the same  
>> context. Suggestion: URINode or UriNode.
LS> No, this is manicure.
LS> This is a change that will break tons of code for no reason other
LS> than style.
Agree.

@Leo: Thanks for answering most parts ;-)



From voelkel at fzi.de  Tue Oct  9 16:03:36 2007
From: voelkel at fzi.de (=?iso-8859-15?Q?Max_V=F6lkel?=)
Date: Tue, 9 Oct 2007 16:03:36 +0200
Subject: [Rdf2go-devel] Further questions to RDF design
Message-ID: <473627166.20071009160336@fzi.de>

  I  just  checked  Adunas  code  for the RDF2Go adapter to sesame, and found some
  interesting questions in the source code.

  Maybe you have answers/opinions.

1)
 * TODO: RDF2Go inconsistency: a Repository returns language tags not as they
 * where given to the Repository, but as toLowerCase(). So testing of
 * equalness to the original language tag fails. Maybe we should adopt this
 * behaviour in rdf2go.
What  should  be  the  behaviour  of  RDF2Go  for  language  tags?  Currently is
unspecified.

2) Reasoning

 // overridden: inferred statements end up having no context, so the
 // Model does not see them (findStatements, contains, etc. do not
 // encounter them). This may change in the future, once
 // MemoryStoreRDFSInferences starts to support different inferencing
 // and inferred statement insertion strategies.

Hmm, how should RDF2Go deal with inferred statements? When *do* they show up?
Only in sparql queries? Is that good?

Kind Regards,
Max
--
       Max V?lkel
       voelkel at fzi.de | www.Xam.de
       office     +49 721 96 54-854
       mobile     +49 171 83 59 678
--
FZI Forschungszentrum Informatik an der Universit?t Karlsruhe
Haid-und-Neu-Str. 10-14, D-76131 Karlsruhe
Tel.: +49-721-9654-0, Fax: +49-721-9654-959
Stiftung des b?rgerlichen Rechts, Az: 14-0563.1 Regierungspr?sidium Karlsruhe.
Vorstand: Prof. Dr.-Ing. R?diger Dillmann, Dipl. Wi.-Ing. Michael Flor
Prof. Dr. Dr.-Ing. Jivka Ovtcharova, Prof. Dr. rer. nat. Rudi Studer
Vorsitzender des Kuratoriums: Ministerialdirigent G?nther Le?nerkraus



From axel at rauschma.de  Tue Oct  9 19:33:20 2007
From: axel at rauschma.de (Axel Rauschmayer)
Date: Tue, 9 Oct 2007 19:33:20 +0200
Subject: [Rdf2go-devel] RDF2Go Feedback
In-Reply-To: <234535961.20071009145022@fzi.de>
References: <94562A73-BF17-478C-AD47-9BA0A43E46CA@rauschma.de>
	<470B676D.3040905@dfki.de> <234535961.20071009145022@fzi.de>
Message-ID: <65479366-7AE0-4DF1-B037-E6BA2DD97471@rauschma.de>

Hi guys! Thanks for answering...

>>> * QueryResultTable.getVariables() should return a list (and not
>>> Set<String>). Reason: order is significant.
>>>
> LS> correct, sets are unsorted.
> LS> This is indeed WRONG in the current version, meaning its a bug.
> Why?  A  sparql  query  result  is  in fact a set of bindings for  
> variables. You
> can retrieve the variables and get the results for each of them.
>
> I guess nowhere in the specs it says: If you ask for
> SELECT ?a ?b WHERE .... the result set has to contain "a" before "b".
> By  trying  to put the lowest semantic burden on implementations, I  
> deliberately
> have NOT choosen a list.

My main use case is this: The user formulates a query and then would  
like to see the result in a table. It will be confusing if the order  
of the columns is different than what she had specified in the SELECT  
clause. Example: "SELECT ?subj ?pred ?obj WHERE ?subj ?pred ?obj."

> LS> All this may be correct, but its too much chnage now, and all  
> our code
> LS> will be invalid.
> Furthermore,  interfaces  have  much better extensibility than  
> abstract/concrete
> classes. Even in my own few programming projects, I was very happy  
> to be able to
> write myclass implements rdf2go.URI.
>
> LS> Leave as it is, we don't need to be more clever thatn jena &  
> sesame
> Also agree.

True. I don't have a strong opinion either way, I've just encountered  
too many projects recently that overdo it with the interfaces; but  
this might be a case where they are justified.

>>> ** getUnderlyingBlankNode() is not accessible via interface. That  
>>> is,
>>> one must cast BlankNode to BlankNodeImpl if one wants to access it.
>>> This completely breaks encapsulation.
> Maybe  for a good reason. Here I am undecided. Why does one need to  
> access these
> internal things?
>
> LS> Max always insisted that the way the database handles blank  
> nodes should
> LS> be "unavailable to the developer",
> LS> but I think that the developer needs indeed to do somethinbg  
> with blank
> LS> nodes, +1
> Hmm,  might  also cause more troubles. Can someone give at least 1  
> reasons, what
> this internal access is needed for?

My use case is (see below): I transport RDF data between (back and  
forth) a server and an Ajax-based client. If I cannot handle blank  
nodes, here, things get *really* messy.

>>> * Blank node IDs: Sesame exposes them -- one can extract the blank
>>> node ID xxx from a blank node (toString() should return _:xxx) and
>>> create a blank node from a given ID. This is very helpful for Ajax-
>>> style client-server communication.
>>>
> LS> yep, similar with jena.
> Hmm, its clearly 'not clean'. On the other hand its clearly useful.
> What  do we do with stores that use no internal blank nodes ids or  
> cannot create
> nodes from ids. Throw an exception? Return null?

I think throwing an exception is appropriate  
(UnsupportedOperationException), maybe complemented by an entry in  
the feature directory (which should be done as simply as possible,  
though, no need to go overboard here) as to whether it can be done or  
not.

>>> * File extensions: class Syntax should store the file extension in
>>> addition to the mime type.
>>>
> LS> +1
> Ok, what are the conventions here?
> ".rdf.xml" for RDF/XML
> ".rdf.nt"  for N-triples
> ".n3" for Turtle ? or ".ttl" ?

You can look it up in Sesame's RDFFormat (whose source I don't have  
available right now). I think it is:
RDF/XML = .rdf
N-Triples = .n3
Turtle = .ttl

>>> ** Blank nodes: return a blank node URI, not just the blank node ID.
> LS> -1
> LS> There ARE NO blank node URIs,
> LS> you are mixing something up here.
> LS> Blank nodes are devined as NOT BEING AN URI.
> Agree with leo.

SPARQL always prepends a "_:" to blank node labels. I don't care too  
much either way.

>>> ** Example: iterating over statements while removing some of  
>>> them. It
>>> would be nice, if Iterator.remove() worked here.
> LS> -1
> LS> not possible in any rdf framework,
> LS> would be nice, but out of question for now.
> Agree,  would  be nice. Would be really nice. But if the triple  
> stores cannot do
> it, we also cannot promise it.

That's interesting. Then you can only store it it do the removal  
later? How is this supposed to scale?

>>> * findReifications(). I have a simple implementation, let me know if
>>> you are interested.
> LS> +1, this misses!!!
> LS> Jena has it with getReifiedStatement(), its crucial for the RDF  
> standard
> LS> reification is in the standard, independent of how loud you cry  
> "it sucks"
> Agree,  thats  a  nice  candidate  for  usability  improvement  
> without breakling
> anything. Let me know your concrete suggestions.

I'll comment in a separate email.

>>> * Namespace support
>>> ** Read and write to the underlying repository.
> LS> +1, meaning you want to expose the "setnamespacePrefix" method?
> Please  educate  me.  To what *are* namespace prefixes registered?  
> To models? to
> modelsets? Ca I define the same namespace different for the same  
> modelset but in
> different models? If you have API suggestions here, let me know.

I think it should go into repositories. Many data formats such as  
Turtle or RDF/XML have a preamble with namespaces so this would allow  
one to access this kind of meta-data.

>>> ** Use for pretty-printing that honors namespace prefixes.
> LS> -1
> LS> done in the underlying implementations already, no changes  
> needed in rdf2go
> yep.

I'm not sure I understand. How can you show "http://www.w3.org/ 
1999/02/22-rdf-syntax-ns#type" as "rdf:type" to the user with RDF2Go  
currently? Showing just "type" here feels weird to me. It should be  
something like a toString(NamespaceResolver) method.

> What about persisting the namespaces in the model/modelset via the  
> NAO ontology?
> Some serialisations cannot store them, otherwise.

On second thoughts, this kind of thing is probably to specific for a  
generic API (accessing the namespace meta-data isn't). Not very many  
RDF2Go users will want to change the namespaces, so this might be  
another use case for the feature directory. To summarize:
- Writing namespace meta-data: throw an exception if it can't be  
done, offer a way to find out programmatically if this feature is there.
- Reading namespace meta-data: never fails, but might return an empty  
data structure.
- Encoding namespaces as RDF: don't do it, too specific.

Greetings,

Axel

--
Axel Rauschmayer
http://www.pst.ifi.lmu.de/~rauschma/





From axel at rauschma.de  Tue Oct  9 19:37:10 2007
From: axel at rauschma.de (Axel Rauschmayer)
Date: Tue, 9 Oct 2007 19:37:10 +0200
Subject: [Rdf2go-devel] RDF2Go Feedback
In-Reply-To: <470B676D.3040905@dfki.de>
References: <94562A73-BF17-478C-AD47-9BA0A43E46CA@rauschma.de>
	<470B676D.3040905@dfki.de>
Message-ID: <6DF300E3-1A18-41A4-B30E-90571B08E71C@rauschma.de>

> There are some changes suggested like "rename a class" or
> "make it a Bean instead of an interface".
> This will not change funcitonality, will not make the code work  
> faster or better.
> It is just "more beautiful in the eye of the observer"
>
> we are not in a beauty contest.
>
> always keep in mind that the investment in created code using  
> RDF2Go is already in the area of 10k-50k Euros,
> do you want to break 50.000? of code just because of uppercases???

Oh, I wholeheartedly agree. I've made the suggestions with varying  
degrees of emphasis. Changing one's mind too often is detrimental to  
the code as well. It is just for me that when it comes to code, I  
look at all aspects (however trivial they may be) and like to discuss  
them, while knowing full well that some of them do not really matter  
that much.

But, I do notice the opposite with Eclipse plugin programming: They  
are so scared of changing anything that it has become a usability  
problem. E.g. generics and enums really help with quickly looking up  
stuff and they still don't use them.

>> * *Returning* C<? extends T> is usually discouraged, see the  
>> generics  tutorial (for arguments though, it is the way to go).  
>> Better: C<T>.
>>
> haha, music in my ears, I always thought that returning a generics  
> like this was wrong,
> thanks for pointing it out.
> could you give a link to the tutorial part you refer to?

I think it was in Bracha's generics tutorial (if you google, you can  
find a PDF version of it, as well):
http://java.sun.com/docs/books/tutorial/extra/generics/

Greetings,

Axel

--
Axel Rauschmayer
http://www.pst.ifi.lmu.de/~rauschma/





From leo.sauermann at dfki.de  Tue Oct  9 19:37:36 2007
From: leo.sauermann at dfki.de (Leo Sauermann)
Date: Tue, 09 Oct 2007 19:37:36 +0200
Subject: [Rdf2go-devel] RDF2Go Feedback
In-Reply-To: <234535961.20071009145022@fzi.de>
References: <94562A73-BF17-478C-AD47-9BA0A43E46CA@rauschma.de>
	<470B676D.3040905@dfki.de> <234535961.20071009145022@fzi.de>
Message-ID: <470BBC60.4070906@dfki.de>

Axel,

this is now a heated discussion, your ideas are very good and you see 
that you made them at the right moment!
so - don't get demotivated by our comments, you hit a nerve
:-)


It was Max V?lkel who said at the right time 09.10.2007 14:50 the 
following words:
> Hi, find my personal opinions below.
>
> LS> ==== begin of serious message ====
> LS> we are not in a beauty contest.
> Agree.
>
> LS> we are not a bunch of hackers having fun with code, there is companies
> LS> around us that depend on what we decide here.
> Yes, we should be really careful of changing RDF2Go. Extending is ok.
> The difference is well explained in some Java document.
>
> LS> ==== end of serious message ====
>   
thx for replying to this, good to talk about these "meta-discussion" 
level :-)))

For the rest, I only reply to things where I change my mind or where no 
agreement was yet reached.

>   
>>> * *Returning* C<? extends T> is usually discouraged, see the generics
>>> tutorial (for arguments though, it is the way to go). Better: C<T>.
>>>       
> LS> haha, music in my ears, I always thought that returning a generics like
> LS> this was wrong,
> LS> thanks for pointing it out.
> LS> could you give a link to the tutorial part you refer to?
> Yep, it seems I misunderstood some parts of the tutorial, maybe.
>
> I am not sure how this change is in terms of binary compatibility.
>   
Axel: could you point us to the place in the java tutorial where it says so?
(I tried to find it, but didn't)


Binary Compability:
No changes expected, I just tried it in a little experiment:

    static class A {    }
    static class B extends A { }
   
    public static Iterator<A> returnDirect(){ return null;   }
    public static Iterator<? extends A> returnExtends() {  return null;  }

    public static void main(String[] args) {
        Iterator<? extends A> myVar = returnExtends();
        myVar = returnDirect();
        // The next one does not compile
        // Type mismatch: cannot convert from Iterator<capture-of ? 
extends  TestReturnValues.A> to Iterator<TestReturnValues.A>
        // Iterator<A> myVar1 = returnExtends();
    }

This is no problem, at the moment everyone has used Iterator<? extends 
A> as variables.
There may be problems when you pass variables through.
But as <? extends A> can be assigned with an A, I think this is ok.

also, once switched, we cannot switch back, but that should be no 
question if we switch to "the right thing"
>   
>>> * QueryResultTable.getVariables() should return a list (and not
>>> Set<String>). Reason: order is significant.
>>>   
>>>       
> LS> correct, sets are unsorted.
> LS> This is indeed WRONG in the current version, meaning its a bug.
> Why?  A  sparql  query  result  is  in fact a set of bindings for variables. You
> can retrieve the variables and get the results for each of them.
>
> I guess nowhere in the specs it says: If you ask for
> SELECT ?a ?b WHERE .... the result set has to contain "a" before "b".
> By  trying  to put the lowest semantic burden on implementations, I deliberately
> have NOT choosen a list.
>   
ok, Max is right, the variables in QueryRow are unordered, the only 
method there being Node getValue(String varname);
Ok, lets leave it like it is.

>   
>>> * URI and URIImpl (similar: Literal, ...)
>>> ** Is this level of indirection really needed? Abstract classes are  
>>> sometimes a simpler solution than an interface + a default  
>>> implementation. If there is only ever going to be a single  
>>> implementation, there should be no interface at all, just a single  
>>> concrete class.
>>> ** In any case: Shouldn't URIImpl be a class that is completely  
>>> internal? Right now, it is needed if you want to create a static  
>>> constant.
>>> *** There should be a static factory for creating URI and literals  
>>> instances (so that URIImpl can be completely private again).
>>>   
>>>       
> LS> All this may be correct, but its too much chnage now, and all our code 
> LS> will be invalid.
> Furthermore,  interfaces  have  much better extensibility than abstract/concrete
> classes. Even in my own few programming projects, I was very happy to be able to
> write myclass implements rdf2go.URI.
>
> LS> Leave as it is, we don't need to be more clever thatn jena & sesame
> Also agree.
>
>   
>>> ** getUnderlyingBlankNode() is not accessible via interface. That is,  
>>> one must cast BlankNode to BlankNodeImpl if one wants to access it.  
>>> This completely breaks encapsulation.
>>>       
> Maybe  for a good reason. Here I am undecided. Why does one need to access these
> internal things?
>
> LS> Max always insisted that the way the database handles blank nodes should
> LS> be "unavailable to the developer",
> LS> but I think that the developer needs indeed to do somethinbg with blank 
> LS> nodes, +1
> Hmm,  might  also cause more troubles. Can someone give at least 1 reasons, what
> this internal access is needed for?
>   
A search through the whole nepomuk code gave only one use of the method,
inside the openRDF adapter's conversion methods.
so +1 argument for Max and hiding the method.

>   
>>> * Blank node IDs: Sesame exposes them -- one can extract the blank  
>>> node ID xxx from a blank node (toString() should return _:xxx) and  
>>> create a blank node from a given ID. This is very helpful for Ajax- 
>>> style client-server communication.
>>>   
>>>       
> LS> yep, similar with jena.
> Hmm, its clearly 'not clean'. On the other hand its clearly useful.
> What  do we do with stores that use no internal blank nodes ids or cannot create
> nodes from ids. Throw an exception? Return null?
>   
as related to above remark,
leave it secretly hidden until somebody else brings up a good use case.

>   
>>> * Should Variable really extend Node? Then one can create a Statement  
>>> that contains Variable.ANY (which is something the type system should  
>>> prevent, right?).
>>>   
>>>       
> LS> +1
> S> shouldnt be needed, the parameters where variables are used are usually
> LS> "NodeOrVariable" "resourceOrVariable", so Variable can be independent
> LS> of node, or?
> Hu, right, bug!
>
>   
>>> * File extensions: class Syntax should store the file extension in  
>>> addition to the mime type.
>>>   
>>>       
> LS> +1
> Ok, what are the conventions here?
> ".rdf.xml" for RDF/XML
> ".rdf.nt"  for N-triples
> ".n3" for Turtle ? or ".ttl" ?
>   
conventions can be copy/pasted from here:
https://src.aduna-software.org/svn/org.openrdf/projects/sesame2/openrdf-rio/openrdf-rio-api/src/main/java/org/openrdf/rio/RDFFormat.java

I would never suggest ".xml" and rather rank "rdf" and "trix" higher
for turtle, it says ".ttl"  in the standard
http://www.dajobe.org/2004/01/turtle/#sec-mime

Hence:
.rdf for rdf/xml
.nt ntriples
.ttl for turtle
.n3 for N3
.trix for trix
.trig for trig



>   
>>> * toString()
>>> ** Literals: Adhere to Turtle syntax? Maybe it should not return the  
>>> getValue() result.
>>>   
>>>       
> LS> -1,
> LS> no thats the "toSparql()" method,
> LS> toString returns what you would show in a user interface!
> Agree to leo.
>
>
>   
>>> ** Blank nodes: return a blank node URI, not just the blank node ID.
>>>       
> LS> -1
> LS> There ARE NO blank node URIs,
> LS> you are mixing something up here.
> LS> Blank nodes are devined as NOT BEING AN URI.
> Agree with leo.
>
>   
>>> * Concurrent modification: throw an exception; now (with Sesame),
>>> RDF2Go just gets stuck.
>>>   
>>>       
> LS> part of sesame, not to be done here,
> LS> (impossible to do on rdf2go level, really)
> LS> this is hidden DEEP inside the transaction system of sesame, to hack it 
> LS> in rdf2go, you would have
> LS> to re-build the whole sesame complexion - don't think about it
>
> LS> this will also be solved in the next sesame releases - they allow then a 
> LS> better locking model!
> LS> this is a known problem, sesames are working on a solution
> Agree with leo.
>
>
>   
>>> ** Example: iterating over statements while removing some of them. It
>>> would be nice, if Iterator.remove() worked here.
>>>       
> LS> -1
> LS> not possible in any rdf framework,
> LS> would be nice, but out of question for now.
> Agree,  would  be nice. Would be really nice. But if the triple stores cannot do
> it, we also cannot promise it.
>
>
>   
>>> * FeatureDirectory: Find out what features the underlying engine
>>> supports.
>>>       
>
>   
>>> ** Main candidate: If there is a triple store then one probably  
>>> cannot add new models.
>>>       
> Well,  that is trivial by calling ModelFactory.createModelSet - if you don't get
> one, there is none. If you have a ModelSet, you have to be able to create Models
> *in it*.
>
>   
>>> * findReifications(). I have a simple implementation, let me know if  
>>> you are interested.
>>>       
> LS> +1, this misses!!!
> LS> Jena has it with getReifiedStatement(), its crucial for the RDF standard
> LS> reification is in the standard, independent of how loud you cry "it sucks"
> Agree,  thats  a  nice  candidate  for  usability  improvement without breakling
> anything. Let me know your concrete suggestions.
>
>   
>>> * Namespace support
>>> ** Read and write to the underlying repository.
>>>       
> LS> +1, meaning you want to expose the "setnamespacePrefix" method?
> Please  educate  me.  To what *are* namespace prefixes registered? To models? to
> modelsets? Ca I define the same namespace different for the same modelset but in
> different models? If you have API suggestions here, let me know.
>   
usually, they are defined on the level of *ugh*. :-)
In sesame on ModelSet, but thats because they don't have models:
http://www.openrdf.com/doc/sesame2/api/org/openrdf/repository/RepositoryConnection.html#getNamespace(java.lang.String)

I owuld propose to copy the sesame stuff (simplifying the getNamespaces 
method, they made their own abstraction framework for this :-), but only 
because I am too lazy to look on jena now

String     getNamespace(String prefix)
          Gets the namespace that is associated with the specified 
prefix, if any.
Map<String, String>  getNamespaces()
          Get all namespaces as a map of prefix to namespace. The 
returned map is an unmodifiable view on the namespaces. (compare to 
Collections.unmodifiableMap())
void     removeNamespace(String prefix)
void     setNamespace(String prefix, String name)

(could someone look for jena?)
>   
>>> ** Use for pretty-printing that honors namespace prefixes.
>>>       
> LS> -1
> LS> done in the underlying implementations already, no changes needed in rdf2go
> yep.
>
> What about persisting the namespaces in the model/modelset via the NAO ontology?
> Some serialisations cannot store them, otherwise.
>   
bad idea, would fuck up every JUnit test
assertEquals("serialization broken", sizebeforeIstoredIt, 
sizeAfterILoadedIt)


>
>   
>>> !! Naming
>>> * I've had good experiences with never writing acronyms in caps (even
>>> though it breaks standard Java API conventions). Example: URIImpl ->  
>>> UriImpl.
>>>       
> LS> No, URI is also all-caps in java.net.*
>   
>>> * URI should be renamed to something else, it should not clash with  
>>> the standard Java API name that is additionally used in the same  
>>> context. Suggestion: URINode or UriNode.
>>>       
> LS> No, this is manicure.
> LS> This is a change that will break tons of code for no reason other
> LS> than style.
> Agree.
>
> @Leo: Thanks for answering most parts ;-)
>
>   
ok, so that was a hard chat..

Axel, its your turn :-)

best
Leo

-- 
____________________________________________________
DI Leo Sauermann       http://www.dfki.de/~sauermann 

Deutsches Forschungszentrum fuer 
Kuenstliche Intelligenz DFKI GmbH
Trippstadter Strasse 122
P.O. Box 2080           Fon:   +49 631 20575-116
D-67663 Kaiserslautern  Fax:   +49 631 20575-102
Germany                 Mail:  leo.sauermann at dfki.de

Geschaeftsfuehrung:
Prof.Dr.Dr.h.c.mult. Wolfgang Wahlster (Vorsitzender)
Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats:
Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
____________________________________________________

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ontoware.org/pipermail/rdf2go-devel/attachments/20071009/1c5da6b2/attachment-0001.html 

From leo.sauermann at dfki.de  Tue Oct  9 19:44:03 2007
From: leo.sauermann at dfki.de (Leo Sauermann)
Date: Tue, 09 Oct 2007 19:44:03 +0200
Subject: [Rdf2go-devel] Further questions to RDF design
In-Reply-To: <473627166.20071009160336@fzi.de>
References: <473627166.20071009160336@fzi.de>
Message-ID: <470BBDE3.8030800@dfki.de>

It was Max V?lkel who said at the right time 09.10.2007 16:03 the 
following words:
>   I  just  checked  Adunas  code  for the RDF2Go adapter to sesame, and found some
>   interesting questions in the source code.
>
>   Maybe you have answers/opinions.
>
> 1)
>  * TODO: RDF2Go inconsistency: a Repository returns language tags not as they
>  * where given to the Repository, but as toLowerCase(). So testing of
>  * equalness to the original language tag fails. Maybe we should adopt this
>  * behaviour in rdf2go.
> What  should  be  the  behaviour  of  RDF2Go  for  language  tags?  Currently is
> unspecified.
>   
oh, uncharted waters....

I would not implemented any logic in RDF2Go. Let it be handled underneath.

> 2) Reasoning
>
>  // overridden: inferred statements end up having no context, so the
>  // Model does not see them (findStatements, contains, etc. do not
>  // encounter them). This may change in the future, once
>  // MemoryStoreRDFSInferences starts to support different inferencing
>  // and inferred statement insertion strategies.
>
> Hmm, how should RDF2Go deal with inferred statements? When *do* they show up?
> Only in sparql queries? Is that good?
>   
hm, no.
That very very depends on the underlying inference engine.

As in RDF2Go, there is no inference visible in any stage, this can be 
ignored.

In sesame, many methods have parameters
find(spo, boolena includeinferred, Resource... context)

and I think they go down to the store as well, they often had this 
"isInferred" flag at the level of statements,
etc.

So, it completly depends on the options of the underlying model
whether and how inference shows up.

best
Leo



> Kind Regards,
> Max
> --
>        Max V?lkel
>        voelkel at fzi.de | www.Xam.de
>        office     +49 721 96 54-854
>        mobile     +49 171 83 59 678
> --
> FZI Forschungszentrum Informatik an der Universit?t Karlsruhe
> Haid-und-Neu-Str. 10-14, D-76131 Karlsruhe
> Tel.: +49-721-9654-0, Fax: +49-721-9654-959
> Stiftung des b?rgerlichen Rechts, Az: 14-0563.1 Regierungspr?sidium Karlsruhe.
> Vorstand: Prof. Dr.-Ing. R?diger Dillmann, Dipl. Wi.-Ing. Michael Flor
> Prof. Dr. Dr.-Ing. Jivka Ovtcharova, Prof. Dr. rer. nat. Rudi Studer
> Vorsitzender des Kuratoriums: Ministerialdirigent G?nther Le?nerkraus
>
>
> _______________________________________________
> Rdf2go-devel mailing list
> Rdf2go-devel at ontoware.org
> http://ontoware.org/mailman/listinfo/rdf2go-devel
>
>   


-- 
____________________________________________________
DI Leo Sauermann       http://www.dfki.de/~sauermann 

Deutsches Forschungszentrum fuer 
Kuenstliche Intelligenz DFKI GmbH
Trippstadter Strasse 122
P.O. Box 2080           Fon:   +49 631 20575-116
D-67663 Kaiserslautern  Fax:   +49 631 20575-102
Germany                 Mail:  leo.sauermann at dfki.de

Geschaeftsfuehrung:
Prof.Dr.Dr.h.c.mult. Wolfgang Wahlster (Vorsitzender)
Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats:
Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
____________________________________________________



From axel at rauschma.de  Tue Oct  9 19:57:32 2007
From: axel at rauschma.de (Axel Rauschmayer)
Date: Tue, 9 Oct 2007 19:57:32 +0200
Subject: [Rdf2go-devel] Reification
Message-ID: <4966AE6E-9554-46B8-B564-62340A3A731E@rauschma.de>

I've implemented the methods below for reification. One can really  
put them anywere (into ModelSet, as instance methods; into a new  
class Reification; etc.).

Greetings,

Axel

--
Axel Rauschmayer
http://www.pst.ifi.lmu.de/~rauschma/

     public static String formatQuery(String queryTemplate, Object...  
parameters) {
         Object[] strings = new Object[parameters.length];
         for(int i=0; i < parameters.length; i++) {
             if (parameters[i] instanceof Node) {
                 strings[i] = ((Node)parameters[i]).toSPARQL();
             } else {
                 strings[i] = parameters[i].toString();
             }
         }
         return String.format(queryTemplate, strings);
     }

// The WriteContext is specific to what I am doing and has to be  
replaced (can it be taken from "stmt"?)
     public static Resource createReification(ModelSet modelSet,
             WriteContext writeContext, Statement stmt) {
         BlankNode resource = modelSet.createBlankNode();
         modelSet.addStatement(writeContext.get(), resource,  
RDF.type, RDF.Statement);
         modelSet.addStatement(writeContext.get(), resource,  
RDF.subject, stmt.getSubject());
         modelSet.addStatement(writeContext.get(), resource,  
RDF.predicate, stmt.getPredicate());
         modelSet.addStatement(writeContext.get(), resource,  
RDF.object, stmt.getObject());
         return resource;
     }

     public static Collection<Resource> findReifyingNodes(ModelSet  
modelSet, Statement stmt) {
         String queryString = formatQuery(
                 "SELECT ?node WHERE { ?node %s %s . ?node %s %s . ? 
node %s %s }",
                 RDF.subject, stmt.getSubject(),
                 RDF.predicate, stmt.getPredicate(),
                 RDF.object, stmt.getObject());
         return extractColumn(modelSet.sparqlSelect(queryString),  
"node", Resource.class);
     }

     public static boolean hasReifications(ModelSet modelSet,  
Statement stmt) {
         return findReifyingNodes(modelSet, stmt).size() > 0;
     }




From voelkel at fzi.de  Tue Oct  9 20:04:17 2007
From: voelkel at fzi.de (=?iso-8859-15?Q?Max_V=F6lkel?=)
Date: Tue, 9 Oct 2007 20:04:17 +0200
Subject: [Rdf2go-devel] Further questions to RDF design
In-Reply-To: <470BBDE3.8030800@dfki.de>
References: <473627166.20071009160336@fzi.de> <470BBDE3.8030800@dfki.de>
Message-ID: <1921966506.20071009200417@fzi.de>

>>  * TODO: RDF2Go inconsistency: a Repository returns language tags not as they
>>  * where given to the Repository, but as toLowerCase(). So testing of
>>  * equalness to the original language tag fails. Maybe we should adopt this
>>  * behaviour in rdf2go.
>> What  should  be  the  behaviour  of  RDF2Go  for  language  tags?  Currently is
>> unspecified.
>>   
LS> oh, uncharted waters....
LS> I would not implemented any logic in RDF2Go. Let it be handled underneath.
Agree,  but the API could still specify correct behaviour. But we can leave this
as is.

>> 2) Reasoning
>>
LS> As in RDF2Go, there is no inference visible in any stage, this can be
LS> ignored.
Well, I can configure reasoning at model creation time. I hope it's on then. And
I hope it will have efects. It only remains to be clarified, when theses effects
should be visible. If this is unclear, ** RDF2Go is much less portable **

we have
- hasStatement
- findStatement
- sparqlQuery

For  each  of  these  'levels  of  complexity'  we  should  decide,  if inferred
statements are included or not.

Any ideas how Jena does it?

Kind Regards,
Max
--
       Max V?lkel
       voelkel at fzi.de | www.Xam.de
       office     +49 721 96 54-854
       mobile     +49 171 83 59 678
--
FZI Forschungszentrum Informatik an der Universit?t Karlsruhe
Haid-und-Neu-Str. 10-14, D-76131 Karlsruhe
Tel.: +49-721-9654-0, Fax: +49-721-9654-959
Stiftung des b?rgerlichen Rechts, Az: 14-0563.1 Regierungspr?sidium Karlsruhe.
Vorstand: Prof. Dr.-Ing. R?diger Dillmann, Dipl. Wi.-Ing. Michael Flor
Prof. Dr. Dr.-Ing. Jivka Ovtcharova, Prof. Dr. rer. nat. Rudi Studer
Vorsitzender des Kuratoriums: Ministerialdirigent G?nther Le?nerkraus



From voelkel at fzi.de  Tue Oct  9 20:13:01 2007
From: voelkel at fzi.de (=?iso-8859-15?Q?Max_V=F6lkel?=)
Date: Tue, 9 Oct 2007 20:13:01 +0200
Subject: [Rdf2go-devel] Reification
In-Reply-To: <4966AE6E-9554-46B8-B564-62340A3A731E@rauschma.de>
References: <4966AE6E-9554-46B8-B564-62340A3A731E@rauschma.de>
Message-ID: <1223200451.20071009201301@fzi.de>

Hi Axel,

looking at your code I suggest:

in Model and ModelSet

  void reify( Resource reifiedStmt, Statement stmt);
  void reify( Resource reifiedStmt, Resource s, URI p, Node o);

So  the user has control what kind of Resource is used for the statement (URI or
bnode). The method should *not* add (s,p,o) to the model.


  Collection<Resource> findReifications( Statement stmt );
  Collection<Resource> findReifications( Resource s, URI p, Node o );

  boolean hasReifications(Statement stmt)
  boolean hasReifications(Resource s, URI p, Node o);

---

Ok?

I created http://octopus13.fzi.de:8080/browse/RTGO-23


Kind Regards,
Max
--
       Max V?lkel
       voelkel at fzi.de | www.Xam.de
       office     +49 721 96 54-854
       mobile     +49 171 83 59 678
--
FZI Forschungszentrum Informatik an der Universit?t Karlsruhe
Haid-und-Neu-Str. 10-14, D-76131 Karlsruhe
Tel.: +49-721-9654-0, Fax: +49-721-9654-959
Stiftung des b?rgerlichen Rechts, Az: 14-0563.1 Regierungspr?sidium Karlsruhe.
Vorstand: Prof. Dr.-Ing. R?diger Dillmann, Dipl. Wi.-Ing. Michael Flor
Prof. Dr. Dr.-Ing. Jivka Ovtcharova, Prof. Dr. rer. nat. Rudi Studer
Vorsitzender des Kuratoriums: Ministerialdirigent G?nther Le?nerkraus



From leo.sauermann at dfki.de  Tue Oct  9 20:30:23 2007
From: leo.sauermann at dfki.de (Leo Sauermann)
Date: Tue, 09 Oct 2007 20:30:23 +0200
Subject: [Rdf2go-devel] Further questions to RDF design
In-Reply-To: <1921966506.20071009200417@fzi.de>
References: <473627166.20071009160336@fzi.de> <470BBDE3.8030800@dfki.de>
	<1921966506.20071009200417@fzi.de>
Message-ID: <470BC8BF.5020906@dfki.de>

It was Max V?lkel who said at the right time 09.10.2007 20:04 the 
following words:
>>>  * TODO: RDF2Go inconsistency: a Repository returns language tags not as they
>>>  * where given to the Repository, but as toLowerCase(). So testing of
>>>  * equalness to the original language tag fails. Maybe we should adopt this
>>>  * behaviour in rdf2go.
>>> What  should  be  the  behaviour  of  RDF2Go  for  language  tags?  Currently is
>>> unspecified.
>>>   
>>>       
> LS> oh, uncharted waters....
> LS> I would not implemented any logic in RDF2Go. Let it be handled underneath.
> Agree,  but the API could still specify correct behaviour. But we can leave this
> as is.
>
>   
>>> 2) Reasoning
>>>
>>>       
> LS> As in RDF2Go, there is no inference visible in any stage, this can be
> LS> ignored.
> Well, I can configure reasoning at model creation time. I hope it's on then. And
> I hope it will have efects. It only remains to be clarified, when theses effects
> should be visible. If this is unclear, ** RDF2Go is much less portable **
>
> we have
> - hasStatement
> - findStatement
> - sparqlQuery
>
> For  each  of  these  'levels  of  complexity'  we  should  decide,  if inferred
> statements are included or not.
>
> Any ideas how Jena does it?
>   
yep, you go:
model = ...
infModel = ModelFactory.createInfModel...(model ...);

model.listStatements()
infModel.listStatements()

be enlighted by the difference :-)

infModel.getRawModel() -> the underlying model

additionally, you can do something like:
infModel.getDeductionsModel() ---> only the inferred statements.
http://jena.sourceforge.net/javadoc/com/hp/hpl/jena/rdf/model/InfModel.html#getDeductionsModel()

Note, that Jena is completly screwed when it comes to Context (ModelSet),
as Jenas architecture is somehow old.
but alas, the context where inferred statements are put in is a question 
of academic and practical dispute anyway,
NRL!!!

best
Leo

> Kind Regards,
> Max
> --
>        Max V?lkel
>        voelkel at fzi.de | www.Xam.de
>        office     +49 721 96 54-854
>        mobile     +49 171 83 59 678
> --
> FZI Forschungszentrum Informatik an der Universit?t Karlsruhe
> Haid-und-Neu-Str. 10-14, D-76131 Karlsruhe
> Tel.: +49-721-9654-0, Fax: +49-721-9654-959
> Stiftung des b?rgerlichen Rechts, Az: 14-0563.1 Regierungspr?sidium Karlsruhe.
> Vorstand: Prof. Dr.-Ing. R?diger Dillmann, Dipl. Wi.-Ing. Michael Flor
> Prof. Dr. Dr.-Ing. Jivka Ovtcharova, Prof. Dr. rer. nat. Rudi Studer
> Vorsitzender des Kuratoriums: Ministerialdirigent G?nther Le?nerkraus
>
>
>   


-- 
____________________________________________________
DI Leo Sauermann       http://www.dfki.de/~sauermann 

Deutsches Forschungszentrum fuer 
Kuenstliche Intelligenz DFKI GmbH
Trippstadter Strasse 122
P.O. Box 2080           Fon:   +49 631 20575-116
D-67663 Kaiserslautern  Fax:   +49 631 20575-102
Germany                 Mail:  leo.sauermann at dfki.de

Geschaeftsfuehrung:
Prof.Dr.Dr.h.c.mult. Wolfgang Wahlster (Vorsitzender)
Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats:
Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
____________________________________________________

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ontoware.org/pipermail/rdf2go-devel/attachments/20071009/063241a9/attachment.html 

From leo.sauermann at dfki.de  Tue Oct  9 20:34:41 2007
From: leo.sauermann at dfki.de (Leo Sauermann)
Date: Tue, 09 Oct 2007 20:34:41 +0200
Subject: [Rdf2go-devel] Reification
In-Reply-To: <1223200451.20071009201301@fzi.de>
References: <4966AE6E-9554-46B8-B564-62340A3A731E@rauschma.de>
	<1223200451.20071009201301@fzi.de>
Message-ID: <470BC9C1.4080907@dfki.de>

It was Max V?lkel who said at the right time 09.10.2007 20:13 the 
following words:
> Hi Axel,
>
> looking at your code I suggest:
>
> in Model and ModelSet
>
>   void reify( Resource reifiedStmt, Statement stmt);
>   void reify( Resource reifiedStmt, Resource s, URI p, Node o);
>
> So  the user has control what kind of Resource is used for the statement (URI or
> bnode). The method should *not* add (s,p,o) to the model.
>   
good idea, but a convenience method to auto-create the bnode is 
typically part of the deal:

Jena:

ReifiedStatement     createReifiedStatement(Statement s)
          Answer a ReifiedStatement that encodes _s_ and belongs to this 
Model.
 ReifiedStatement     createReifiedStatement(java.lang.String uri, 
Statement s)
          answer a ReifiedStatement that encodes _s_, belongs to this 
Model, and is a Resource with that _uri_.

I suggest:
Resource createReifiedStatement(Statement s)
          Answer a ReifiedStatement that encodes _s_ and belongs to this 
Model.
Resource createReifiedStatement(Resource resource, Statement s)
          answer a ReifiedStatement that encodes _s_, belongs to this 
Model, and is a Resource with that _uri_.

let the return value be a resource - to allow stacking (neat to have!)

Note that createReifiedStatement is better than "reify" as it maps to 
the FactoryMethods createUri(), etc....!

also, I see no reason to expose the methods with SPO signature (is just 
overhead).
>
>   Collection<Resource> findReifications( Statement stmt );
>   Collection<Resource> findReifications( Resource s, URI p, Node o );
>
>   boolean hasReifications(Statement stmt)
>   boolean hasReifications(Resource s, URI p, Node o);
>
> ---
>
> Ok?
>
> I created http://octopus13.fzi.de:8080/browse/RTGO-23
>
>
> Kind Regards,
> Max
> --
>        Max V?lkel
>        voelkel at fzi.de | www.Xam.de
>        office     +49 721 96 54-854
>        mobile     +49 171 83 59 678
> --
> FZI Forschungszentrum Informatik an der Universit?t Karlsruhe
> Haid-und-Neu-Str. 10-14, D-76131 Karlsruhe
> Tel.: +49-721-9654-0, Fax: +49-721-9654-959
> Stiftung des b?rgerlichen Rechts, Az: 14-0563.1 Regierungspr?sidium Karlsruhe.
> Vorstand: Prof. Dr.-Ing. R?diger Dillmann, Dipl. Wi.-Ing. Michael Flor
> Prof. Dr. Dr.-Ing. Jivka Ovtcharova, Prof. Dr. rer. nat. Rudi Studer
> Vorsitzender des Kuratoriums: Ministerialdirigent G?nther Le?nerkraus
>
>
> _______________________________________________
> Rdf2go-devel mailing list
> Rdf2go-devel at ontoware.org
> http://ontoware.org/mailman/listinfo/rdf2go-devel
>
>   


-- 
____________________________________________________
DI Leo Sauermann       http://www.dfki.de/~sauermann 

Deutsches Forschungszentrum fuer 
Kuenstliche Intelligenz DFKI GmbH
Trippstadter Strasse 122
P.O. Box 2080           Fon:   +49 631 20575-116
D-67663 Kaiserslautern  Fax:   +49 631 20575-102
Germany                 Mail:  leo.sauermann at dfki.de

Geschaeftsfuehrung:
Prof.Dr.Dr.h.c.mult. Wolfgang Wahlster (Vorsitzender)
Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats:
Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
____________________________________________________



From voelkel at fzi.de  Tue Oct  9 20:44:17 2007
From: voelkel at fzi.de (=?iso-8859-15?Q?Max_V=F6lkel?=)
Date: Tue, 9 Oct 2007 20:44:17 +0200
Subject: [Rdf2go-devel] Reification
In-Reply-To: <470BC9C1.4080907@dfki.de>
References: <4966AE6E-9554-46B8-B564-62340A3A731E@rauschma.de>
	<1223200451.20071009201301@fzi.de> <470BC9C1.4080907@dfki.de>
Message-ID: <1892548284.20071009204417@fzi.de>

LS> Resource createReifiedStatement(Statement s)
LS>           Answer a ReifiedStatement that encodes _s_ and belongs to this Model.

But the statement s should NOT be added to the model doing this, right?

And we can refine to
  BlankNode createReifiedStatement(Statement s)

---

LS> Resource createReifiedStatement(Resource resource, Statement s)
LS>           answer a ReifiedStatement that encodes _s_, belongs to this 
LS> Model, and is a Resource with that _uri_.

LS> let the return value be a resource - to allow stacking (neat to have!)
ok, nicer than void, agree.

Hmm,  one  might  thing  it CREATES the statement in the model - which it should
not. It should just create the reification of a statement.

createReficationOf(..) ?

LS> also, I see no reason to expose the methods with SPO signature (is just
LS> overhead).
Uh? Ok, no problem.

Kind Regards,
Max
--
       Max V?lkel
       voelkel at fzi.de | www.Xam.de
       office     +49 721 96 54-854
       mobile     +49 171 83 59 678
--
FZI Forschungszentrum Informatik an der Universit?t Karlsruhe
Haid-und-Neu-Str. 10-14, D-76131 Karlsruhe
Tel.: +49-721-9654-0, Fax: +49-721-9654-959
Stiftung des b?rgerlichen Rechts, Az: 14-0563.1 Regierungspr?sidium Karlsruhe.
Vorstand: Prof. Dr.-Ing. R?diger Dillmann, Dipl. Wi.-Ing. Michael Flor
Prof. Dr. Dr.-Ing. Jivka Ovtcharova, Prof. Dr. rer. nat. Rudi Studer
Vorsitzender des Kuratoriums: Ministerialdirigent G?nther Le?nerkraus



From axel at rauschma.de  Tue Oct  9 20:53:01 2007
From: axel at rauschma.de (Axel Rauschmayer)
Date: Tue, 9 Oct 2007 20:53:01 +0200
Subject: [Rdf2go-devel] Further questions to RDF design
In-Reply-To: <473627166.20071009160336@fzi.de>
References: <473627166.20071009160336@fzi.de>
Message-ID: <8B994666-5AC4-4BE1-8B1E-6001FA5420E8@rauschma.de>

> 1)
>  * TODO: RDF2Go inconsistency: a Repository returns language tags  
> not as they
>  * where given to the Repository, but as toLowerCase(). So testing of
>  * equalness to the original language tag fails. Maybe we should  
> adopt this
>  * behaviour in rdf2go.
> What  should  be  the  behaviour  of  RDF2Go  for  language  tags?   
> Currently is
> unspecified.

I don't know what the "proper" way to go is, but changing the string  
feels wrong. You could make equals (and thus also hashCode) more  
tolerant, though.

>
> 2) Reasoning
>
>  // overridden: inferred statements end up having no context, so the
>  // Model does not see them (findStatements, contains, etc. do not
>  // encounter them). This may change in the future, once
>  // MemoryStoreRDFSInferences starts to support different inferencing
>  // and inferred statement insertion strategies.
>
> Hmm, how should RDF2Go deal with inferred statements? When *do*  
> they show up?
> Only in sparql queries? Is that good?

Can this decision be made on a per-model(set)/per-method-invocation  
basis? Especially when it comes to hierarchies, I see both use cases:
- Include inferred statements: When testing for descendancy.
- Exclude inferred statements: When displaying the hierarchy.

Greetings,

AR

--
Axel Rauschmayer
http://www.pst.ifi.lmu.de/~rauschma/





From leo.sauermann at dfki.de  Tue Oct  9 21:01:11 2007
From: leo.sauermann at dfki.de (Leo Sauermann)
Date: Tue, 09 Oct 2007 21:01:11 +0200
Subject: [Rdf2go-devel] Reification
In-Reply-To: <1892548284.20071009204417@fzi.de>
References: <4966AE6E-9554-46B8-B564-62340A3A731E@rauschma.de>
	<1223200451.20071009201301@fzi.de> <470BC9C1.4080907@dfki.de>
	<1892548284.20071009204417@fzi.de>
Message-ID: <470BCFF7.4010908@dfki.de>

It was Max V?lkel who said at the right time 09.10.2007 20:44 the 
following words:
> LS> Resource createReifiedStatement(Statement s)
> LS>           Answer a ReifiedStatement that encodes _s_ and belongs to this Model.
>
> But the statement s should NOT be added to the model doing this, right?
>
> And we can refine to
>   BlankNode createReifiedStatement(Statement s)
>   
whoah! now you really go for precision :-)
+1
> ---
>
> LS> Resource createReifiedStatement(Resource resource, Statement s)
> LS>           answer a ReifiedStatement that encodes _s_, belongs to this 
> LS> Model, and is a Resource with that _uri_.
>
> LS> let the return value be a resource - to allow stacking (neat to have!)
> ok, nicer than void, agree.
>
> Hmm,  one  might  thing  it CREATES the statement in the model - which it should
> not. It should just create the reification of a statement.
>
> createReficationOf(..) ?
>   
sounds better.

> LS> also, I see no reason to expose the methods with SPO signature (is just
> LS> overhead).
> Uh? Ok, no problem.
>   
yeah, keep it simple.
> Kind Regards,
> Max
> --
>        Max V?lkel
>        voelkel at fzi.de | www.Xam.de
>        office     +49 721 96 54-854
>        mobile     +49 171 83 59 678
> --
> FZI Forschungszentrum Informatik an der Universit?t Karlsruhe
> Haid-und-Neu-Str. 10-14, D-76131 Karlsruhe
> Tel.: +49-721-9654-0, Fax: +49-721-9654-959
> Stiftung des b?rgerlichen Rechts, Az: 14-0563.1 Regierungspr?sidium Karlsruhe.
> Vorstand: Prof. Dr.-Ing. R?diger Dillmann, Dipl. Wi.-Ing. Michael Flor
> Prof. Dr. Dr.-Ing. Jivka Ovtcharova, Prof. Dr. rer. nat. Rudi Studer
> Vorsitzender des Kuratoriums: Ministerialdirigent G?nther Le?nerkraus
>
>
>   


-- 
____________________________________________________
DI Leo Sauermann       http://www.dfki.de/~sauermann 

Deutsches Forschungszentrum fuer 
Kuenstliche Intelligenz DFKI GmbH
Trippstadter Strasse 122
P.O. Box 2080           Fon:   +49 631 20575-116
D-67663 Kaiserslautern  Fax:   +49 631 20575-102
Germany                 Mail:  leo.sauermann at dfki.de

Geschaeftsfuehrung:
Prof.Dr.Dr.h.c.mult. Wolfgang Wahlster (Vorsitzender)
Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats:
Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
____________________________________________________



From leo.sauermann at dfki.de  Tue Oct  9 21:09:05 2007
From: leo.sauermann at dfki.de (Leo Sauermann)
Date: Tue, 09 Oct 2007 21:09:05 +0200
Subject: [Rdf2go-devel] Further questions to RDF design
In-Reply-To: <8B994666-5AC4-4BE1-8B1E-6001FA5420E8@rauschma.de>
References: <473627166.20071009160336@fzi.de>
	<8B994666-5AC4-4BE1-8B1E-6001FA5420E8@rauschma.de>
Message-ID: <470BD1D1.6050601@dfki.de>

It was Axel Rauschmayer who said at the right time 09.10.2007 20:53 the 
following words:
>> 1)
>>  * TODO: RDF2Go inconsistency: a Repository returns language tags  
>> not as they
>>  * where given to the Repository, but as toLowerCase(). So testing of
>>  * equalness to the original language tag fails. Maybe we should  
>> adopt this
>>  * behaviour in rdf2go.
>> What  should  be  the  behaviour  of  RDF2Go  for  language  tags?   
>> Currently is
>> unspecified.
>>     
>
> I don't know what the "proper" way to go is, but changing the string  
> feels wrong. You could make equals (and thus also hashCode) more  
> tolerant, though.
>   

see
http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/#section-Literal-Equality
"The language tags, if any, compare equal."

http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/#section-Graph-Literal
"Plain literals have a lexical form and optionally a language tag as 
defined by [RFC-3066], normalized to lowercase."

so its ok to lowercase!
horray for standards.
>   
>> 2) Reasoning
>>
>>  // overridden: inferred statements end up having no context, so the
>>  // Model does not see them (findStatements, contains, etc. do not
>>  // encounter them). This may change in the future, once
>>  // MemoryStoreRDFSInferences starts to support different inferencing
>>  // and inferred statement insertion strategies.
>>
>> Hmm, how should RDF2Go deal with inferred statements? When *do*  
>> they show up?
>> Only in sparql queries? Is that good?
>>     
>
> Can this decision be made on a per-model(set)/per-method-invocation  
> basis? Especially when it comes to hierarchies, I see both use cases:
> - Include inferred statements: When testing for descendancy.
> - Exclude inferred statements: When displaying the hierarchy.
>   
It can, but I would wait with this until sesame2 is finished,
and Jena supports context
(hihihihi.......)

yes, its good input, but I think we should focus on other things for now.

best
Leo
> Greetings,
>
> AR
>
> --
> Axel Rauschmayer
> http://www.pst.ifi.lmu.de/~rauschma/
>
>
>
>
> _______________________________________________
> Rdf2go-devel mailing list
> Rdf2go-devel at ontoware.org
> http://ontoware.org/mailman/listinfo/rdf2go-devel
>   


-- 
____________________________________________________
DI Leo Sauermann       http://www.dfki.de/~sauermann 

Deutsches Forschungszentrum fuer 
Kuenstliche Intelligenz DFKI GmbH
Trippstadter Strasse 122
P.O. Box 2080           Fon:   +49 631 20575-116
D-67663 Kaiserslautern  Fax:   +49 631 20575-102
Germany                 Mail:  leo.sauermann at dfki.de

Geschaeftsfuehrung:
Prof.Dr.Dr.h.c.mult. Wolfgang Wahlster (Vorsitzender)
Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats:
Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
____________________________________________________

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ontoware.org/pipermail/rdf2go-devel/attachments/20071009/e62f3f56/attachment.html 

From voelkel at fzi.de  Tue Oct  9 21:31:30 2007
From: voelkel at fzi.de (=?iso-8859-1?Q?Max_V=F6lkel?=)
Date: Tue, 9 Oct 2007 21:31:30 +0200
Subject: [Rdf2go-devel] Further questions to RDF design
In-Reply-To: <470BD1D1.6050601@dfki.de>
References: <473627166.20071009160336@fzi.de>
	<8B994666-5AC4-4BE1-8B1E-6001FA5420E8@rauschma.de>
	<470BD1D1.6050601@dfki.de>
Message-ID: <1642177399.20071009213130@fzi.de>

>>> Hmm, how should RDF2Go deal with inferred statements? When *do*
>>> they show up?
>>> Only in sparql queries? Is that good?

It seems we should maybe go for an all-or-nothing approach:
eiother you seed inferred triples everywhere, as if they were in the model (just
when you try to delete them, nothing will happen?)

Is the jena way good for this? getModelWithoutReasoning() ?

Anyway, we must define SOME behaviour for reasoning models...

all-or-nothing is maybe the simplest possible such behaviour.

Kind Regards,
Max
--
       Max V?lkel
       voelkel at fzi.de | www.Xam.de
       office     +49 721 96 54-854
       mobile     +49 171 83 59 678
--
FZI Forschungszentrum Informatik an der Universit?t Karlsruhe
Haid-und-Neu-Str. 10-14, D-76131 Karlsruhe
Tel.: +49-721-9654-0, Fax: +49-721-9654-959
Stiftung des b?rgerlichen Rechts, Az: 14-0563.1 Regierungspr?sidium Karlsruhe.
Vorstand: Prof. Dr.-Ing. R?diger Dillmann, Dipl. Wi.-Ing. Michael Flor
Prof. Dr. Dr.-Ing. Jivka Ovtcharova, Prof. Dr. rer. nat. Rudi Studer
Vorsitzender des Kuratoriums: Ministerialdirigent G?nther Le?nerkraus



From axel at rauschma.de  Tue Oct  9 21:31:48 2007
From: axel at rauschma.de (Axel Rauschmayer)
Date: Tue, 9 Oct 2007 21:31:48 +0200
Subject: [Rdf2go-devel] Further questions to RDF design
In-Reply-To: <470BBDE3.8030800@dfki.de>
References: <473627166.20071009160336@fzi.de> <470BBDE3.8030800@dfki.de>
Message-ID: <A3F2D582-AACC-4DD0-9526-5833E5AC64CE@rauschma.de>

>> Hmm, how should RDF2Go deal with inferred statements? When *do*  
>> they show up?
>> Only in sparql queries? Is that good?
>>
> hm, no.
> That very very depends on the underlying inference engine.
>
> As in RDF2Go, there is no inference visible in any stage, this can be
> ignored.
>
> In sesame, many methods have parameters
> find(spo, boolena includeinferred, Resource... context)
>
> and I think they go down to the store as well, they often had this
> "isInferred" flag at the level of statements,
> etc.
>
> So, it completly depends on the options of the underlying model
> whether and how inference shows up.

So the recipe is: If necessary, create two views on the same  
repository ->in the underlying RDF engine<-, one with inferred  
statements, the other one without and use each view according to your  
needs. (Right?)

--
Axel Rauschmayer
http://www.pst.ifi.lmu.de/~rauschma/





From voelkel at fzi.de  Tue Oct  9 21:50:28 2007
From: voelkel at fzi.de (=?iso-8859-15?Q?Max_V=F6lkel?=)
Date: Tue, 9 Oct 2007 21:50:28 +0200
Subject: [Rdf2go-devel] Further questions to RDF design
In-Reply-To: <A3F2D582-AACC-4DD0-9526-5833E5AC64CE@rauschma.de>
References: <473627166.20071009160336@fzi.de> <470BBDE3.8030800@dfki.de>
	<A3F2D582-AACC-4DD0-9526-5833E5AC64CE@rauschma.de>
Message-ID: <04798146.20071009215028@fzi.de>

AR> So the recipe is: If necessary, create two views on the same
repository ->>in the underlying RDF engine<-, one with inferred  
AR> statements, the other one without and use each view according to your  
AR> needs. (Right?)

yes



From axel at rauschma.de  Tue Oct  9 23:01:44 2007
From: axel at rauschma.de (Axel Rauschmayer)
Date: Tue, 9 Oct 2007 23:01:44 +0200
Subject: [Rdf2go-devel] Reification
In-Reply-To: <1223200451.20071009201301@fzi.de>
References: <4966AE6E-9554-46B8-B564-62340A3A731E@rauschma.de>
	<1223200451.20071009201301@fzi.de>
Message-ID: <E53E543D-738B-4662-B1BC-4A604A43E1FA@rauschma.de>

>   void reify( Resource reifiedStmt, Statement stmt);
>   void reify( Resource reifiedStmt, Resource s, URI p, Node o);
>
> So  the user has control what kind of Resource is used for the  
> statement (URI or
> bnode). The method should *not* add (s,p,o) to the model.

Yes, that makes a lot of sense. Not sure variant 2 is really needed,  
because one can usually assume that the statement exists in RDF (same  
for find/hasReifications).

AR

--
Axel Rauschmayer
http://www.pst.ifi.lmu.de/~rauschma/





From sintek at dfki.uni-kl.de  Tue Oct  9 23:24:39 2007
From: sintek at dfki.uni-kl.de (Michael Sintek)
Date: Tue, 09 Oct 2007 23:24:39 +0200
Subject: [Rdf2go-devel] Reification
In-Reply-To: <E53E543D-738B-4662-B1BC-4A604A43E1FA@rauschma.de>
References: <4966AE6E-9554-46B8-B564-62340A3A731E@rauschma.de>	<1223200451.20071009201301@fzi.de>
	<E53E543D-738B-4662-B1BC-4A604A43E1FA@rauschma.de>
Message-ID: <470BF197.3060505@dfki.uni-kl.de>



Axel Rauschmayer wrote:
>>   void reify( Resource reifiedStmt, Statement stmt);
>>   void reify( Resource reifiedStmt, Resource s, URI p, Node o);
>>
>> So  the user has control what kind of Resource is used for the  
>> statement (URI or
>> bnode). The method should *not* add (s,p,o) to the model.
> 
> Yes, that makes a lot of sense. Not sure variant 2 is really needed,  
> because one can usually assume that the statement exists in RDF (same  
> for find/hasReifications).

I don't fully understand this remark. Do you want to say that
reified statements can be assumed to be in the normal RDF model?
This would be a wrong assumption -- one of the many usages for
reification is to have statements only reified and not directly
in the RDF model, because the latter implies that a statement
*holds* (is true), while a reified statement does not imply this.
In this way I can express "I don't believe in some statement",
e.g., <I don't_believe_in <John loves Mary>>; in this case,
the statement <John loves Mary> is not in my RDF model (and should not be
since I want to express that this statement is not true at all).

Michael


> 
> AR
> 
> --
> Axel Rauschmayer
> http://www.pst.ifi.lmu.de/~rauschma/
> 
> 
> 
> 
> _______________________________________________
> Rdf2go-devel mailing list
> Rdf2go-devel at ontoware.org
> http://ontoware.org/mailman/listinfo/rdf2go-devel

-- 
Michael Sintek -- DFKI GmbH, Kaiserslautern
http://www.michael-sintek.de -- michael.sintek at dfki.de
phone: +49 631 20575-130 -- fax: +49 631 20575-103
legal information: http://www.dfki.uni-kl.de/km/legal.html


From axel at rauschma.de  Wed Oct 10 00:30:43 2007
From: axel at rauschma.de (Axel Rauschmayer)
Date: Wed, 10 Oct 2007 00:30:43 +0200
Subject: [Rdf2go-devel] Reification
In-Reply-To: <470BCFF7.4010908@dfki.de>
References: <4966AE6E-9554-46B8-B564-62340A3A731E@rauschma.de>
	<1223200451.20071009201301@fzi.de> <470BC9C1.4080907@dfki.de>
	<1892548284.20071009204417@fzi.de> <470BCFF7.4010908@dfki.de>
Message-ID: <7289B1F4-80B0-4C91-9D68-A7AA5D489631@rauschma.de>

>> And we can refine to
>>   BlankNode createReifiedStatement(Statement s)
>>
> whoah! now you really go for precision :-)
> +1

Sorry for being in high nit-pick-mode, but:
- I've grown to dislike blank nodes (mainly because I have been  
thinking about synchronization a lot). Couldn't there be use cases  
where an implementation wants the default reified statement to be an  
(automatically created) URI node? Maybe the return value should stay  
a Resource.

> Resource createReifiedStatement(Resource resource, Statement s)

- With generics one could do:
<R extends Resource> R createReifiedStatement(R resource, Statement s)

Greetings,

Axel

--
Axel Rauschmayer
http://www.pst.ifi.lmu.de/~rauschma/





From gunnar.grimnes at dfki.de  Wed Oct 10 10:40:47 2007
From: gunnar.grimnes at dfki.de (Gunnar Aastrand Grimnes)
Date: Wed, 10 Oct 2007 10:40:47 +0200
Subject: [Rdf2go-devel] Feature request: prepare queries
Message-ID: <470C900F.7000008@dfki.de>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello all,

Since you are having so much with advancing rdf2go discussion already, can I
throw another ball in?

Would it be possible to somehow add prepared queries to rdf2go?

I.e.

Query q=model.prepareQuery("select ?name where { ?person foaf:name ?name . }");
q.setParameter("person", new
URIImpl("http://www.dfki.uni-kl.de/~grimnes/foaf.rdf#grimnes"));

etc.

Currently I need this for porting some project to rdf2go, but I've also been
wanting it before when doing Nepomuk stuff.

The only question is whether we can assume that all underlying stores support
this (i only know sesame does, i would be surprised if jena didn't) and whether
is puts too much pressure on people writing new adapters?

Maybe we could provide a default implementation that does not actually prepare
the query, but just does string manipulation of the SPARQL string? (this needs a
complete SPARQL parser though)

What do you think?

- - Gunnar
- --
Gunnar Aastrand Grimnes
gunnar.grimnes [AT] dfki.de

DFKI GmbH
Knowledge Management
Trippstadter Strasse 122
D-67663 Kaiserslautern
Germany

Office: +49 631 205 75-117
Mobile: +49 177 277 4397


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHDJAPfD15aMgAOfcRAqvdAJ96dLZUk8ivZQwPCxSBXJdFO8uHZgCgt3xs
AR/8IT8EXHTtrbHkbHIrpQw=
=YmbG
-----END PGP SIGNATURE-----


From sintek at dfki.uni-kl.de  Tue Oct  9 23:24:39 2007
From: sintek at dfki.uni-kl.de (Michael Sintek)
Date: Tue, 09 Oct 2007 23:24:39 +0200
Subject: [Rdf2go-devel] Reification
In-Reply-To: <E53E543D-738B-4662-B1BC-4A604A43E1FA@rauschma.de>
References: <4966AE6E-9554-46B8-B564-62340A3A731E@rauschma.de>	<1223200451.20071009201301@fzi.de>
	<E53E543D-738B-4662-B1BC-4A604A43E1FA@rauschma.de>
Message-ID: <470BF197.3060505@dfki.uni-kl.de>



Axel Rauschmayer wrote:
>>   void reify( Resource reifiedStmt, Statement stmt);
>>   void reify( Resource reifiedStmt, Resource s, URI p, Node o);
>>
>> So  the user has control what kind of Resource is used for the  
>> statement (URI or
>> bnode). The method should *not* add (s,p,o) to the model.
> 
> Yes, that makes a lot of sense. Not sure variant 2 is really needed,  
> because one can usually assume that the statement exists in RDF (same  
> for find/hasReifications).

I don't fully understand this remark. Do you want to say that
reified statements can be assumed to be in the normal RDF model?
This would be a wrong assumption -- one of the many usages for
reification is to have statements only reified and not directly
in the RDF model, because the latter implies that a statement
*holds* (is true), while a reified statement does not imply this.
In this way I can express "I don't believe in some statement",
e.g., <I don't_believe_in <John loves Mary>>; in this case,
the statement <John loves Mary> is not in my RDF model (and should not be
since I want to express that this statement is not true at all).

Michael


> 
> AR
> 
> --
> Axel Rauschmayer
> http://www.pst.ifi.lmu.de/~rauschma/
> 
> 
> 
> 
> _______________________________________________
> Rdf2go-devel mailing list
> Rdf2go-devel at ontoware.org
> http://ontoware.org/mailman/listinfo/rdf2go-devel

-- 
Michael Sintek -- DFKI GmbH, Kaiserslautern
http://www.michael-sintek.de -- michael.sintek at dfki.de
phone: +49 631 20575-130 -- fax: +49 631 20575-103
legal information: http://www.dfki.uni-kl.de/km/legal.html


From leo.sauermann at dfki.de  Wed Oct 10 13:27:51 2007
From: leo.sauermann at dfki.de (Leo Sauermann)
Date: Wed, 10 Oct 2007 13:27:51 +0200
Subject: [Rdf2go-devel] Reification
In-Reply-To: <7289B1F4-80B0-4C91-9D68-A7AA5D489631@rauschma.de>
References: <4966AE6E-9554-46B8-B564-62340A3A731E@rauschma.de>
	<1223200451.20071009201301@fzi.de> <470BC9C1.4080907@dfki.de>
	<1892548284.20071009204417@fzi.de> <470BCFF7.4010908@dfki.de>
	<7289B1F4-80B0-4C91-9D68-A7AA5D489631@rauschma.de>
Message-ID: <470CB737.5020304@dfki.de>

It was Axel Rauschmayer who said at the right time 10.10.2007 00:30 the 
following words:
>>> And we can refine to
>>>   BlankNode createReifiedStatement(Statement s)
>>>
>> whoah! now you really go for precision :-)
>> +1
>
> Sorry for being in high nit-pick-mode, but:
> - I've grown to dislike blank nodes (mainly because I have been 
> thinking about synchronization a lot). Couldn't there be use cases 
> where an implementation wants the default reified statement to be an 
> (automatically created) URI node? Maybe the return value should stay a 
> Resource.
this is not possible.
You cannot auto-create URIs. URIs contain a protocol part, and that has 
to be authorized and retrievalbe.
If you need this, call the createReifiedStatement(Resource, Statement) 
method, and create the URI beforehand.

>
>> Resource createReifiedStatement(Resource resource, Statement s)
>
> - With generics one could do:
> <R extends Resource> R createReifiedStatement(R resource, Statement s)
yep, but thats too witty I think.
with subclasses and interfaces you can do:
Resource createReifiedStatement(Resource resource, Statement s)

blanknode and uri are subclasses of resource, should be fine.
>
> Greetings,
>
> Axel
>
> -- 
> Axel Rauschmayer
> http://www.pst.ifi.lmu.de/~rauschma/
>
>
>


-- 
____________________________________________________
DI Leo Sauermann       http://www.dfki.de/~sauermann 

Deutsches Forschungszentrum fuer 
Kuenstliche Intelligenz DFKI GmbH
Trippstadter Strasse 122
P.O. Box 2080           Fon:   +49 631 20575-116
D-67663 Kaiserslautern  Fax:   +49 631 20575-102
Germany                 Mail:  leo.sauermann at dfki.de

Geschaeftsfuehrung:
Prof.Dr.Dr.h.c.mult. Wolfgang Wahlster (Vorsitzender)
Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats:
Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
____________________________________________________



From axel at rauschma.de  Wed Oct 10 13:50:16 2007
From: axel at rauschma.de (Axel Rauschmayer)
Date: Wed, 10 Oct 2007 13:50:16 +0200
Subject: [Rdf2go-devel] Reification
In-Reply-To: <470CB737.5020304@dfki.de>
References: <4966AE6E-9554-46B8-B564-62340A3A731E@rauschma.de>
	<1223200451.20071009201301@fzi.de> <470BC9C1.4080907@dfki.de>
	<1892548284.20071009204417@fzi.de> <470BCFF7.4010908@dfki.de>
	<7289B1F4-80B0-4C91-9D68-A7AA5D489631@rauschma.de>
	<470CB737.5020304@dfki.de>
Message-ID: <895FA862-B701-493D-A98B-B02387708CE0@rauschma.de>

>> Sorry for being in high nit-pick-mode, but:
>> - I've grown to dislike blank nodes (mainly because I have been  
>> thinking about synchronization a lot). Couldn't there be use cases  
>> where an implementation wants the default reified statement to be  
>> an (automatically created) URI node? Maybe the return value should  
>> stay a Resource.
> this is not possible.
> You cannot auto-create URIs. URIs contain a protocol part, and that  
> has to be authorized and retrievalbe.

I am doing it, because it is a practical solutions to some problems I  
have, even though it may not be 100% "proper".

> If you need this, call the createReifiedStatement(Resource,  
> Statement) method, and create the URI beforehand.

Yes, I can easily live with that solution.

>>> Resource createReifiedStatement(Resource resource, Statement s)
>>
>> - With generics one could do:
>> <R extends Resource> R createReifiedStatement(R resource,  
>> Statement s)
> yep, but thats too witty I think.
> with subclasses and interfaces you can do:
> Resource createReifiedStatement(Resource resource, Statement s)
>
> blanknode and uri are subclasses of resource, should be fine.

I agree that this might be too clever for its own sake, but the main  
point is not about extenders of this interface, but instead about  
clients (callers) of this interface: If you invoke this method, the  
return type will be the same as the type of the argument you handed in.

Greetings,

Axel

--
Axel Rauschmayer
http://www.pst.ifi.lmu.de/~rauschma/





From arjohn.kampman at aduna-software.com  Wed Oct 10 14:03:33 2007
From: arjohn.kampman at aduna-software.com (Arjohn Kampman)
Date: Wed, 10 Oct 2007 14:03:33 +0200
Subject: [Rdf2go-devel] RDF2Go Feedback
In-Reply-To: <6DF300E3-1A18-41A4-B30E-90571B08E71C@rauschma.de>
References: <94562A73-BF17-478C-AD47-9BA0A43E46CA@rauschma.de>	<470B676D.3040905@dfki.de>
	<6DF300E3-1A18-41A4-B30E-90571B08E71C@rauschma.de>
Message-ID: <470CBF95.4010903@aduna-software.com>

Axel Rauschmayer wrote:
>>> * *Returning* C<? extends T> is usually discouraged, see the  
>>> generics  tutorial (for arguments though, it is the way to go).  
>>> Better: C<T>.
>>>
>> haha, music in my ears, I always thought that returning a generics  
>> like this was wrong,
>> thanks for pointing it out.
>> could you give a link to the tutorial part you refer to?
> 
> I think it was in Bracha's generics tutorial (if you google, you can  
> find a PDF version of it, as well):
> http://java.sun.com/docs/books/tutorial/extra/generics/

Hi Axel,

Do you have a more precise pointer? I went through this tutorial again
but couldn't find anything that's related to this use of generics in
return types. As Sesame's APIs also use this consturction, I'm curious
about why this is considered to be bad practice.

-- 
Arjohn Kampman, Senior Software Engineer
Aduna - Guided Exploration
www.aduna-software.com


From michael.sintek at dfki.de  Wed Oct 10 15:27:02 2007
From: michael.sintek at dfki.de (Michael Sintek)
Date: Wed, 10 Oct 2007 15:27:02 +0200
Subject: [Rdf2go-devel] Reification
In-Reply-To: <E53E543D-738B-4662-B1BC-4A604A43E1FA@rauschma.de>
References: <4966AE6E-9554-46B8-B564-62340A3A731E@rauschma.de>	<1223200451.20071009201301@fzi.de>
	<E53E543D-738B-4662-B1BC-4A604A43E1FA@rauschma.de>
Message-ID: <470CD326.1030106@dfki.de>

(tying to send this email again to the mailing list;
it didn't work yesterday)

Axel Rauschmayer wrote:
>>   void reify( Resource reifiedStmt, Statement stmt);
>>   void reify( Resource reifiedStmt, Resource s, URI p, Node o);
>>
>> So  the user has control what kind of Resource is used for the  
>> statement (URI or
>> bnode). The method should *not* add (s,p,o) to the model.
> 
> Yes, that makes a lot of sense. Not sure variant 2 is really needed,  
> because one can usually assume that the statement exists in RDF (same  
> for find/hasReifications).

I don't fully understand this remark. Do you want to say that
reified statements can be assumed to be in the normal RDF model?
This would be a wrong assumption -- one of the many usages for
reification is to have statements only reified and not directly
in the RDF model, because the latter implies that a statement
*holds* (is true), while a reified statement does not imply this.
In this way I can express "I don't believe in some statement",
e.g., <I don't_believe_in <John loves Mary>>; in this case,
the statement <John loves Mary> is not in my RDF model (and should not be
since I want to express that this statement is not true at all).

Michael

> 
> AR
> 
> --
> Axel Rauschmayer
> http://www.pst.ifi.lmu.de/~rauschma/
> 
> 
> 
> 
> _______________________________________________
> Rdf2go-devel mailing list
> Rdf2go-devel at ontoware.org
> http://ontoware.org/mailman/listinfo/rdf2go-devel

-- 
Michael Sintek -- DFKI GmbH, Kaiserslautern
http://www.michael-sintek.de -- michael.sintek at dfki.de
phone: +49 631 20575-130 -- fax: +49 631 20575-103
legal information: http://www.dfki.uni-kl.de/km/legal.html


From axel at rauschma.de  Wed Oct 10 15:33:00 2007
From: axel at rauschma.de (Axel Rauschmayer)
Date: Wed, 10 Oct 2007 15:33:00 +0200
Subject: [Rdf2go-devel] Reification
In-Reply-To: <470CD326.1030106@dfki.de>
References: <4966AE6E-9554-46B8-B564-62340A3A731E@rauschma.de>	<1223200451.20071009201301@fzi.de>
	<E53E543D-738B-4662-B1BC-4A604A43E1FA@rauschma.de>
	<470CD326.1030106@dfki.de>
Message-ID: <973AFEBA-BD60-494D-8330-8C41A81A93B2@rauschma.de>

>> one can usually assume that the statement exists in RDF (same
>> for find/hasReifications).
>
> I don't fully understand this remark. Do you want to say that
> reified statements can be assumed to be in the normal RDF model?
> This would be a wrong assumption -- one of the many usages for
> reification is to have statements only reified and not directly
> in the RDF model, because the latter implies that a statement
> *holds* (is true), while a reified statement does not imply this.
> In this way I can express "I don't believe in some statement",
> e.g., <I don't_believe_in <John loves Mary>>; in this case,
> the statement <John loves Mary> is not in my RDF model (and should  
> not be
> since I want to express that this statement is not true at all).

Yes, this is absolutely correct, I tend to forget the knowledge  
representation perspective when it comes to RDF and see reification  
more as post-it notes that one attaches to _existing_ (valid)  
statements.

Greetings,

Axel

--
Axel Rauschmayer
http://www.pst.ifi.lmu.de/~rauschma/





From axel at rauschma.de  Wed Oct 10 16:31:50 2007
From: axel at rauschma.de (Axel Rauschmayer)
Date: Wed, 10 Oct 2007 16:31:50 +0200
Subject: [Rdf2go-devel] RDF2Go Feedback
In-Reply-To: <470CBF95.4010903@aduna-software.com>
References: <94562A73-BF17-478C-AD47-9BA0A43E46CA@rauschma.de>	<470B676D.3040905@dfki.de>
	<6DF300E3-1A18-41A4-B30E-90571B08E71C@rauschma.de>
	<470CBF95.4010903@aduna-software.com>
Message-ID: <D6000CDC-5277-4063-B42A-15BDD0C2CA6B@rauschma.de>

> Do you have a more precise pointer? I went through this tutorial again
> but couldn't find anything that's related to this use of generics in
> return types. As Sesame's APIs also use this consturction, I'm curious
> about why this is considered to be bad practice.

After further research, I've found out that I had this insight from a  
different source, namely:
http://angelikalanger.com/GenericsFAQ/FAQSections/ 
ProgrammingIdioms.html#Should%20I%20use%20wildcards%20in%20the% 
20return%20type%20of%20a%20method?

Greetings,

Axel

--
Axel Rauschmayer
http://www.pst.ifi.lmu.de/~rauschma/





From voelkel at fzi.de  Wed Oct 10 16:48:16 2007
From: voelkel at fzi.de (=?iso-8859-15?Q?Max_V=F6lkel?=)
Date: Wed, 10 Oct 2007 16:48:16 +0200
Subject: [Rdf2go-devel] issues via JIRA, please
Message-ID: <110932040.20071010164816@fzi.de>

Hi rdf2go-devel,

  long  emails  with over ten different suggestions and ideas are very valuable,
  but hard to keep track of. In order not to miss ideas and matching comments in
  other emails, I had to move issues to a real issue tracker.

  You can browse and add new issues here:
  http://octopus13.fzi.de:8080/browse/RTGO

  Everybody  *should*  be able to get an account. I added leo and axel and added
  them as watchers to issues where they contributed.

  You will also find the issue-URLs in the changelogs of future rdf2go releases,
  you you clearly know what happens.

  e.g.
  http://semweb4j.org/site/rdf2go.api/changes-report.html
  (oops, links shown on page are buggy, fix underway)

Kind Regards,
Max
--
       Max V?lkel
       voelkel at fzi.de | www.Xam.de
       office     +49 721 96 54-854
       mobile     +49 171 83 59 678
--
FZI Forschungszentrum Informatik an der Universit?t Karlsruhe
Haid-und-Neu-Str. 10-14, D-76131 Karlsruhe
Tel.: +49-721-9654-0, Fax: +49-721-9654-959
Stiftung des b?rgerlichen Rechts, Az: 14-0563.1 Regierungspr?sidium Karlsruhe.
Vorstand: Prof. Dr.-Ing. R?diger Dillmann, Dipl. Wi.-Ing. Michael Flor
Prof. Dr. Dr.-Ing. Jivka Ovtcharova, Prof. Dr. rer. nat. Rudi Studer
Vorsitzender des Kuratoriums: Ministerialdirigent G?nther Le?nerkraus



From leo.sauermann at dfki.de  Wed Oct 10 18:26:29 2007
From: leo.sauermann at dfki.de (Leo Sauermann)
Date: Wed, 10 Oct 2007 18:26:29 +0200
Subject: [Rdf2go-devel] issues via JIRA, please
In-Reply-To: <110932040.20071010164816@fzi.de>
References: <110932040.20071010164816@fzi.de>
Message-ID: <470CFD35.3020803@dfki.de>

hey,

good work to move them to JIRA.

best
Leo


It was Max V?lkel who said at the right time 10.10.2007 16:48 the 
following words:
> Hi rdf2go-devel,
>
>   long  emails  with over ten different suggestions and ideas are very valuable,
>   but hard to keep track of. In order not to miss ideas and matching comments in
>   other emails, I had to move issues to a real issue tracker.
>
>   You can browse and add new issues here:
>   http://octopus13.fzi.de:8080/browse/RTGO
>
>   Everybody  *should*  be able to get an account. I added leo and axel and added
>   them as watchers to issues where they contributed.
>
>   You will also find the issue-URLs in the changelogs of future rdf2go releases,
>   you you clearly know what happens.
>
>   e.g.
>   http://semweb4j.org/site/rdf2go.api/changes-report.html
>   (oops, links shown on page are buggy, fix underway)
>
> Kind Regards,
> Max
> --
>        Max V?lkel
>        voelkel at fzi.de | www.Xam.de
>        office     +49 721 96 54-854
>        mobile     +49 171 83 59 678
> --
> FZI Forschungszentrum Informatik an der Universit?t Karlsruhe
> Haid-und-Neu-Str. 10-14, D-76131 Karlsruhe
> Tel.: +49-721-9654-0, Fax: +49-721-9654-959
> Stiftung des b?rgerlichen Rechts, Az: 14-0563.1 Regierungspr?sidium Karlsruhe.
> Vorstand: Prof. Dr.-Ing. R?diger Dillmann, Dipl. Wi.-Ing. Michael Flor
> Prof. Dr. Dr.-Ing. Jivka Ovtcharova, Prof. Dr. rer. nat. Rudi Studer
> Vorsitzender des Kuratoriums: Ministerialdirigent G?nther Le?nerkraus
>
>
> _______________________________________________
> Rdf2go-devel mailing list
> Rdf2go-devel at ontoware.org
> http://ontoware.org/mailman/listinfo/rdf2go-devel
>
>   


-- 
____________________________________________________
DI Leo Sauermann       http://www.dfki.de/~sauermann 

Deutsches Forschungszentrum fuer 
Kuenstliche Intelligenz DFKI GmbH
Trippstadter Strasse 122
P.O. Box 2080           Fon:   +49 631 20575-116
D-67663 Kaiserslautern  Fax:   +49 631 20575-102
Germany                 Mail:  leo.sauermann at dfki.de

Geschaeftsfuehrung:
Prof.Dr.Dr.h.c.mult. Wolfgang Wahlster (Vorsitzender)
Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats:
Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
____________________________________________________



From arjohn.kampman at aduna-software.com  Wed Oct 10 21:42:32 2007
From: arjohn.kampman at aduna-software.com (Arjohn Kampman)
Date: Wed, 10 Oct 2007 21:42:32 +0200
Subject: [Rdf2go-devel] RDF2Go Feedback
In-Reply-To: <D6000CDC-5277-4063-B42A-15BDD0C2CA6B@rauschma.de>
References: <94562A73-BF17-478C-AD47-9BA0A43E46CA@rauschma.de>	<470B676D.3040905@dfki.de>
	<6DF300E3-1A18-41A4-B30E-90571B08E71C@rauschma.de>
	<470CBF95.4010903@aduna-software.com>
	<D6000CDC-5277-4063-B42A-15BDD0C2CA6B@rauschma.de>
Message-ID: <470D2B28.3050705@aduna-software.com>

Axel Rauschmayer wrote:
>> Do you have a more precise pointer? I went through this tutorial again
>> but couldn't find anything that's related to this use of generics in
>> return types. As Sesame's APIs also use this consturction, I'm curious
>> about why this is considered to be bad practice.
> 
> After further research, I've found out that I had this insight from a 
> different source, namely:
> http://angelikalanger.com/GenericsFAQ/FAQSections/ProgrammingIdioms.html#Should%20I%20use%20wildcards%20in%20the%20return%20type%20of%20a%20method? 

Thanks for the link. The arguments don't sound very convincing though.
The author bypasses the fact that wildcards can be very useful in that
it allows subclasses to return more specific return types. His point
that, for example, you can't modify collections with wildcard types are
true; but then again, in most cases I don't want other classes to
directly modify lists that are returned by a class.

I guess what it comes down to is that you need to evaluate every case
individually and decide whether or not to return wildcard types. Just
saying "Avoid it, if you can." sounds a bit too simple to me.

All of the above "IMHO", of course.

--
Arjohn


From voelkel at fzi.de  Wed Oct 10 21:53:35 2007
From: voelkel at fzi.de (=?iso-8859-15?Q?Max_V=F6lkel?=)
Date: Wed, 10 Oct 2007 21:53:35 +0200
Subject: [Rdf2go-devel] Feature request: prepare queries
In-Reply-To: <470C900F.7000008@dfki.de>
References: <470C900F.7000008@dfki.de>
Message-ID: <184239169.20071010215335@fzi.de>

GAG> Would it be possible to somehow add prepared queries to rdf2go?

Moved to http://octopus13.fzi.de:8080/browse/RTGO-29

Kind Regards,
Max
--
       Max V?lkel
       voelkel at fzi.de | www.Xam.de
       office     +49 721 96 54-854
       mobile     +49 171 83 59 678
--
FZI Forschungszentrum Informatik an der Universit?t Karlsruhe
Haid-und-Neu-Str. 10-14, D-76131 Karlsruhe
Tel.: +49-721-9654-0, Fax: +49-721-9654-959
Stiftung des b?rgerlichen Rechts, Az: 14-0563.1 Regierungspr?sidium Karlsruhe.
Vorstand: Prof. Dr.-Ing. R?diger Dillmann, Dipl. Wi.-Ing. Michael Flor
Prof. Dr. Dr.-Ing. Jivka Ovtcharova, Prof. Dr. rer. nat. Rudi Studer
Vorsitzender des Kuratoriums: Ministerialdirigent G?nther Le?nerkraus



From axel at rauschma.de  Sat Oct 13 14:32:43 2007
From: axel at rauschma.de (Axel Rauschmayer)
Date: Sat, 13 Oct 2007 14:32:43 +0200
Subject: [Rdf2go-devel] Underlying resource?
Message-ID: <805E1EC5-86F6-4F17-8D23-F8074F5B32F0@rauschma.de>

Hi!

I've seen that the BlankNodeImpl contains a field "underlyingBlankNode".

- Wouldn't it make sense to push this up to ResourceImpl, maybe even  
to the Node level? I've read that Sesame keeps IDs in their resource  
objects to considerably speed up repository access.
- If that is true, then it would be nice if the underlying node were  
publically accessible (similar to what you are doing with ModelSet).

Axel

--
Axel Rauschmayer
http://www.pst.ifi.lmu.de/~rauschma/





From christiaan.fluit at aduna-software.com  Mon Oct 15 11:33:34 2007
From: christiaan.fluit at aduna-software.com (Christiaan Fluit)
Date: Mon, 15 Oct 2007 11:33:34 +0200
Subject: [Rdf2go-devel] RDF2Go driver for Sesame 2.0 beta 6
Message-ID: <471333EE.3070204@aduna-software.com>

Hello all,

The Sesame users on this list are probably already aware that last 
Friday we released Sesame 2.0 beta 6. I have just created a release of 
the RDF2Go driver compatible with this Sesame release.

Binaries can be found in our Maven repository:

http://repository.aduna-software.org/maven2/org/openrdf/openrdf-rdf2go/2.0-beta6/

The source of this release is available here:

https://src.aduna-software.org/svn/org.openrdf/releases/sesame2-contrib/2.0-beta6/openrdf-rdf2go/

The trunk source is available at:

https://src.aduna-software.org/svn/org.openrdf/projects/sesame2-contrib/openrdf-ext-contrib/openrdf-rdf2go/

Max: you can now safely start editing the trunk.



Kind regards,

Chris
--



From Axel.Rauschmayer at ifi.lmu.de  Mon Oct 15 11:47:15 2007
From: Axel.Rauschmayer at ifi.lmu.de (Axel Rauschmayer)
Date: Mon, 15 Oct 2007 11:47:15 +0200
Subject: [Rdf2go-devel] RDF2Go driver for Sesame 2.0 beta 6
In-Reply-To: <471333EE.3070204@aduna-software.com>
References: <471333EE.3070204@aduna-software.com>
Message-ID: <47133723.3000804@ifi.lmu.de>

Christiaan Fluit wrote:
> Hello all,
>
> The Sesame users on this list are probably already aware that last 
> Friday we released Sesame 2.0 beta 6. I have just created a release of 
> the RDF2Go driver compatible with this Sesame release.
>   
That's great news!

Small detail: Shouldn't the files contain both versions (of Sesame and 
RDF2Go)? For example: openrdf-2.0b6_rdf2go-4.4.9.jar

Greetings,

Axel

-- 
Axel.Rauschmayer at ifi.lmu.de
http://www.pst.ifi.lmu.de/~rauschma/




From axel at rauschma.de  Tue Oct 16 00:49:03 2007
From: axel at rauschma.de (Axel Rauschmayer)
Date: Tue, 16 Oct 2007 00:49:03 +0200
Subject: [Rdf2go-devel] Ordered query variables
Message-ID: <1A907BA2-2821-4E81-AAD8-2362AF384BDF@rauschma.de>

I'm sorry to bring this up again [I've not yet seen a JIRA issue for  
this], but after the currently planned changes to RDF2Go, it is the  
only thing where I have to perform hacks to get around the standard API:

> I think QueryResultTable.getVariables() should return a list (or  
> alternatively, there should be a method getOrderedVariables()).

Otherwise, you cannot properly print out the result in answer to a  
SPARQL query the user enters; usually the order in which (s)he  
enumerates the variables in the SELECT clause *does* matter (SELECT ? 
subj ?pred ?obj ...).

If I'm the only one, I'll live with my hack, but I think this change  
makes general sense.

Greetings,

Axel

--
Axel Rauschmayer
http://www.pst.ifi.lmu.de/~rauschma/





From voelkel at fzi.de  Tue Oct 16 10:02:15 2007
From: voelkel at fzi.de (=?iso-8859-15?Q?Max_V=F6lkel?=)
Date: Tue, 16 Oct 2007 10:02:15 +0200
Subject: [Rdf2go-devel] Ordered query variables
In-Reply-To: <1A907BA2-2821-4E81-AAD8-2362AF384BDF@rauschma.de>
References: <1A907BA2-2821-4E81-AAD8-2362AF384BDF@rauschma.de>
Message-ID: <1447236581.20071016100215@fzi.de>

Hi Axel,

AR> I'm sorry to bring this up again [I've not yet seen a JIRA issue for
AR> this], but after the currently planned changes to RDF2Go, it is the  
AR> only thing where I have to perform hacks to get around the standard API:
You can also create issues ;-)
So I did this: http://octopus13.fzi.de:8080/browse/RTGO-32

I comment on the issue there...

Kind Regards,
Max
--
       Max V?lkel
       voelkel at fzi.de | www.Xam.de
       office     +49 721 96 54-854
       mobile     +49 171 83 59 678
--
FZI Forschungszentrum Informatik an der Universit?t Karlsruhe
Haid-und-Neu-Str. 10-14, D-76131 Karlsruhe
Tel.: +49-721-9654-0, Fax: +49-721-9654-959
Stiftung des b?rgerlichen Rechts, Az: 14-0563.1 Regierungspr?sidium Karlsruhe.
Vorstand: Prof. Dr.-Ing. R?diger Dillmann, Dipl. Wi.-Ing. Michael Flor
Prof. Dr. Dr.-Ing. Jivka Ovtcharova, Prof. Dr. rer. nat. Rudi Studer
Vorsitzender des Kuratoriums: Ministerialdirigent G?nther Le?nerkraus



From voelkel at fzi.de  Wed Oct 17 10:53:34 2007
From: voelkel at fzi.de (=?iso-8859-15?Q?Max_V=F6lkel?=)
Date: Wed, 17 Oct 2007 10:53:34 +0200
Subject: [Rdf2go-devel] RDF2Go 4.5.0-SNAPSHOT available
Message-ID: <267165545.20071017105334@fzi.de>

Hi,


1)
  You can try out the new, slightly changed RDF2GO API.

  RDF2GO 4.5.0 API + Jena 2.4 adapter
    http://semweb4j.org/snapshots/org/semweb4j/rdf2go.dist/4.5.0-SNAPSHOT/rdf2go.dist-4.5.0-20071016.094010-1.zip

  OpenRDF adapter for Sesame 2.0 beta 6 and RDF2GO 4.5.0
    http://semweb4j.org/snapshots/org/openrdf/openrdf-rdf2go/4.5.0-SNAPSHOT/openrdf-rdf2go-4.5.0-20071016.100544-1.jar

  Changes:

        BlankNodeImpl became AbstractBlankNode. Interface BlankNode now has
        String getInternalID(). Fixes RTGO-28. xamde

        Variable no longer extends Node. This was a bug, thanks for spotting it
        Axel! xamde
        
        Changed all occurences of < ? extens Statement > to < Statement > , same
        for Model. Fixes RTGO-25. xamde

        Added Syntax.getFilenameExtension() Fixes RTGO-26. xamde

        Changed QueryResultTable.getVariables() return type to List < String >
        (was Set < String > ) Fixes RTGO-32. xamde

   http://semweb4j.org/site/rdf2go.api/changes-report.html


   Please   play  around  with  it  and  report  if  the  API  changes  break  a
   lot/or anything.

2)

   I  need  some help with testing. It's great to receive all the discussion and
   feature  request  from  you,  but  its hard to implement (and test) them all.
   Currently,  all  tests  run,  but we need more of them. Currently ~ 20-30% of
   methods might be untested.

   How to help?

   The  simplest  way (without knowing e.g. maven) is to download the jars, look
   at the existing test code
   http://semweb4j.googlecode.com/svn/trunk/org.semweb4j.rdf2go.impl.base.test/src/main/java/org/ontoware/rdf2go/model/AbstractModelSetTest.java
   http://semweb4j.googlecode.com/svn/trunk/org.semweb4j.rdf2go.impl.base.test/src/main/java/org/ontoware/rdf2go/model/AbstractModelTest.java
   and   write   tests  for  things  that are not tested yet. Simply write JUnit
   tests from scratch and email them to me, its easy to integrate them then.
   
Kind Regards,
Max
--
       Max V?lkel
       voelkel at fzi.de | www.Xam.de
       office     +49 721 96 54-854
       mobile     +49 171 83 59 678
--
FZI Forschungszentrum Informatik an der Universit?t Karlsruhe
Haid-und-Neu-Str. 10-14, D-76131 Karlsruhe
Tel.: +49-721-9654-0, Fax: +49-721-9654-959
Stiftung des b?rgerlichen Rechts, Az: 14-0563.1 Regierungspr?sidium Karlsruhe.
Vorstand: Prof. Dr.-Ing. R?diger Dillmann, Dipl. Wi.-Ing. Michael Flor
Prof. Dr. Dr.-Ing. Jivka Ovtcharova, Prof. Dr. rer. nat. Rudi Studer
Vorsitzender des Kuratoriums: Ministerialdirigent G?nther Le?nerkraus