Best Practice - When to XSD versus RDF - How to convert
Just prior to looking seriously at Jazz, we created a for a current company application (well, really just a bunch of Database Tables), by defining an XSD, and implementing over Rest. This was largely for practice in moving towards OSLC/Jazz. Certainly, the DB aspect lends itself to the criteria for Rest.
Now, with a little more Jazz under the belt, we're wanting this to fit better into Jazz environment.
First, we looked for an appropriate OSLC interface, but did not find one that really fit well necessarily.. certainly, the DB holds vastly more specific info than the OSLC would ever dream of defining. (i.e. application owners, recovery plans, funding models, etc).
What has been the overall "Best practice" emerging for non-industry tools like this.
Should we:
1) Redo XSD into more RDF form, i.e. our own "Internal Spec". Is there guidance/tool here?
2) Use something like RM spec, indicating "here's where you find App Info, using xyz.xsd", and not expect to really update information?
3) Do a mixed approach, finding the closest OSLC spec as possible, and leave the full content in XSD defined structures?
Should I be asking different questions? ;)
Thanks,
Now, with a little more Jazz under the belt, we're wanting this to fit better into Jazz environment.
First, we looked for an appropriate OSLC interface, but did not find one that really fit well necessarily.. certainly, the DB holds vastly more specific info than the OSLC would ever dream of defining. (i.e. application owners, recovery plans, funding models, etc).
What has been the overall "Best practice" emerging for non-industry tools like this.
Should we:
1) Redo XSD into more RDF form, i.e. our own "Internal Spec". Is there guidance/tool here?
2) Use something like RM spec, indicating "here's where you find App Info, using xyz.xsd", and not expect to really update information?
3) Do a mixed approach, finding the closest OSLC spec as possible, and leave the full content in XSD defined structures?
Should I be asking different questions? ;)
Thanks,
5 answers
Jonathan,
As a start, I can give you some good references to RDF. Because JFS has native RDF support and if you have the freedom to define your own internal format, I think it makes sense to try using it. However, keep in mind that RDF is more "semantic" than XML/XSD because it deals with triples and triple graphs and provides many different serialization formats.
Here are some references from w3c:
RDF does not immediately impose metadata expectations. You can come with an RDF format and define all or parts of the metadata after the fact. In fact, any given set of RDF triples may be given any number of meta-data definitions. Also, keep in mind that, although RDF has (several) XML serialization formats, it does not require XML or XSD. E.g. "turtle" is quite popular format although XML is often used as well.
Others are more qualified to comment on the suitability of existing OSCL specs for your purposes
Hope that helps,
Simon
As a start, I can give you some good references to RDF. Because JFS has native RDF support and if you have the freedom to define your own internal format, I think it makes sense to try using it. However, keep in mind that RDF is more "semantic" than XML/XSD because it deals with triples and triple graphs and provides many different serialization formats.
Here are some references from w3c:
RDF does not immediately impose metadata expectations. You can come with an RDF format and define all or parts of the metadata after the fact. In fact, any given set of RDF triples may be given any number of meta-data definitions. Also, keep in mind that, although RDF has (several) XML serialization formats, it does not require XML or XSD. E.g. "turtle" is quite popular format although XML is often used as well.
Others are more qualified to comment on the suitability of existing OSCL specs for your purposes
Hope that helps,
Simon
Just prior to looking seriously at Jazz, we created a for a current company application (well, really just a bunch of Database Tables), by defining an XSD, and implementing over Rest. This was largely for practice in moving towards OSLC/Jazz. Certainly, the DB aspect lends itself to the criteria for Rest.
Now, with a little more Jazz under the belt, we're wanting this to fit better into Jazz environment.
First, we looked for an appropriate OSLC interface, but did not find one that really fit well necessarily.. certainly, the DB holds vastly more specific info than the OSLC would ever dream of defining. (i.e. application owners, recovery plans, funding models, etc).
What has been the overall "Best practice" emerging for non-industry tools like this.
Should we:
1) Redo XSD into more RDF form, i.e. our own "Internal Spec". Is there guidance/tool here?
2) Use something like RM spec, indicating "here's where you find App Info, using xyz.xsd", and not expect to really update information?
3) Do a mixed approach, finding the closest OSLC spec as possible, and leave the full content in XSD defined structures?
Should I be asking different questions? ;)
Thanks,
Jonathan,
I am going to take a guess (or two) that you want to surface some resource type(s) that you currently have modeled with XSD, instances can be exchanged as XML, and you store in a relational database.
Your first question: "when to XSD versus RDF?" needs to be qualified with a "for what". Again, I'm gonna make a few assumptions (given this context), that you want your resources to be made available to other Jazz applications, so they can be at least linked to (CLM link), and possibly navigated to (and rendered) in a browser and provide hover help.
If you want other Jazz applications to actually parse and use the information in your resources you will have to expose them as RDF in one form or another (RDF/XML, JSON, Turtle, ...). The current core spec requirement is that all OSLC resources MUST provide RDF/XML and MAY provide other formats. And it defines the rules for constructing the RDF/XML (not all RDF/XML is alike).
In addition to providing your resources in RDF form, you'll need to implement one of the OSLC specs, ideally the one that most closely matches the semantic intent of the resources that you are managing. However the reality is that for generic life cycle artifacts, you probably want to look at the RM and AM specifications, as these are the most generic. This is required because Jazz applications only know how to interact with known specifications. There is no generic OSLC interface that generic clients can implement or consume to manage resources (OSLC AM, RM and QM are about as close as you will find).
As the OSLC AM lead, I'll point out some features that may be of use, that currently are not in the other specs. In the AM domain, we realized early on that we'd never be able to canonically define all the resource types and shapes that are considered architecture artifacts (i.e. UML models, ER diagrams, deployment topologies, etc.). Rather, like the other specs we'd define a least common set of properties for the specification, but provide a means by which service implementers could manage opaque resources of their own. For example, suppose we considered a power point deck an architecture resource. The AM specificaion defines how an implementer can accept a POST of such a black box resource, and in turn provide a OSLC AM resource representation of it (RDF based). This RDF representation can include any number of properties of the deck that were parsed from the resources (i.e. slide titles, text runs, images). These properties can appear in the OSLC AM resource document as basic properties, albeit in RDF/XML. Where the AM spec is different is we also use the property dcterms:source to provide a URL to the client, that they can in turn use to perform a GET on, to obtain the original power point deck POSTed.
Getting back to your scenario, you could implement the OSLC AM specification, and POST (and GET) your current XML documents, as well as providing OSLC AM representations for them, that can be discovered, linked to and in general integrated with other Jazz applications.
I am going to take a guess (or two) that you want to surface some resource type(s) that you currently have modeled with XSD, instances can be exchanged as XML, and you store in a relational database.
Your first question: "when to XSD versus RDF?" needs to be qualified with a "for what". Again, I'm gonna make a few assumptions (given this context), that you want your resources to be made available to other Jazz applications, so they can be at least linked to (CLM link), and possibly navigated to (and rendered) in a browser and provide hover help.
If you want other Jazz applications to actually parse and use the information in your resources you will have to expose them as RDF in one form or another (RDF/XML, JSON, Turtle, ...). The current core spec requirement is that all OSLC resources MUST provide RDF/XML and MAY provide other formats. And it defines the rules for constructing the RDF/XML (not all RDF/XML is alike).
In addition to providing your resources in RDF form, you'll need to implement one of the OSLC specs, ideally the one that most closely matches the semantic intent of the resources that you are managing. However the reality is that for generic life cycle artifacts, you probably want to look at the RM and AM specifications, as these are the most generic. This is required because Jazz applications only know how to interact with known specifications. There is no generic OSLC interface that generic clients can implement or consume to manage resources (OSLC AM, RM and QM are about as close as you will find).
As the OSLC AM lead, I'll point out some features that may be of use, that currently are not in the other specs. In the AM domain, we realized early on that we'd never be able to canonically define all the resource types and shapes that are considered architecture artifacts (i.e. UML models, ER diagrams, deployment topologies, etc.). Rather, like the other specs we'd define a least common set of properties for the specification, but provide a means by which service implementers could manage opaque resources of their own. For example, suppose we considered a power point deck an architecture resource. The AM specificaion defines how an implementer can accept a POST of such a black box resource, and in turn provide a OSLC AM resource representation of it (RDF based). This RDF representation can include any number of properties of the deck that were parsed from the resources (i.e. slide titles, text runs, images). These properties can appear in the OSLC AM resource document as basic properties, albeit in RDF/XML. Where the AM spec is different is we also use the property dcterms:source to provide a URL to the client, that they can in turn use to perform a GET on, to obtain the original power point deck POSTed.
Getting back to your scenario, you could implement the OSLC AM specification, and POST (and GET) your current XML documents, as well as providing OSLC AM representations for them, that can be discovered, linked to and in general integrated with other Jazz applications.
Thank you very much for the reply, Shelson,
I've been studying hard on RDF, and while I've previously seen and studied these links, I'm sure they'll be helpful for any others who chance upon this thread!
For me, RDF is an entirely different animal than declaring an interface, and implementing/calling it in the classic Client/Server in various flavors in the past. While I've seen a lot about the mechanics of dealing with triplets, etc, and I've looked a bit at RDFS, Even with the comforting addition of the term "Schema" in RDF/S, I am coming to the conclusion that that applying the typical Meta-Data->Compile->fill out data model is rather missing the point of RDF, and isn't really what RDF/S is about either.
I think, perhaps, the best path for me is to go back and study the OSLC Core Glossary again
http://open-services.net/bin/view/Main/OSLCCoreSpecDRAFT?sortcol=table;table=up#Glossary_of_terms
It appears that perhaps the key to my understanding may be in the definition of
1) OSLC Resource
2) OSLC Properties (which contains familiar terms like "Occurs" and "Value-types") and may provide the best clue
I've had better luck with formulating Internet searches today. W3C has a page referencing various "Converters" (http://esw.w3.org/ConverterToRdf), and I will investigate "TopBraid" referenced there.
Thanks again!
I've been studying hard on RDF, and while I've previously seen and studied these links, I'm sure they'll be helpful for any others who chance upon this thread!
For me, RDF is an entirely different animal than declaring an interface, and implementing/calling it in the classic Client/Server in various flavors in the past. While I've seen a lot about the mechanics of dealing with triplets, etc, and I've looked a bit at RDFS, Even with the comforting addition of the term "Schema" in RDF/S, I am coming to the conclusion that that applying the typical Meta-Data->Compile->fill out data model is rather missing the point of RDF, and isn't really what RDF/S is about either.
I think, perhaps, the best path for me is to go back and study the OSLC Core Glossary again
http://open-services.net/bin/view/Main/OSLCCoreSpecDRAFT?sortcol=table;table=up#Glossary_of_terms
It appears that perhaps the key to my understanding may be in the definition of
1) OSLC Resource
2) OSLC Properties (which contains familiar terms like "Occurs" and "Value-types") and may provide the best clue
I've had better luck with formulating Internet searches today. W3C has a page referencing various "Converters" (http://esw.w3.org/ConverterToRdf), and I will investigate "TopBraid" referenced there.
Thanks again!
Jonathan,
James,
Thank you, this is exactly the kind of guidance I need. Ironically, I was posting while you were, and I see I started to turn a bit in your direction.
I will look carefully at your references and Spec in light of your comment.
P.S. Just so you know, in my Thread Subject, I used XSD and RDF as verbs intentionally as I thought it was rather poetic, and might catch someone's eye... I'm glad it caught yours.
OK, I think I can formulate more relevant questions now.
My assumption in this question was that ultimately, after all the reference passing, Queries, etc, a client would need to get down to some content that can be parsed and used programmatically (i.e. Java)
I'm assuming that in the case of Hover Help, it would display as much information (i.e. Description, Id, etc) as comes in the Properties of the message).
In the case of Browser Rendered app, then the Service itself is really providing all the interpretation with JavaScript/CSS or other WebGUI mechanism.
Exposing in RDF was the second part of my question.
RDF/S doesn't appear to be any sort of contract like XSD is, and W3C pages specifically says that it's not intended to be "Validated", etc. It appears a bit more like the method to create some Definitions akin to Dublin Core for your own use, in some ways like "import" within XSD.
While I could come up with some RDF (and have in some samples), how would the End client (specifically a Tool in an OSLC domain) have any idea of what to do with it? Searching through with XPath, etc, implies the client knows enough about the about the content to find it.
Is there an OSLC or Jazz way for a Client side Developer, at Development time, to know what incoming content may or may not have in it, so he can do something with it? Or is my suspicion correct, that that kind of content passing is beyond the scope of OSLC?
I did look at "Resource Shapes", but appears to be intended only for properties accompanying the request, and not wholesale definition of content.
Thanks
Your first question: "when to XSD versus RDF?" needs to be qualified with a "for what". Again, I'm gonna make a few assumptions (given this context), that you want your resources to be made available to other Jazz applications, so they can be at least linked to (CLM link), and possibly navigated to (and rendered) in a browser and provide hover help.
My assumption in this question was that ultimately, after all the reference passing, Queries, etc, a client would need to get down to some content that can be parsed and used programmatically (i.e. Java)
I'm assuming that in the case of Hover Help, it would display as much information (i.e. Description, Id, etc) as comes in the Properties of the message).
In the case of Browser Rendered app, then the Service itself is really providing all the interpretation with JavaScript/CSS or other WebGUI mechanism.
If you want other Jazz applications to actually parse and use the information in your resources you will have to expose them as RDF in one form or another (RDF/XML, JSON, Turtle, ...). The current core spec requirement is that all OSLC resources MUST provide RDF/XML and MAY provide other formats. And it defines the rules for constructing the RDF/XML (not all RDF/XML is alike).
Exposing in RDF was the second part of my question.
RDF/S doesn't appear to be any sort of contract like XSD is, and W3C pages specifically says that it's not intended to be "Validated", etc. It appears a bit more like the method to create some Definitions akin to Dublin Core for your own use, in some ways like "import" within XSD.
While I could come up with some RDF (and have in some samples), how would the End client (specifically a Tool in an OSLC domain) have any idea of what to do with it? Searching through with XPath, etc, implies the client knows enough about the about the content to find it.
Is there an OSLC or Jazz way for a Client side Developer, at Development time, to know what incoming content may or may not have in it, so he can do something with it? Or is my suspicion correct, that that kind of content passing is beyond the scope of OSLC?
I did look at "Resource Shapes", but appears to be intended only for properties accompanying the request, and not wholesale definition of content.
Thanks