« Uniform Interface | Main | Statistically improbable phrases »

Trading off

[Updated 2005-05-16: Danny Ayers and Julien Couvreur pointed me towards a better way to mark up the DOAP so that source code repositories can be given an identifier.]

These days we are all complexity experts and simplicity mavens. Once upon a time a popular way to trash somebody's technical design without having to bother to present a cogent argument was to point at it and say it would never scale. Today we just can call designs we don't like complex - that's even better because while it's unlikely to happen, you can actually have a meaningful conversation about scale. Complexity on the other hand is comparatively vague - indeed there is only one simple definition of simplicity for software.

Finger pointing and glibness aside, figuring out where and when to make a design tradeoff across the complexity/simplicity divide is difficult. Really difficult. And important. Aim too low and your technical designs won't scale (whatever that means) or be useful except for toy scenarios. Aim too high and no-one will be able to get past the actual or perceived complexity of the design - half the intended audience will get up and leave.

How to apply web metadata, especially with XML formats has seen all kinds of tradeoff issues and arguments. From RDF to RSS to SOAP to WSDL, one common theme is an endless debate about complexity.

In this entry I wanted to talk about a bit about a complexity/simplicity tradeoff centering around extensibility. Everyone loves extensibility, almost as much as simplicity in fact, and you will not hear many bad words said about the idea. Specifically I wanted to get specific and narrow it down to one issue - repository metadata in a format called DOAP.

DOAP is a format based on RDF for describing projects, by Edd Dumbill. It stands for Description Of A Project. It caused something of a shock when it was published, for two reasons. First it amply demonstrated that we have hardly any useful or interesting metadata about software projects. Which is terribly bad when you think about how much of the stuff we put out every year. Second, and this was far more shocking, it was a readable RDF/XML format. Shocking because up to then, everyone knew, just knew, that RDF/XML was insanely complex and comprehensible markup simply could not be produced with it (even I knew it). There are approximately 5 wildly successful RSS formats based on that assumption and who knows how many other domain specific formats.

The problem I was having was how to describe a software project or a unit of work. DOAP seemed like a good start, but there were some things I wanted to say that DOAP does not support, mostly around source code repositories. This lead me into a mire of decision making and trading off that was quite unexpected. That's the thing about working on software and data formats - you never know when you are about to fall down a rat hole.

Here's an example DOAP fragment that describes some details about a Subversion repository (there's a lot more you can put into one of these files, but we'll stick to the repository metadata for now):

  <doap:Project 
    xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
    xmlns:doap="http://usefulinc.com/ns/doap#"
    rdf:about="http://example.org/projects/blah/">
    <doap:name>blah blah</doap:name>
    <doap:repository >
      <doap:SVNRepository>
        <doap:location rdf:resource="http://example.org/svn/blah/"/>
        <doap:browse rdf:resource="http://example.org/svn/blah/"/>
      </doap:SVNRepository>
    </doap:repository>
  </doap:Project>

For RDF/XML that format is pretty good (RDF/XML can get complicated). Best of all, you can easily rip through it with a regular XML toolchain - scripting against DOAP markup isn't going to be a problem. The only thing that's a bit weird are those rdf:resource attributes peppered about the elements.

Now, there are other things we might want to say about a Subversion repository, than is allowed for by DOAP. For example DOAP doesn't have a notion for a repository alias and it's easy to alias http: accessible Subversion repositories. So to get there, we can try something like this:

  <doap:Project 
    xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
    xmlns:doap="http://usefulinc.com/ns/doap#"
    xmlns:ext="http://example.org/doap/plusplus/"
    rdf:about="http://example.org/projects/blah/">
    <doap:name>blah blah</doap:name>
    <doap:repository >
      <doap:SVNRepository>
        <doap:location rdf:resource="http://example.org/svn/waffle/"
            rdf:type="http://example.org/doap/plusplus/alias" />
        <doap:location rdf:resource="http://example.org/svn/blah/"/>
        <doap:browse rdf:resource="http://example.org/svn/blah/"/>
      </doap:SVNRepository>
    </doap:repository>
  </doap:Project>

