[I've been a member of this list for quite a while already, sometimes reading, often skipping what seemed too theoretical for the moment - sometimes going back and reading what seems relevant to the problem I'm trying to solve, like I did the last few days. Still, I'm setting out for the first time to actually apply RDF, so I'm quite newbie enough. I've started creating an RDF schema.]
Here's the problem that's the subject of this message:
I'm trying to set up RDF for a new (sub)site where I will document and distribute some software, mostly extensions to an existing program. I'm envisioning that much of the content of the site (apart from actual texts I'd have to write) will be RDF-driven. I soon recognized that I'd have "Products" and "Packages" with a Package a subclass of Product; and as part of the RDF I'd need for this site, I'd need a way to describe Packages in terms of the files they contain. Reading through the RDF Primer I found a description of XPackage which I looked up; I found the package concept (almost) completely matched my own, so it would be logical to use XPackage [1] (the package part, not the XML files part) as part of my solution, instead of creating my own vocabulary for that.
However, I find I need to make two distinctions (or refinements): the reason is that there would (in my mind) be a difference between the "logical" package (all of the functionality as available on the user's system (once installed) with all the files needed for that functionality) and a "physical" package which is what I would distribute. I know "logical" and "physical" aren't very good terms here - I'm open to suggestions - but I hope you'll understand what I mean. There are two differences:
- the "logical" package (once on the user's system) can "consist of" some files that are not in the "physical" (downloadable) package: they would be already on the user's system (installed with the program my package is an extension for) and I have no distribution rights anyway;
- the "physical" package may also contain some files serving as documentation (readme, release notes, etc.) that are not strictly required for functionality, and the user may safely throw these away and not lose any functionality; I realize this more or less breaks the package concept as consisting of exactly those things that _are_ needed for functionality.
It seems obvious to me I'd need some vocabulary in addition to what XPackage provides to express these distinctions/refinements but I'm not entirely sure if I could just add these to my own RDF schema and then "mix and match" with XPackage statements or whether I'd actually have to use a complete vocabulary of my own for this since it doesn't quite fit within XPackage and the concepts it's based on.
If anyone has dealt with such extensions (specifically of XPackage) or suggestions for how to go about it, I'd like to hear from you. Thanks in advance for any insights, suggestions or examples you may come up with!
[Since I'm only just starting on this little project, please bear with me: I'll probably be back with more questions.]
[1] http://www.xpackage.org/specification/