[jira] [Updated] (JENA-1083) Minor refactoring in TupleTables
[ https://issues.apache.org/jira/browse/JENA-1083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Seaborne updated JENA-1083: Assignee: A. Soroka (was: Andy Seaborne) > Minor refactoring in TupleTables > > > Key: JENA-1083 > URL: https://issues.apache.org/jira/browse/JENA-1083 > Project: Apache Jena > Issue Type: Improvement > Components: ARQ >Reporter: A. Soroka >Assignee: A. Soroka >Priority: Minor > Fix For: Jena 3.1.0 > > > There are some minor refactorings available for TupleTable and its subtypes, > particularly PMapTripleTable and PMapQuadTable that will clarify their use. > Specifically, current impls of those abstract types have to override several > methods for adding, removing, and finding tuples. In fact, the only > information being added when those methods are overridden is conversion > between canonical and internal tuple ordering. This refactoring is to provide > methods that do that conversion and nothing else, which will make two methods > the most that any implementation of those abstract classes will have to > provide. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] jena pull request: JENA-1083: Factoring tuple ordering into TupleM...
Github user ajs6f commented on the pull request: https://github.com/apache/jena/pull/120#issuecomment-177313470 Sorry on both counts. `SimpleMap*` is leakage from JENA-1084. My Git-fu failed. I thought I had kept that work separate. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Resolved] (JENA-1083) Minor refactoring in TupleTables
[ https://issues.apache.org/jira/browse/JENA-1083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Seaborne resolved JENA-1083. - Resolution: Done Fix Version/s: Jena 3.1.0 > Minor refactoring in TupleTables > > > Key: JENA-1083 > URL: https://issues.apache.org/jira/browse/JENA-1083 > Project: Apache Jena > Issue Type: Improvement > Components: ARQ >Reporter: A. Soroka >Assignee: A. Soroka >Priority: Minor > Fix For: Jena 3.1.0 > > > There are some minor refactorings available for TupleTable and its subtypes, > particularly PMapTripleTable and PMapQuadTable that will clarify their use. > Specifically, current impls of those abstract types have to override several > methods for adding, removing, and finding tuples. In fact, the only > information being added when those methods are overridden is conversion > between canonical and internal tuple ordering. This refactoring is to provide > methods that do that conversion and nothing else, which will make two methods > the most that any implementation of those abstract classes will have to > provide. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JENA-1083) Minor refactoring in TupleTables
[ https://issues.apache.org/jira/browse/JENA-1083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15125093#comment-15125093 ] ASF GitHub Bot commented on JENA-1083: -- Github user ajs6f commented on the pull request: https://github.com/apache/jena/pull/120#issuecomment-177313470 Sorry on both counts. `SimpleMap*` is leakage from JENA-1084. My Git-fu failed. I thought I had kept that work separate. > Minor refactoring in TupleTables > > > Key: JENA-1083 > URL: https://issues.apache.org/jira/browse/JENA-1083 > Project: Apache Jena > Issue Type: Improvement > Components: ARQ >Reporter: A. Soroka >Assignee: A. Soroka >Priority: Minor > Fix For: Jena 3.1.0 > > > There are some minor refactorings available for TupleTable and its subtypes, > particularly PMapTripleTable and PMapQuadTable that will clarify their use. > Specifically, current impls of those abstract types have to override several > methods for adding, removing, and finding tuples. In fact, the only > information being added when those methods are overridden is conversion > between canonical and internal tuple ordering. This refactoring is to provide > methods that do that conversion and nothing else, which will make two methods > the most that any implementation of those abstract classes will have to > provide. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JENA-1083) MInor refactoring in TupleTables
[ https://issues.apache.org/jira/browse/JENA-1083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15125092#comment-15125092 ] ASF GitHub Bot commented on JENA-1083: -- Github user afs commented on the pull request: https://github.com/apache/jena/pull/120#issuecomment-177312482 Merged after fixing up: 1/ I used "git pull --no-commit" and got some compile errors (imports of `TriOperator.Operator3` etc) in files `SimpleMap*`. These classes are unused so I deleted them before commiting. 2/ There were no licnese headers on `TConsumer3` etc. Please run `mvn clean test -Pdev` before submitting a pull request. This will run the license checks (also know as the RAT). Failing to pass RAT causes the maven build to fail. > MInor refactoring in TupleTables > > > Key: JENA-1083 > URL: https://issues.apache.org/jira/browse/JENA-1083 > Project: Apache Jena > Issue Type: Improvement > Components: ARQ >Reporter: A. Soroka >Priority: Minor > > There are some minor refactorings available for TupleTable and its subtypes, > particularly PMapTripleTable and PMapQuadTable that will clarify their use. > Specifically, current impls of those abstract types have to override several > methods for adding, removing, and finding tuples. In fact, the only > information being added when those methods are overridden is conversion > between canonical and internal tuple ordering. This refactoring is to provide > methods that do that conversion and nothing else, which will make two methods > the most that any implementation of those abstract classes will have to > provide. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] jena pull request: JENA-1083: Factoring tuple ordering into TupleM...
Github user afs commented on the pull request: https://github.com/apache/jena/pull/120#issuecomment-177312482 Merged after fixing up: 1/ I used "git pull --no-commit" and got some compile errors (imports of `TriOperator.Operator3` etc) in files `SimpleMap*`. These classes are unused so I deleted them before commiting. 2/ There were no licnese headers on `TConsumer3` etc. Please run `mvn clean test -Pdev` before submitting a pull request. This will run the license checks (also know as the RAT). Failing to pass RAT causes the maven build to fail. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Updated] (JENA-1083) Minor refactoring in TupleTables
[ https://issues.apache.org/jira/browse/JENA-1083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Seaborne updated JENA-1083: Summary: Minor refactoring in TupleTables (was: MInor refactoring in TupleTables) > Minor refactoring in TupleTables > > > Key: JENA-1083 > URL: https://issues.apache.org/jira/browse/JENA-1083 > Project: Apache Jena > Issue Type: Improvement > Components: ARQ >Reporter: A. Soroka >Priority: Minor > > There are some minor refactorings available for TupleTable and its subtypes, > particularly PMapTripleTable and PMapQuadTable that will clarify their use. > Specifically, current impls of those abstract types have to override several > methods for adding, removing, and finding tuples. In fact, the only > information being added when those methods are overridden is conversion > between canonical and internal tuple ordering. This refactoring is to provide > methods that do that conversion and nothing else, which will make two methods > the most that any implementation of those abstract classes will have to > provide. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (JENA-1126) Make SAMPLE avoid undefs/errors if there are valid choices.
[
https://issues.apache.org/jira/browse/JENA-1126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy Seaborne resolved JENA-1126.
-
Resolution: Done
Assignee: Andy Seaborne
Fix Version/s: Jena 3.1.0
> Make SAMPLE avoid undefs/errors if there are valid choices.
> ---
>
> Key: JENA-1126
> URL: https://issues.apache.org/jira/browse/JENA-1126
> Project: Apache Jena
> Issue Type: Improvement
> Components: ARQ
>Reporter: Andy Seaborne
>Assignee: Andy Seaborne
>Priority: Minor
> Fix For: Jena 3.1.0
>
>
> From
> https://lists.w3.org/Archives/Public/public-sparql-dev/2016JanMar/0005.html
> {noformat}SAMPLE({1, 2, error}){noformat} is error currently (for any order).
> It tends to favour errors as that is checked before a sampling.
> It can be 1 or 2. All are right but returning a value if possible is more
> helpful.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JENA-1083) MInor refactoring in TupleTables
[ https://issues.apache.org/jira/browse/JENA-1083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15125090#comment-15125090 ] ASF subversion and git services commented on JENA-1083: --- Commit c538483e2a6011a0aeb1f92a4ff7894c4f2a2fb0 in jena's branch refs/heads/master from [~andy.seaborne] [ https://git-wip-us.apache.org/repos/asf?p=jena.git;h=c538483 ] JENA-1083: Factoring tuple ordering into TupleMap Merge commit 'refs/pull/120/head' of github.com:apache/jena This closes #120. > MInor refactoring in TupleTables > > > Key: JENA-1083 > URL: https://issues.apache.org/jira/browse/JENA-1083 > Project: Apache Jena > Issue Type: Improvement > Components: ARQ >Reporter: A. Soroka >Priority: Minor > > There are some minor refactorings available for TupleTable and its subtypes, > particularly PMapTripleTable and PMapQuadTable that will clarify their use. > Specifically, current impls of those abstract types have to override several > methods for adding, removing, and finding tuples. In fact, the only > information being added when those methods are overridden is conversion > between canonical and internal tuple ordering. This refactoring is to provide > methods that do that conversion and nothing else, which will make two methods > the most that any implementation of those abstract classes will have to > provide. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] jena pull request: JENA-1083: Factoring tuple ordering into TupleM...
Github user asfgit closed the pull request at: https://github.com/apache/jena/pull/120 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (JENA-1083) MInor refactoring in TupleTables
[ https://issues.apache.org/jira/browse/JENA-1083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15125091#comment-15125091 ] ASF GitHub Bot commented on JENA-1083: -- Github user asfgit closed the pull request at: https://github.com/apache/jena/pull/120 > MInor refactoring in TupleTables > > > Key: JENA-1083 > URL: https://issues.apache.org/jira/browse/JENA-1083 > Project: Apache Jena > Issue Type: Improvement > Components: ARQ >Reporter: A. Soroka >Priority: Minor > > There are some minor refactorings available for TupleTable and its subtypes, > particularly PMapTripleTable and PMapQuadTable that will clarify their use. > Specifically, current impls of those abstract types have to override several > methods for adding, removing, and finding tuples. In fact, the only > information being added when those methods are overridden is conversion > between canonical and internal tuple ordering. This refactoring is to provide > methods that do that conversion and nothing else, which will make two methods > the most that any implementation of those abstract classes will have to > provide. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JENA-1104) LockObtainFailedException for text index
[
https://issues.apache.org/jira/browse/JENA-1104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15124968#comment-15124968
]
ASF GitHub Bot commented on JENA-1104:
--
Github user afs commented on the pull request:
https://github.com/apache/jena/pull/123#issuecomment-177243620
This PR protects against multiple creation of a text index (JENA-1104), not
against two calls to create the same dataset for two services in Fuseki. By
chance, TDB is less prone to problems if that happens but that is luck.
General datasets e.g. with inference graphs, SDB or plain in-memory datasets
are likely exposed to problems.
Let's solve the immediate issue described in JENA-1122, then see if
JENA-1104 needs addressing or whether the situations where it can still happen
are uninteresting or have other problems in which case the application must be
responsible for creating the index only once.
For the record, there are some specific items with the current PR that I
would like clarified or refuted before this code is used to address JENA-1107,
if that is still needed.
1: `TextIndexLucene.close` is not reference counted.
* Create text index -> T1
* Create text index -> T2 (which is T1, shared)
* Close T2.
* Any T1 code will now crash - the index is closed.
2: Using WeakReferences and managing `close()` seems to be duplicating
lifecycle management.
I am not clear that the WeakReference to the Lucene index helps because
there are no finalizers, so GC fnalization does not tidy up lucene. A freed
WeakReference would cause a new attempt to create the index but it will hit the
state lock.
3: Creation by `createLuceneIndex` is not thread safe. It has a
get-create-put timing hole.
4: Need to be clear on the contract for "same `Directory`, different Lucene
configuration (`TextIndexConfig`)".
> LockObtainFailedException for text index
>
>
> Key: JENA-1104
> URL: https://issues.apache.org/jira/browse/JENA-1104
> Project: Apache Jena
> Issue Type: Bug
> Components: Fuseki
>Affects Versions: Fuseki 2.3.1
> Environment: CentOS 5.11
> Java 1.8.0_45-b14
> Tomcat 7.0.62
>Reporter: Joachim Neubert
>
> When starting Fuseki2 under Tomcat, on Centos 5 I get an exception which I
> have not seen on Centos 7:
> {quote}
> SEVERE: Exception sending context initialized event to listener instance of
> class org.apache.jena.fuseki.server.FusekiServerListener
> org.apache.jena.assembler.exceptions.AssemblerException: caught:
> org.apache.lucene.store.LockObtainFailedException: Lock obtain timed out:
> NativeFSLock@/opt/thes/var/gn
> d/2015-10-13/tdb_lucene/write.lock:
> java.nio.channels.OverlappingFileLockException
> doing:
> root: file:///opt/fuseki2/run/configuration/gnd.ttl#gndIndex with type:
> http://jena.apache.org/text#TextIndexLucene assembler class: class
> org.apache.jena.query.tex
> t.assembler.TextIndexLuceneAssembler
> root: file:///opt/fuseki2/run/configuration/gnd.ttl#gnd with type:
> http://jena.apache.org/text#TextDataset assembler class: class
> org.apache.jena.query.text.assembl
> er.TextDatasetAssembler
> at
> org.apache.jena.assembler.assemblers.AssemblerGroup$PlainAssemblerGroup.openBySpecificType(AssemblerGroup.java:138)
> ...
> {quote}
> The very strange thing is that tomcat actually *has* created the write.lock
> file in that directory (which I had removed before).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] jena pull request: Add memoizing of LuceneTextIndexes so that ther...
Github user afs commented on the pull request: https://github.com/apache/jena/pull/123#issuecomment-177243620 This PR protects against multiple creation of a text index (JENA-1104), not against two calls to create the same dataset for two services in Fuseki. By chance, TDB is less prone to problems if that happens but that is luck. General datasets e.g. with inference graphs, SDB or plain in-memory datasets are likely exposed to problems. Let's solve the immediate issue described in JENA-1122, then see if JENA-1104 needs addressing or whether the situations where it can still happen are uninteresting or have other problems in which case the application must be responsible for creating the index only once. For the record, there are some specific items with the current PR that I would like clarified or refuted before this code is used to address JENA-1107, if that is still needed. 1: `TextIndexLucene.close` is not reference counted. * Create text index -> T1 * Create text index -> T2 (which is T1, shared) * Close T2. * Any T1 code will now crash - the index is closed. 2: Using WeakReferences and managing `close()` seems to be duplicating lifecycle management. I am not clear that the WeakReference to the Lucene index helps because there are no finalizers, so GC fnalization does not tidy up lucene. A freed WeakReference would cause a new attempt to create the index but it will hit the state lock. 3: Creation by `createLuceneIndex` is not thread safe. It has a get-create-put timing hole. 4: Need to be clear on the contract for "same `Directory`, different Lucene configuration (`TextIndexConfig`)". --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (JENA-1126) Make SAMPLE avoid undefs/errors if there are valid choices.
[
https://issues.apache.org/jira/browse/JENA-1126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15124984#comment-15124984
]
ASF subversion and git services commented on JENA-1126:
---
Commit a523a4066af5af5c6b1cc9d6504ba4d247f38df4 in jena's branch
refs/heads/master from [~andy.seaborne]
[ https://git-wip-us.apache.org/repos/asf?p=jena.git;h=a523a40 ]
JENA-1126: Clean up.
Introduce ExprLib.evalOrNull.
> Make SAMPLE avoid undefs/errors if there are valid choices.
> ---
>
> Key: JENA-1126
> URL: https://issues.apache.org/jira/browse/JENA-1126
> Project: Apache Jena
> Issue Type: Improvement
> Components: ARQ
>Reporter: Andy Seaborne
>Priority: Minor
>
> From
> https://lists.w3.org/Archives/Public/public-sparql-dev/2016JanMar/0005.html
> {noformat}SAMPLE({1, 2, error}){noformat} is error currently (for any order).
> It tends to favour errors as that is checked before a sampling.
> It can be 1 or 2. All are right but returning a value if possible is more
> helpful.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (JENA-1126) Make SAMPLE avoid undefs/errors if there are valid choices.
[
https://issues.apache.org/jira/browse/JENA-1126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15124952#comment-15124952
]
Andy Seaborne edited comment on JENA-1126 at 1/30/16 4:26 PM:
--
Commit 8a85da108fbab721ea190cac5ec7f87240363800 in jena's branch
refs/heads/master from [~andy.seaborne]
[ https://git-wip-us.apache.org/repos/asf?p=jena.git;h=8a85da1 ]
JENA-1126: Choose a defined value if possible in SAMPLE.
was (Author: jira-bot):
Commit 8a85da108fbab721ea190cac5ec7f87240363800 in jena's branch
refs/heads/master from [~andy.seaborne]
[ https://git-wip-us.apache.org/repos/asf?p=jena.git;h=8a85da1 ]
JENA-1126: Choese a defined value if possible in SAMPLE.
> Make SAMPLE avoid undefs/errors if there are valid choices.
> ---
>
> Key: JENA-1126
> URL: https://issues.apache.org/jira/browse/JENA-1126
> Project: Apache Jena
> Issue Type: Improvement
> Components: ARQ
>Reporter: Andy Seaborne
>Priority: Minor
>
> From
> https://lists.w3.org/Archives/Public/public-sparql-dev/2016JanMar/0005.html
> {noformat}SAMPLE({1, 2, error}){noformat} is error currently (for any order).
> It tends to favour errors as that is checked before a sampling.
> It can be 1 or 2. All are right but returning a value if possible is more
> helpful.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JENA-1126) Make SAMPLE avoid undefs/errors if there are valid choices.
[
https://issues.apache.org/jira/browse/JENA-1126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15124952#comment-15124952
]
ASF subversion and git services commented on JENA-1126:
---
Commit 8a85da108fbab721ea190cac5ec7f87240363800 in jena's branch
refs/heads/master from [~andy.seaborne]
[ https://git-wip-us.apache.org/repos/asf?p=jena.git;h=8a85da1 ]
JENA-1126: Choese a defined value if possible in SAMPLE.
> Make SAMPLE avoid undefs/errors if there are valid choices.
> ---
>
> Key: JENA-1126
> URL: https://issues.apache.org/jira/browse/JENA-1126
> Project: Apache Jena
> Issue Type: Improvement
> Components: ARQ
>Reporter: Andy Seaborne
>Priority: Minor
>
> From
> https://lists.w3.org/Archives/Public/public-sparql-dev/2016JanMar/0005.html
> {noformat}SAMPLE({1, 2, error}){noformat} is error currently (for any order).
> It tends to favour errors as that is checked before a sampling.
> It can be 1 or 2. All are right but returning a value if possible is more
> helpful.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JENA-1122) Fuseki fails to start if configured with two services that share the same dataset with a lucene index.
[ https://issues.apache.org/jira/browse/JENA-1122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15124975#comment-15124975 ] ASF GitHub Bot commented on JENA-1122: -- Github user afs commented on the pull request: https://github.com/apache/jena/pull/123#issuecomment-177246334 Starting from the JENA-1122 description: > Two Fuseki services, linking to the same dataset description. Fuseki only calls assemblers once. No other system is (legitimately) calling Fuseki service building. The configuration file processing puts service access points into the server-wide state. There is no service assembler (it could be done but it isn't, it serves no purpose); it is done by custom processing during walking the datastructure which is happening anyway. In the Fuseki case, we want shared datasets descriptions, that is, same name, to yield the same dataset. Processing dataset descriptions is driven by assemblers and they have names for keys using the root resource. A general "dataset sharing" outside assemblers is hard because of the lack of key. In other cases, I can imagine that a shared description alone does not always imply a shared object - in-memory datasets for example. The more general area is not clearly defined. The solution I see is that Fuseki handles the process step for the link: ``` fuseki:dataset <#dataset> <#dataset> rdf:type ja:RDFDataset(OrSubType) ``` This happens in `Builder.buildDataService` as it calls `Assembler.general.open(datasetDesc)`. It looks to me that if sharing is provided here, the problem statement of JENA-1122 is addressed. One matter arising: Service descriptions can be in multiple files (it is the preferred pattern to use `configuration/`). The template system behind the UI uses relative URIs so names of descriptions are unique across the server. If a user manually writes two configuration files, but uses the same absolute URI and they meant it to be different, we have a problem and this could be made to cause an error (safe choice to force shared datasets to be in the server `config.ttl`). `FusekiConfig.initializeDataAccessPoints` is the driver, it calls `readConfigurationDirectory` and the others places service descriptions can be and so needs checking. For now, just solving this for two services in the server configuration file, with entries in the `fuseki:services` list links is a good start. > Fuseki fails to start if configured with two services that share the same > dataset with a lucene index. > -- > > Key: JENA-1122 > URL: https://issues.apache.org/jira/browse/JENA-1122 > Project: Apache Jena > Issue Type: Bug > Components: Text >Affects Versions: Jena 3.0.0, Fuseki 2.3.0 >Reporter: Brian McBride > > This problem arises when the assemblers for the two services run. For each > service, a separate TextIndexLucene object is created. Both of those objects > try to lock the same Lucene index directory and one fails. > A proposed fix is to modify the TextDatasetFactory to only create one > TextIndexLucene object per on disk directory. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] jena pull request: Add memoizing of LuceneTextIndexes so that ther...
Github user afs commented on the pull request: https://github.com/apache/jena/pull/123#issuecomment-177246334 Starting from the JENA-1122 description: > Two Fuseki services, linking to the same dataset description. Fuseki only calls assemblers once. No other system is (legitimately) calling Fuseki service building. The configuration file processing puts service access points into the server-wide state. There is no service assembler (it could be done but it isn't, it serves no purpose); it is done by custom processing during walking the datastructure which is happening anyway. In the Fuseki case, we want shared datasets descriptions, that is, same name, to yield the same dataset. Processing dataset descriptions is driven by assemblers and they have names for keys using the root resource. A general "dataset sharing" outside assemblers is hard because of the lack of key. In other cases, I can imagine that a shared description alone does not always imply a shared object - in-memory datasets for example. The more general area is not clearly defined. The solution I see is that Fuseki handles the process step for the link: ``` fuseki:dataset <#dataset> <#dataset> rdf:type ja:RDFDataset(OrSubType) ``` This happens in `Builder.buildDataService` as it calls `Assembler.general.open(datasetDesc)`. It looks to me that if sharing is provided here, the problem statement of JENA-1122 is addressed. One matter arising: Service descriptions can be in multiple files (it is the preferred pattern to use `configuration/`). The template system behind the UI uses relative URIs so names of descriptions are unique across the server. If a user manually writes two configuration files, but uses the same absolute URI and they meant it to be different, we have a problem and this could be made to cause an error (safe choice to force shared datasets to be in the server `config.ttl`). `FusekiConfig.initializeDataAccessPoints` is the driver, it calls `readConfigurationDirectory` and the others places service descriptions can be and so needs checking. For now, just solving this for two services in the server configuration file, with entries in the `fuseki:services` list links is a good start. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