Above we're using an rdf:type annotation to qualify a new doap:location as being an alias. The nice thing about rdf:type annotations is that they're entirely optional - if you're not looking for it, it won't break you. A DOAP-aware processor will accept that as a doap:location just fine. Aside from RDF, a lot of extension work and "duck-typing" with XML is done by sprinkling elements with attributes, as it's usually considered the least likely approach to break code. To break against unknown attributes you'd have to write (deeply) neurotic code of the form: "scan all the element's attributes, and if you don't recognize any of them, fall over". Some schemas are neurotic like this, but regular code doesn't tend to be. RDF goes a step further and bakes the idiom in for types, arguably in a way that's less intrusive than the approach taken by XML Schema.

Alternatively we could we could use a new element name to make a stronger distinction between doap:location and an alias. Here's an example where we make one up, called ext:alias:

  <doap:Project 
   xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
   xmlns:doap="http://usefulinc.com/ns/doap#"
   xmlns:ext="http://example.org/doap/plusplus/"
   rdf:about="http://example.org/projects/blah/">
    <doap:name>blah blah</doap:name>
    <doap:repository >
      <doap:SVNRepository>
        <ext:alias rdf:resource="http://example.org/svn/waffle/"/>
        <doap:location rdf:resource="http://example.org/svn/blah/"/>
        <doap:browse rdf:resource="http://example.org/svn/blah/"/>
      </doap:SVNRepository>
    </doap:repository>
  </doap:Project>

Unless you had domain-specific code that breaks when it sees new elements or had a strict schema that's going to be fine (an RDF-aware processor won't bat an eyelid at this). This approach is more likely to break regular XML code than attribute sprinkling, but again it does come down to how you do your programming, and in particular to whatever your policy towards extensions happens to be. Chances are fair a lot of code will just not pick the ext:alias and skip over it, but schema driven checks might choke.

So far, so good. Extending DOAP is looking straightforward.Although the various approaches to managing extensions are interesting in their own right, that's not what I want to focus on here. I want to concentrate on how we are using names and identity to manage extensions. What is allowing us to extend DOAP in large part is that the things of interest have names.

The thing about the way DOAP XML is structured is that although the Project has a name the Subversion repository itself has no explicit identity. It might not be entirely obvious from the XML so I'll elaborate a bit.

There are properties of a repository in the DOAP document, sure, but the repository itself has no proper name. The project does have a name - it's in the rdf:about attribute on the doap:Project. That means all the property-value metadata is asociated with the thing via its name. But the repository is dealt with differently. For example, the Jena toolkit will produce a table of subject-property-values something like this (using Qnames instead of URLs):

1 	http://example.org/projects/blah/ 	rdf:type 	doap:Project
2 	http://example.org/projects/blah/ 	doap:name 	"blah blah"
3 	http://example.org/projects/blah/ 	doap:repository 	genid:ARP132296
4 	genid:ARP132296 	rdf:type doap:SVNRepository
5 	genid:ARP132296 	ext:alias 	http://example.org/svn/waffle/
6 	genid:ARP132296 	doap:location 	http://example.org/svn/blah/
7 	genid:ARP132296 	doap:browse 	http://example.org/svn/blah/

Here's what that looks like in excel:

rdf-excel.GIF

See that "genid:ARP132296" thing? That's an internal identifier assigned by Jena's RDF/XML parser for the repository. Jena is a Java toolkit for working with RDF. Jena's parser (which is called ARP) has scanned our RDF and figured out that there is a thing in the RDF, which has properties, including a type annotation of doap:SVNRepository but has no explicit name. So it's been given a pseudo identifier - by pseudo I mean it's not globally unique. Contrast that with row 1 where Jena has realized that the name of the project 'thing' is "http://example.org/projects/blah/" just as we said it was a minute ago.

In one sense it's no big deal. Most keyed metadata today is laid out in the pseudo identified way. There are property values pairs and what they are property values of is entirely context-specific - either some specialised code or a person is going to appreciate that context and fill in the blanks. Context is king, and so on.

