> The vocab is nice. A while back I did some work on a project vocab [1] > but spent far too much time on the terms and not enough on doing stuff > with it - got bogged down, bloat, overengineered. So I reckon just > starting with a few terms and actually *using* them is the best route > forward.
I hear that. Still, amusingly although I'd happily let Gump pump out Atom or RSS (all bet's off ;-) but I worry about pumping out RDF without a lot more thought/design. I fear that a triple could end up permenantly in some corner of some remote triple store and dork over some logic eons from now. ;-) > It could well be helpful, but I'd suggest being careful about what > statements are made involving the URI - i.e. does that resource > actually identify the project? If so a direct rdf:about to it is ok, > but otherwise a technique that's getting popular is to have an > rdfs:seeAlso to it. There's not the same level of commitment, but > automatic tools can still pick up the data. (Other statements such as > the type of the resource can also be made, but aren't necessary from > day one). Interesting. Could we have a dated URI that has a seeAlso to the non-dated one? Hmm, if we had those two is it really not an 'about'? > [[ > > 1.3) How do we define a URI to represent a long lived (yet varying) > > entity? > > eheh, great question ;-) > ]] > > Easy! My home page is http://dannyayers.com. The representations of it > (the HTML & RSS) vary a lot, but conceptually it's the same entity. But how can I tell you things about how it looked yesterday or last week? I don't think I can w/o adding that information separately (storing version in an SCM, or whatever). I feel I want Gump to do that work for others. > I'm a big fan of numerical URIs for long-term persisting things. The > less implicit semantics in the URI, the higher the chance of surviving > changes without requiring the URI to change. > ]] > > If I understand Stefano correctly, I agree - if it's worth saying, > make it explicit in some other way as additional statements, the URI > is opaque to (most) machine processing. Seems counter to the XML goal of 'human readable', but I can understand. So, we'd generate an ID for a project, and have a triple assigning it's name (which could change). Might be good for tracking projects as they mature up to TLP and such. That said, could we have two types? ID provided and free-form so we don't need to centralize this? > > doap:Project owl:equivalentClass gump:Project > Now this makes sense. They are both the same class of thing, we just have a few different views on properties (perhaps) for a while. > There is another candidate relationship, owl:sameAs, but this says > that the two individuals (in this case classes) are the same. This can > be problematic both conceptually (are you sure the classes are > *exactly* the same?) and sometimes in practice (the DL breed of > reasoners tend to choke). It's not written in stone anywhere, but > folks who generally know what they're doing (like Dan Brickley) tend > to avoid owl:sameAs for this purpose. Thanks for the heads up. > You may be able to reuse(/hijack!) some of the DOAP authoring tools. > There no reason Gump can't use the same syntax style (with equivalent > meaning to your examples): > > <Project rdf:about="http://apache.org/gump/project/xml-xerces/"; > xmlns="http://gump.apache.org/schemas/main/1.0/"; > xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"; > > > <dependsOn rdf:resource="http://apache.org/gump/project/xjavac/"/> > <dependsOn rdf:resource="http://apache.org/gump/project/bootstrap-ant/"/> > <residesWithin rdf:resource="http://apache.org/gump/repository/xml/"/> > <name>xml-xerces</name> > </Project> > > > [[ > > and how would we test/exercise it? > > you don't, you just publish your data in the best way possible and see > what happens ;-) > ]] > > Hmm, I dunno, this is one to think about. Assuming you had all the > (combined) project data in a store, what kind of questions could you > ask? What if you stuck the RDF into a reasoner and asserted project X > (defined only in DOAP) depends on project Y (defined in Gump), > presumably then X would inherit all the dependencies of Y. The > reasoner may be able to spit out X's dependencies. > Scruffy types tend to play around with this stuff in cwm [3], those > that comb their hair often opt for Protege [4]. > I like this approach, determine the questions. Stefano's license idea is on the now, mine w/ version compatibility is on historical. Hmm, dated is making my head hurt. I suspect it is time to drop that for now, and jsut focus on 'todays view'... > [1] http://purl.org/stuff/project/ > [2] http://www.w3.org/TR/swbp-n-aryRelations/ > [3] http://www.w3.org/2000/10/swap/doc/cwm.html > [4] http://protege.stanford.edu/ Thanks for these. regards Adam --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
