Adam R. B. Jack wrote:
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. ;-)
well, this could be said for any information you spit out, including this email, so I wouldn't worry about it that much ;-)
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'?
careful here: the fact that a system wants to try to derefernce the URI that is included in rdf:about is not a requirement. Although not een rdf:seeAlso is required to be dereferenced, there is a lot higher chance that seeAlso is dereferenced.
Anyway, rdf:about indicates the subject while rdfs:seeAlso indicates an implicit relationship.
I personally strongly dislike rdf:seeAlso for that: it doesn't state what kind of relationship you have with that URI, it's vague and semantically useless.
In general, I don't like a lot of RDFSchema and I think that OWL Light (or even a subset of that, OWL Tiny as some people call it) is a lot mroe coherent than RDFSchema, but that's just me.
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.
Easy?!? c'mon. Easy to implement so that you show something? sure. Easy to implement so that the semantic web can really happen? another story. Ask the TAG ;-)
But how can I tell you things about how it looked yesterday or last week?
exactly. As a hack, if you have a date-based URI, you can "infer" that if you have
http://blah/newsfeed/2004/03/23
then you can ask for
http://blah/newsfeed/2003/03/23
and get the news of the same day last year. But there is no guarantee that this is so.
Also,
http://blah/newsfeed
might return you the "last" feed, but then you have no idea on how to ask for a previous feed.
The RDF data access WG is supposed to solve this issue, tough, but I suspect that a clear result won't be found, it will just emerge out of de-facto useful practices.
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.
Maybe not gump itself, but Bubba or something: a web service exposing the gump metadata in a more useful way.
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.
RDF is (almost by definition) definately not targetted to humans ;-)
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?
I think the ASF *should* start to centralize these things and associate persistent URIs to projects. I can push this at the board@ level if required.
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.
Exactly. Just work on your stuff, then we draw equivalences so that external inferencing engines don't note the differences.
-- Stefano.
smime.p7s
Description: S/MIME Cryptographic Signature