The problem is that relying on context is one of things that makes it tricky to share metadata. How do we pass this stuff around so it can be reused and merged with other - across time or space. Ok, so maybe you're thinking I've lost it there. "Time or space"? In italics? What?

Space might be easiest to make sense of - we could have project metadata scattered on a few different servers on the Web or inside a LAN. Without these shared names, merging that data is going to require people to go that extra yard (or mile, it depends) to figure out what goes where and embody that integration context knowledge in code or as rules as best they can. What about time? Well we might want to update the Subversion repository details later on. Like suppose six months later we added Atom/RSS feeds detailing the check in to our repository (by the way if you're not doing this with your repositories, you should try it out, it's great). To do that, I need to make up a new property because DOAP doesn't have a concept of repository commit feeds - let's put it in the same namespace as the repository alias we made up and call it 'commit-feed'. To update the XML we have to go into the document and drop in the new data like so:

  <doap:Project 
    xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
    xmlns:doap="http://usefulinc.com/ns/doap#"
    xmlns:ext="http://example.org/doap/plusplus/"
    rdf:about="http://example.org/projects/blah/">
    <doap:name>blah blah</doap:name>
    <doap:repository >
      <doap:SVNRepository>
        <doap:location rdf:resource="http://example.org/svn/blah/"/>
        <doap:browse rdf:resource="http://example.org/svn/blah/"/>
        <ext:alias rdf:resource="http://example.org/svn/waffle/"/>
        <ext:commit-feed rdf:resource="http://example.org/feed/svn/blah.xml"/>
      </doap:SVNRepository>
    </doap:repository>
  </doap:Project>

Now we can see and RDF tools will discover that the repository has a commit-feed property value. But here's the thing - with RDF I could have done that without ever touching the original document, if only the repository had a URL identifier. This is worth some explanation.

Remember that we said the project had an identifier "http://example.Org/projects/blah/"? lets give the project a pointer to the developer mailing list:

<rdf:Description 
    xmlns:rdf="http://www.W3.Org/1999/02/22-rdf-syntax-ns#"
    xmlns:doap="http://usefulinc.Com/ns/doap#" 
    rdf:about="http://example.Org/projects/blah/">
  <doap:mailing rdf:resource="http://example.Organ"/>
</rdf:Description>

I just did that without having the original metadata to manipulate. Once I know the name of something I can start writing down property value pairs about it. RDF people say this ability is useful because it enables third-party metadata ("anyone can say anything about anything"). But I just think it's cool. I did not need to worry about knowing what all my metadata might be upfront. I did not need to worry about how I'm going to manage extensibility. If I had a webservice exposed that supplied and accepted information about all my projects there would be no checkout step to get the right XML file, edit it and check it back in as an update. I would just pass the new data to the service and the data would get merged, and this would be no more difficult that a programmer added a new key-value pair to a hashmap or a manager adding a new row to a spreadsheet. Folks who fret about passing large XML documents around would have to find something else to worry about.

Actually, let's look at that excel spreadsheet again. Imagine our imaginary webservice was using excel to store its data. Here's what the merged data looks like:

rdf-excel1.GIF

And for those of us that just can't get enough of RDF/XML:

  <doap:Project 
    xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
    xmlns:doap="http://usefulinc.com/ns/doap#"
    xmlns:ext="http://example.org/doap/plusplus/"
    rdf:about="http://example.org/projects/blah/">
    <doap:name>blah blah</doap:name>
    <doap:repository >
      <doap:SVNRepository>
        <doap:location rdf:resource="http://example.org/svn/blah/"/>
        <doap:browse rdf:resource="http://example.org/svn/blah/"/>
        <ext:alias rdf:resource="http://example.org/svn/waffle/"/>
        <ext:commit-feed rdf:resource="http://example.org/feed/svn/blah.xml"/>
      </doap:SVNRepository>
    </doap:repository>
    <doap:mailing-list rdf:resource="http://example.org/mailman/listinfo/blah-dev"/>
  </doap:Project>
