[
https://issues.apache.org/jira/browse/VCL-577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13589035#comment-13589035
]
Aaron Coburn edited comment on VCL-577 at 2/28/13 1:41 AM:
-----------------------------------------------------------
I wanted to check in on the status of this. I wasn't entirely sure what the
underlying triplestore is supposed to be -- there is a mention of both Joseki
and D2RQ, but it wasn't entirely clear to me whether those were going to work.
A couple of questions:
1) Looking at the patch file, it looks like you are using a series of MySQL
queries to simulate a triplestore. I think the better approach would be to have
a simple method that is part of the XML-RPC framework that returns an RDF
representation of the object (i.e. in your proposed OWL ontology), and then
push the RDF into a real triplestore. And for this, have you considered using
something like Clerezza or Fuseki (on top of Jena) for the triplestore? They
are a bit more modern than Joseki. Or possibly even a Stanbol Entity hub, which
would make it significantly easier to handle text-based or LD-Path-based
queries (especially for searching across rdfs:label fields) -- which will be
key if users are searching for applications with free-text. My suggestion would
be to use either Clerezza or Stanbol, with some preference for Stanbol -- they
are both top level apache projects, and they would integrate nicely,
license-wise.
2) Since you are suggesting that data is effectively mirrored outside the VCL
infrastructure, what are your thoughts about publishing the data modifications
to a message broker and then using a subscriber to publish changes to the
triplestore? I would be curious to know what other VCL devs think of adding an
optional message broker to the VCL setup -- I think, there may be a lot of
potential uses for this outside the context of this reservation broker.
3) As for the OWL ontology you created, I would think the rdfs:domain should be
a fully qualified URI, and I would recommend using
http://vcl.apache.org/ontology#image. Second, I think that the rdf:ID values
should be made more consistent in terms of upper/lower case; my inclination
would be to use camelCase. I would also suggest changing how you represent
internal IDs (ownerid, imagemetaid, platformid, basedoffrevisionid, osid) -- I
wouldn't use string literals for these -- instead, I would use the database
"name" values: ownerid becomes unityid + affiliation.name; platformid becomes a
URI such as http://vcl.apache.org/ontology#platform:{type}, etc, etc.
was (Author: acoburn):
I wanted to check in on the status of this. I wasn't entirely sure what the
underlying triplestore is supposed to be -- there is a mention of both Joseki
and D2RQ, but it wasn't entirely clear to me whether those were going to work.
A couple of questions:
1) Looking at the patch file, it looks like you are using a series of MySQL
queries to simulate a triplestore. I think the better approach would be to have
a simple method that is part of the XML-RPC framework that returns an RDF
representation of the object (i.e. in your proposed OWL ontology), and then
push the RDF into a real triplestore. And for this, have you considered using
something like Clerezza or Fuseki (on top of Jena) for the triplestore? They
are a bit more modern than Joseki. Or possibly even a Stanbol Entity hub, which
would make it significantly easier to handle text-based or LD-Path-based
queries (especially for searching across rdfs:label fields) -- which will be
key if users are searching for applications with free-text. My suggestion would
be to use either Clerezza or Stanbol, with some preference for Stanbol -- they
are both top level apache projects, and they would integrate nicely,
license-wise.
2) Since you are suggesting that data is effectively mirrored outside the VCL
infrastructure, what are your thoughts about publishing the data modifications
to a message broker and then using a subscriber to publish changes to the
triplestore? I would be curious to know what other VCL devs think of adding an
optional message broker to the VCL setup -- I think, there may be a lot of
potential uses for this outside the context of this message broker.
3) As for the OWL ontology you created, I would think the rdfs:domain should be
a fully qualified URI, and I would recommend using
http://vcl.apache.org/ontology#image. Second, I think that the rdf:ID values
should be made more consistent in terms of upper/lower case; my inclination
would be to use camelCase. I would also suggest changing how you represent
internal IDs (ownerid, imagemetaid, platformid, basedoffrevisionid, osid) -- I
wouldn't use string literals for these -- instead, I would use the database
"name" values: ownerid becomes unityid + affiliation.name; platformid becomes a
URI such as http://vcl.apache.org/ontology#platform:{type}, etc, etc.
> Cloud Broker tool for VCL
> -------------------------
>
> Key: VCL-577
> URL: https://issues.apache.org/jira/browse/VCL-577
> Project: VCL
> Issue Type: New Feature
> Components: database, vcld (backend), web gui (frontend)
> Affects Versions: 2.3, 2.4
> Environment: PhP, perl, web servers and Semantic Web technologies -
> OWL, RDF, SPARQL
> Reporter: Karuna P Joshi
> Labels: Broker
> Fix For: 2.4
>
> Attachments: VCLbroker_MYSQL_script.sql, vclbroker.patch,
> VCL_broker.pdf, VCL_broker_screenshot_final.jpg, VCL_broker_screenshot.jpg,
> VCL_cloud_broker.pdf
>
> Original Estimate: 2,520h
> Remaining Estimate: 2,520h
>
> Cloud Broker tool that will enable VCL users to specify their requirements
> via policies. For instance, they can specify their security needs, their
> software needs etc. using a web interface. The broker tool will discover the
> image that best matches these policies.
> The users (or broker tool ) can then issue a reservation for that particular
> image. This feature will be very useful for instances where the VCL user is
> not sure which VCL image will best match their needs.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
