[ 
https://issues.apache.org/jira/browse/JENA-1687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16798838#comment-16798838
 ] 

Jan Martin Keil edited comment on JENA-1687 at 3/22/19 9:01 AM:
----------------------------------------------------------------

Hi. The use case in mind is to
 # get URI nodes NodeFactory::createURI using (or Graph::find and 
Triple::getSubject / Triple::getObject in case of JENA-1688)
 # process this URI nodes in different ways (nothing what could be done with a 
SPARQL CONSTRUCT query)
 # generate new triples and graphs using some of the processed URI nodes

The idea was to use Java type safety to enforce integrity during the process. 
Of course, there are other ways to ensure that. And I appreciate that you do 
not want change this.


was (Author: jmkeil):
Hi. The use case in mind is to
 # get URI nodes using Graph::find and Triple::getSubject / Triple::getObject 
(or NodeFactory::createURI in case of JENA-1688)
 # process this URI nodes in different ways (nothing what could be done with a 
SPARQL CONSTRUCT query)
 # generate new triples and graphs using some of the processed URI nodes

The idea was to use Java type safety to enforce integrity during the process. 
Of course, there are other ways to ensure that. And I appreciate that you do 
not want change this.

> Precise return types of NodeFactory methods
> -------------------------------------------
>
>                 Key: JENA-1687
>                 URL: https://issues.apache.org/jira/browse/JENA-1687
>             Project: Apache Jena
>          Issue Type: Improvement
>            Reporter: Jan Martin Keil
>            Priority: Major
>          Time Spent: 10m
>  Remaining Estimate: 0h
>
> I propose to precise the return types of the NodeFactory methods, e.g. to set 
> NodeFactory#createURI return type to Node_URI. This makes the developers life 
> easier, as there is no longer a need to cast after creating a Node, if one 
> need a specific node type. I can not see any disadvantages and it should be 
> backward compatible (except of classes that override these methods).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to