which is the unified document version of the two XML documents we started out with:
  <doap:Project 
    xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
    xmlns:doap="http://usefulinc.com/ns/doap#"
    xmlns:ext="http://example.org/doap/plusplus/"
    rdf:about="http://example.org/projects/blah/">
    <doap:name>blah blah</doap:name>
    <doap:repository >
      <doap:SVNRepository>
        <doap:location rdf:resource="http://example.org/svn/blah/"/>
        <doap:browse rdf:resource="http://example.org/svn/blah/"/>
        <ext:alias rdf:resource="http://example.org/svn/waffle/"/>
        <ext:commit-feed rdf:resource="http://example.org/feed/svn/blah.xml"/>
      </doap:SVNRepository>
    </doap:repository>
  </doap:Project>
<rdf:Description 
    xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
    xmlns:doap="http://usefulinc.com/ns/doap#" 
    rdf:about="http://example.org/projects/blah/">
  <doap:mailing-list rdf:resource="http://example.org/mailman/listinfo/blah-dev"/>
</rdf:Description>

So, we can see that RDF data is not especially document or file bound - as data it rides above them. Some people might think this means that syntax doesn't matter, but what it really means is that syntax and physical structures don't have to get in the way of extensibility. Documents and files are no less useful as a result, but you can stop thinking about them as being really tiny data silos that you have to manage and keep a track of, and organize, and particulary as really tiny data silos that don't always travel well.


Ages ago it seems like, I said there was a problem. What problem? Well I can't do what I did with the project mailing list for Subversion Atom feed, as things stand. That's because I have no URL identifier for the repository and that means creating a second chunk of metadata to pass in is a non-starter, as things stand. There was that genid thingy, but it's not safely shareable or usable as metadata (for all I know, the service is using Redland instead of Jena, or Jena has changed its id generation algorithm). Depending on that to be long-lived and have integrity would be like depending on primary keys between databases, only primary keys have a better chance of working out. In that repository case I am back to getting a handle on some kind of document to check out, update and check in. The document gives me enough initial context to find where to drop in the property value for the feed.

What can we do? We could hack the DOAP format to look this:

  <doap:Project 
    xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
    xmlns:doap="http://usefulinc.com/ns/doap#"
    xmlns:ext="http://example.org/doap/plusplus/"
    rdf:about="http://example.org/projects/blah/">
    <doap:name>blah blah</doap:name>
    <doap:repository >
    <rdf:Description 
         rdf:type="http://usefulinc.com/ns/doap#SVNRepository"
      rdf:about="http://example.org/projects/blah/svn/">
      <doap:location rdf:resource="http://example.org/svn/blah/"/>
      <doap:browse rdf:resource="http://example.org/svn/blah/"/>
      <ext:alias rdf:resource="http://example.org/svn/waffle/"/>
      <ext:commit-feed rdf:resource="http://example.org/feed/svn/blah.xml"/>
      </rdf:Description>
    </doap:repository>
  </doap:Project>

What's going on here? Well, remember earlier on I showed two ways to describe a repository's alias, one as an element and the other as an rdf:type attribute? I've done much the same thing above with SVNRepository element, by moving it to be a rdf:type attribute declaration. The SVNRepository element has been replaced by an element called rdf:Description. rdf:Description is bit like a shim for RDF/XML markup - what matters is the value of its rdf:about attribute not the element itself. If you are looking at this and thinking about HTML span and div tags, you're on the right track - rdf:Description is to RDF as span is to HTML. Dropping rdf:Description in there allows me to name the repository at the cost of being slightly abstracted from the DOAP subject matter. At this point if you believe what Adam Bosworth has to say about abstractions then half of you just stopped reading and left the room.

So that's a problem. We're getting some expressive power at the cost of introducing an abstraction, which you can argue defeats the design goals of the DOAP format to begin with.

