You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@vcl.apache.org by "Aaron Coburn (JIRA)" <ji...@apache.org> on 2013/02/28 02:40:11 UTC
[jira] [Commented] (VCL-577) Cloud Broker tool for VCL
[ https://issues.apache.org/jira/browse/VCL-577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13589035#comment-13589035 ]
Aaron Coburn commented on VCL-577:
----------------------------------
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