August 09, 2003
Processing fragments?
What's better here?
<hamsandwich:group rdf:resource="http://ideaspace.net/schema#parent/child"/>This:
<hamsandwich:group rdf:resource="http://ideaspace.net/schema/parent#child"/>Or this:
<hamsandwich:group rdf:resource="http://ideaspace.net/schema/parent/child"/>
What I'm after here is a vocabulary listed at http://ideaspace.net/schema has a hierarchy within it. It's a descriptive vocabulary with many parent and subsequent child layers.
When I ask "what's better" I'm asking in the context of what's the least horrible way to express it such that it doesn't put undue burden upon the various tools that might be used to parse it?
Realizing that I may also make it more human readable by serializing it this like as well:
<hamsandwich:group rdf:resource="http://ideaspace.net/schema/parent#child">
<rdf:label>Child of Parent</rdf:label>
</hamsandwich:group>
In reality, however, the labelling of the various points within the hierarchy might not need to be marked up as such when both sides already know what human-readable labelling should be applied to them. This if just to stave of the nitwits that want to jump in and whine about verbosity.
So there's my question, if I emit data that's marked up in this manner what would be the least painful way for something doing triplespace queries to reach into the dataset and find exact points in the hierarchy as well as possible portions 'higher' in it?
i think that *best* ones from those listed above are #1 and #3
#1 is good because it would allow you to relocate entire ...#parent/child hirearchy from one base url to another and the symbol # can be used to distinguich hierachy out of base schema location
#3 is good because it allows you to use pseudo-subdirectory url syntax and therefore you can implement your hierachies as tree of file resources (with xml schema and or namespace namespace declared for each parent/child)
while i think those (#1 and #3) are good i'd prefer entirely different syntax for hierachies
here is an example
http://hostname.domainname.domainsuffix:port/bloodyblah/baseurl;dynserverparam=123?parent/child
you see that parent/child in that case just a parameter name in query string, so in your web application that suppose to provide client with properties of hierachy elements you simply use query string without any additional parsing of a baseurl whinch is in that case:
http://hostname.domainname.domainsuffix:port/bloodyblah/baseurl;dynserverparam=123
if you move your app from one url to another it will work using query string key without any change of the code
so i vote for separation of application semantic from the transport and location sematic (a.k.a base url)
Posted by: igor bazdyrev (igor.txt.net) on August 9, 2003 08:42 PM