Thankfully, there is another design option we can take, to get some of you back in the room, maybe even half of you back. Danny Ayers and Julien Couvreur showed me how to patch the DOAP markup so that we don't need rdf:Description abstraction. We can add an rdf:about attribute to the doap:SVNRepository like so:

  <doap:Project 
    xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
    xmlns:doap="http://usefulinc.com/ns/doap#"
    xmlns:ext="http://example.org/doap/plusplus/"
    rdf:about="http://example.org/projects/blah/">
    <doap:name>blah blah</doap:name>
    <doap:repository >
      <doap:SVNRepository 
         rdf:about="http://example.org/projects/blah/svn/">
	<doap:location rdf:resource="http://example.org/svn/blah/"/>
      	<doap:browse rdf:resource="http://example.org/svn/blah/"/>
      	<ext:alias rdf:resource="http://example.org/svn/waffle/"/>
      	<ext:commit-feed rdf:resource="http://example.org/feed/svn/blah.xml"/>
      </doap:SVNRepository>
    </doap:repository>
  </doap:Project>
That preserves the DOAP XML markup while allowing us to call out the name of the repository as "http://example.org/projects/blah/svn/". Less abstraction, but the same expressive power, and more consistent with the format.

What's interesting is that this technique of sprinkling rdf:about attributes on XML is that it's the same approach to when we mark up bits of HTML using class or cite attributes, where the attributes are being used to do some classification. The proper way to do this these days for XHTML and RSS is to use the rel attribute and not class/cite. For example rel attributes are an used as an extension mechanism in Atom and RSS. Sometimes this is called semantic markup. The idea is the same, the difference will be technologies you're going to leverage.

Anyway, here's the final sheet:

rdf-excel3.GIF

No more genid things - that's a good result, at an estimated cost of 25% of the intended audience.

Is this a good tradeoff? I think for most cases Edd's initial design + rdf:about beats the rdf:Description idea out easily - the benefits of easy processing and clear markup carry a lot of weight - every popular XML format on the web can be presented in evidence.

For the specific imaginary web service and the not-unjustified fear of wanting to get a decent handle on the repositories, using rdf:about is the next step on the ladder - not having identifiers gets more problematic as you add more unamed things (like when we have 3 repositories for that project). Naming things seems to be a web best practice for metadata as well as with the REST style of web design. Plus we can always hack the webservice to drop the rdf:Description in favour of emitting doap:SVNRepository elements for producing representations.

An aside. DOAP doesn't require that these rdf:about attributes have to be there for either Repositories or Projects. Their use is optional, without the cost of interoperability issues that normally comes with optionality. That's handy if you don't have names for these things or don't care too much about naming for the time being. However I hope the examples here have convinced you of the value of adding one to doap:Project. A good number of projects can probably get away with just using their doap:homepages URLs as the identifier of the project.

Is this a flaw in DOAP? It turns out that's not a tough call to make, and the answer is no. There's no design flaw - DOAP, as Edd laid it out shows a tradeoff - where you get extension heavy lifting from RDF, XML toolkit friendliness, and good levels of document comprehension, with minimal cluttering from RDF. As of the time of writing, 2005, DOAP as it stands is good, for two reasons

  1. You can add these rdf:about attributes without breaking anything; there's no need to assemble a working group for DOAP2 and months of handwringing about forwards and backwards compatibility.
  2. The DOAP format makes it easy to work with regular XML tools, which can't be said of RDF/XML in general.

The latter is especially important. As I said, we all espouse to the idea of extensible formats, but what we can do today with the format matters a heck of a lot. This:

  <doap:Project 
    xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
    xmlns:doap="http://usefulinc.com/ns/doap#"
    xmlns:ext="http://example.org/doap/plusplus/"
    rdf:about="http://example.org/projects/blah/">
    <doap:name>blah blah</doap:name>
    <doap:repository >
      <doap:SVNRepository>
        <doap:location rdf:resource="http://example.org/svn/blah/"/>
        <doap:browse rdf:resource="http://example.org/svn/blah/"/>
        <ext:alias rdf:resource="http://example.org/svn/waffle/"/>
        <ext:commit-feed rdf:resource="http://example.org/feed/svn/blah.xml"/>
      </doap:SVNRepository>
    </doap:repository>
    <doap:mailing-list rdf:resource="http://example.org/mailman/listinfo/blah-dev"/>
  </doap:Project>

