- From: Marjolein Katsma <wkf1s1l9yfpruqn001@sneakemail.com>
- Date: Thu, 23 Jan 2003 23:12:05 +0100
- To: www-rdf-interest@w3.org
Well, I think I've found something that works - at least works for me. It took several days of heavy thinking and scribbling since I'm still somewhat unfamiliar with RDF concepts and syntax - but I'm getting there, I think.
Before describing the solution (or my attempt at it) let me try to reformulate the problem:
- I write software, mostly "extensions" to existing software
- I want to make all of them available on a new site, and describe what's available with RDF (and generate most HTML pages from there)
- My products are distributed as "packages" but generally depend on (at least) the application it's an extension _for_ to be present on the user's system
- In describing my products and packages, I need to be able to refer to file and directory paths that are *relative* to wherever the user has installed the "target application" - but I have no idea what the *actual* installation path on the user's system is. I need such relative paths to "installation path" both for specifying which files already installed with the target application may be required, as well as where my package would need to be installed, and where the files it contains would then end up on the user's system.
1. There is a general "Catalog" RDF which sums up and classifies all available products; each product may have several versions.
2. For each product, there is a single RDF file describing details for each product version; such a description includes a reference to how the product may be distributed in the form of one or more packages (e.g., different packages may target different target applications for the same product).
3. For each package, there is a separate RDF file. This specifies all possible details about a package, including required applications, target applications, etc.
Working backwards from how I arrived at a solution, here's what I'm doing:
a) In a package RDF, I establish an abstract resource "DirectoryPath" as follows:
<hsx:DirectoryPath rdf:ID="app_path">
<dc:description>The path where the chosen target application is installed; this path, or a directory below it, should
be used as the target for installing this package.
</dc:description>
</hsx:DirectoryPath>
Note there is no *value* for this "app_path" - merely a dc:description which (together with the entry fopr DirectoryPath in the RDF Schema) gives its semantics; so what this does is to establish an _identity_ for "the installation path" without saying (having to say) what that installation path actually is.
b) The package RDF then has an entry for each possible related application; this is NOT a full description of the (required or target) application but describes (only) how that application relates to the package. Thus a particular application may occur in different package RDFs, but with different properties (only those that are relevant to the relationship between my the package and the application).
[I found this has the interesting implication that each package actually *needs* its own separate RDF file; I cannot combine descriptions for several packages in a single file since I would no longer be able to have "local" application descriptions that are different.]
Example:
<hsx:Application rdf:ID="homesite_3.x">
<hsx:appName rdf:value="HomeSite 3.x"/>
<hsx:role rdf:ParseType="Collection">
<hsx:RequiredApplication>
<hsx:minAppVersion rdf:value="3.0"/>
<hsx:maxAppVersion rdf:value="3.01"/>
</hsx:RequiredApplication>
<hsx:TargetApplication"/>
</hsx:role>
<hsx:appInstallationPath rdf:resource="#app_path"/>
</hsx:Application>
<hsx:Application rdf:ID="cfstudio_3.x">
<hsx:appName rdf:value="ColdFusionStudio 3.x"/>
<hsx:role rdf:ParseType="Collection">
<hsx:RequiredApplication>
<hsx:minAppVersion rdf:value="3.1"/>
<hsx:maxAppVersion rdf:value="3.11"/>
</hsx:RequiredApplication>
<hsx:TargetApplication/>
</hsx:role>
<hsx:appInstallationPath rdf:resource="#app_path"/>
</hsx:Application>
Note that there are *two* applications here, *both* of which refer to the same (abstract) DirectoryPath "app_path" as its "appInstallationPath". This is because either of the two applications can be the target for my package. I've defined extra properties for the role "RequiredApplication" (minimum and maximum version) but the role "TargetApplication" has (as yet) no attributes. (I deduce from teh grammar that it's possible to have a node like this without further properties.
c) For the package I now need to be able to defien where to install it; for this, I define a further abstract DirectoryPath "target_path" as follows:
<hsx:DirectoryPath rdf:ID="target_path">
<dc:description>The (base) target for installing this package; defined as (a subdirectory of) the path where the chosen
target application is installed.
An empty subdirectory value means that the path is actually identical (not relative) to the target application
installation path.
</dc:description>
<hsx:targetBasePath rdf:resource="#app_path"/>
<hsx:targetSubdir rdf:value=""/>
</hsx:DirectoryPath>
In this case, I'm saying that the target installation path of my package will be the same as the target application's installation path by setting the "targetSubdir" to an empty string.
d) Finally, in the package description, I refer to the two applications as well as the now established abstract "target installation path" as follows:
<hsx:Package rdf:about="urn:hsx:vtmltageditors_199804200605_1">
<dc:title>VTML Tag Editors 1.0</dc:title>
<dc:description>This package contains Tag Editors for VTML and a Tag Chooser file updated
to refer to the VTML Tag Editors, as well as supporting images.
</dc:description>
...
<hsx:requirements>
<rdf:Description>
<hsx:requiresApps>
<rdf:Alt>
<rdf:li rdf:resource="#homesite_3.x"/>
<rdf:li rdf:resource="#cfstudio_3.x"/>
</rdf:Alt>
</hsx:requiresApps>
<hsx:extendsApps>
<rdf:Alt>
<rdf:li rdf:resource="#homesite_3.x"/>
<rdf:li rdf:resource="#cfstudio_3.x"/>
</rdf:Alt>
</hsx:extendsApps>
</rdf:Description>
</hsx:requirements>
...
<hsx:targetInstallationPath rdf:resource="#target_path"/>
<hsx:inDistribution>
<rdf:Description>
<hsx:manifest rdf:parseType="Collection">
<hsx:TagChooser hsx:targetFilePath="MarkUpTags.vtm"/>
<hsx:TagEditor hsx:targetFilePath="TagEditors/Attrib.vtm"/>
...
<hsx:Image hsx:targetFilePath="TagEditors/Images/writeonly.bmp"/>
</hsx:manifest>
</rdf:Description>
</hsx:inDistribution>
</hsx:Package>
Here, "requirements" contains references to the locally-defined applications, and "targetInstallationPath" references the abstract DirectoryPath "target_path". Also the property "targetFilepath" as used in the "manifest" is again intended to be relative to the target installation path.
Questions:
- Do you think this is a valid approach or do you see any flaws that I don't notice as an RDF newbie?
- Is it indeed valid to use a node without any properties as I've done for the role "TargetApplication"?
- Is is valid to use an empty string as value (in particular, use rdf:value with an empty string) as I've done hereto indicate "no subdirectory"?
Any and all comments welcome. For now, these RDF files are still local on my machine, but I can post them somewhere if you want to look at the complete files (as complete as they are now, that is).
At 13:48 2003-01-19, I wrote:
>Hi Seth,
>
>Maybe I didn't make myself clear enough or maybe I don't understand what you mean :)
>But your example code suggests referring to an actual path (file:///C:/wherefor/whatever/) on a user's machine. Is that what you meant?
>
>I can't do that since I don't know what that path is - only the user installing my package knows where they installed the application that my package is an extension for. I still need to refer to files that are part of that application that I don't know the installation path for - all I can say is that those files have a particular path *relative* to whatever the installation path is: I know what the relative path is - I don't know what it's relative *to* except logically as "wherever you installed application X or Y".
>
>So my problem is: how do I describe a path relative to a base path that can be described only logically but not as a specific path?
>
>Sorry if I misunderstood your suggestion though - I'm still new at this. If I did misunderstand could you try to explain a bit more? Thanks!
>
>At 19:59 2003-01-18, Seth Russell wrote:
>>Have you considered using a Bnode to denote the installation on a person's computer ?
>>In N3 it would look something like:
>>
>>[ foo:installDirectory <file:///C:/wherefor/whatever/> ;
>> foo:installedName "Seth Russell";
>>..... other parameters relative to the clients installation ...]
>>
>>With the new RDF syntax you could use a Bnode ID to refer to it from other nodes.
>>
>>Seth Russell
>>http://radio.weblogs.com/0113759/
>>
>>----- in response to ----
>>Marjolein Katsma wrote:
>>
>>>Still working on my package descriptions (developing an RDF schema to describe software packages).
>>>
>>>A package consists of files; the location of these files can be described using xlink:href with a URI relative to the package itself (as distributed, as well as once installed. I think that in this scenario it is not necessary to define a base path (xml:base) since the package (distribution) itself provides the base path. (Is this correct?)
>>>
>>>Things become more complicated when I need to refer to required files on the user's system (not included in the package but required for its functionality). Essentially they would still be relative paths - but relative to the "installation path" of the application my package is an extension for. The actual installation path will be different for different users; still that installation path will also be the target installation path for my package, so (more or less): a path relative to the distribution == a path relative to the installed package AND a path relative to the installed package == a path relative to the user's application path.
>>>I'm not sure if I would need to define a base path for required files in this case (strictly speaking they can't be relative to the distribution of my package since they're not included - but *will* be relative to the package once installed correctly).
>>>
>>>A related question is: is there a way to self-reference an RDF file, so that (for instance) I could use an RDF statement *within* the file to state something like: all xlink:hrefs in this file are relative to [some logical description of "application installation path"]?
>>>
>>>Suggestions, anyone?
>>>
>>>.
>>>
>>>
>>
>
>--
>Marjolein Katsma
>HomeSite Help - http://hshelp.com/
>Java Woman - http://javawoman.com
--
Marjolein Katsma
HomeSite Help - http://hshelp.com/
Java Woman - http://javawoman.com
Received on Thursday, 23 January 2003 17:12:34 UTC