is going to be a lot easier to send through something like XSLT or a DOM-based script than these pair:

  <doap:Project 
    xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
    xmlns:doap="http://usefulinc.com/ns/doap#"
    xmlns:ext="http://example.org/doap/plusplus/"
    rdf:about="http://example.org/projects/blah/">
    <doap:name>blah blah</doap:name>
    <doap:repository >
      <doap:SVNRepository>
        <doap:location rdf:resource="http://example.org/svn/blah/"/>
        <doap:browse rdf:resource="http://example.org/svn/blah/"/>
        <ext:alias rdf:resource="http://example.org/svn/waffle/"/>
        <ext:commit-feed rdf:resource="http://example.org/feed/svn/blah.xml"/>
      </doap:SVNRepository>
    </doap:repository>
  </doap:Project>
<rdf:Description 
    xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
    xmlns:doap="http://usefulinc.com/ns/doap#" 
    rdf:about="http://example.org/projects/blah/">
  <doap:mailing-list rdf:resource="http://example.org/mailman/listinfo/blah-dev"/>
</rdf:Description>

You could present a unified document by wrapping those two inside rdf:RDF like this:

<rdf:RDF 
    xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
    xmlns:doap="http://usefulinc.com/ns/doap#"
    xmlns:ext="http://example.org/doap/plusplus/">
    <doap:Project 
    rdf:about="http://example.org/projects/blah/">
      <doap:name>blah blah</doap:name>
      <doap:repository >
      <doap:SVNRepository>
      <doap:location rdf:resource="http://example.org/svn/blah/"/>
        <doap:browse rdf:resource="http://example.org/svn/blah/"/>
        <ext:alias rdf:resource="http://example.org/svn/waffle/"/>
        <ext:commit-feed rdf:resource="http://example.org/feed/svn/blah.xml"/>
      </doap:SVNRepository>
      </doap:repository>
    </doap:Project>
  <rdf:Description 
    xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
    xmlns:doap="http://usefulinc.com/ns/doap#" 
    rdf:about="http://example.org/projects/blah/">
    <doap:mailing-list rdf:resource="http://example.org/mailman/listinfo/blah-dev"/>
  </rdf:Description>
</rdf:RDF>

but this gets hard to manipulate in a general way (suppose we have lots of other rdf:Description blocks). I for one, wouldn't want to be writing or maintaining the XSLT to suck HTML tables out of that as the data accretes. This is partly because XML is document based, so the tools assume everything you'll need will be laid out under the root element and will be related structurally as child elements and so on. Which is a perfectly good assumption as I see it. RDF is not like that; the relationships are found in the RDF abstraction not necessarily in syntactic XML structures. In this case it appears silo abstraction comes at a price. Unless you're going to use some kind of RDF preprocessor to create a unified document, what makes RDF so flexible can be a pain in the ass to script against. This is one reason why we hear that RDF/XML is not easy to manipulate with XML tools- another reason is that there are a lot of different ways that DOAP could be rendered into RDF/XML. RDF/XML reflects the flexibility of RDF directly by providing too many markup options.

When you see the kinds of numbers spent on getting IT and software to work, it's clear we do have to make things simpler. Approaches like DOAP with a few minor tweaks are about as simple as you get if you want to pass on the heavy lifting of things like naming, extensiblity and structured metadata to RDF.

In this space - shared metadata - how and where to trade off are questions we'll continue to ask. In the case I talked about here, over time I think we'll move towards rdf:Description, or something like it, but not today. And remember a lot this comes down to understanding how people are working today - if the next version of RDF/XML used something called rdf:span instead of rdf:Description we might be able to hold onto more of that intended audience.


May 15, 2005 12:44 PM

Comments

Julien
(May 15, 2005 11:24 PM #)

I'm no expert at RDF/XML, but wouldn't it be possible to put an rdf:about attribute on the doap:SVNRepository element? Or an "rdf:identifier"?

It seems the problem is that you need to use a generic element (Description) to get that feature (identification of the node), because the more specific one (SVNRepository) doesn't support it. Is there a reason why SVNRepository can't be tagged with an ID/URI?

Michael Koziarski
(May 16, 2005 07:58 AM #)

Wow, that was a *great* article Bill. My RDF knowledge is non-existant, but I'm beginning to think that there just may be something to this thing.

Do you have any resources you recommend for people who want more?

Danny
(May 16, 2005 10:50 AM #)

Nice one Bill. The triples in Excel made me chuckle. But what Julien said..?

Bill de hra
(May 16, 2005 11:49 AM #)

"..why SVNRepository can't be tagged with an ID/URI"

I had a few attempts at this, using rdf:nodeID, rdf:about and rdf:resource. I either ended up getting the parser to short-circuit the child elements of SVNRepository or drop the repository details off the graph altogether - rdf:Desc is what ended up working. There might be an idiom/approach I don't know about, or I could just be off by one on the striping. I'll follow up with some examples of what I did later.

Julien Boyreau
(May 16, 2005 03:31 PM #)

Quite interesting article about meta-data sharing...
For me, the Number One problem of RDF today is the lack of a simple design to Globally identify URI "Creation".

The "mental" binding of RDF to XML tend to prefer XML Namespaces ; but these ones are Document-oriented structure, tree-based, not adapted to graph-based decentralised RDF edition.

One of the possibility would be to form URN based on "Who created it" : for example to spread the convention for people to prefix all their created Resources with "urn:hash(email):" ;
With this you will kill one of the flaw (prevent two people to give the same URI to two different concepts) and can resolve more easily by "inference" the second problem (if two people give two different URI to the same concept)...

Alpa
(April 24, 2007 09:54 AM #)

Hi Bill,

You have a very cool blog here…loved the content.
U know there is an awesome opportunity for people like you who have ur own blogs n sites…I came across this site called Myndnet.com…it’s a platform for people to buy and sell IT related information. and everytime you sell some information you get paid for it…Good money for people like us in the IT domain. Here the link http://www.myndnet.com/login.jsp?referral=alpa83&channel=al452

Sign up is free…check it out…
You can contact me at my id here for more questions : barot.alpa@gmail.com

Cheers
Alpa

Post a comment

(you may use HTML tags for style)




Remember Me?

Trackback Pings

TrackBack URL for this entry:
http://www.dehora.net/mt/mt-tb.cgi/1567

Listed below are links to weblogs that reference Trading off:

» Extending DOAP from Raw
A fine post from Bill de hÓra: Trading off on XML, RDF extensibility etc. looking at a practical issue with DOAP. Worth looking at if only for the triples in Excel ;-) As one of the commentators pointed out, I think he’s overlooked an option: ... [Read More]

Tracked on May 16, 2005 11:01 AM

» SDLs Continued: Finding the Value Proposition in Describing Web Services from Dion Hinchcliffe's Blog - Musings and Ruminations on Building Great Systems
TITLE: SDLs Continued: Finding the Value Proposition in Describing Web Services URL: http://hinchcliffe.org/archive/2005/05/16/231.aspx IP: 216.177.77.9 BLOG NAME: Dion Hinchcliffe's Blog - Musings and Ruminations on Building Great Systems DATE: 05/16/2005 03:53:42 PM [Read More]

Tracked on May 16, 2005 03:53 PM

» SDLs Continued: Finding the Value Proposition in Describing Web Services from Dion Hinchcliffe's Blog - Musings and Ruminations on Building Great Systems
TITLE: SDLs Continued: Finding the Value Proposition in Describing Web Services URL: http://hinchcliffe.org/archive/0001/01/01/231.aspx IP: 216.177.77.9 BLOG NAME: Dion Hinchcliffe's Blog - Musings and Ruminations on Building Great Systems DATE: 05/16/2005 03:57:09 PM [Read More]

Tracked on May 16, 2005 03:57 PM