danbri: "I'm speculating about what a truly Pythonic interface to RDF would look like. ..."
eikeon: ... one of the agenda items for the next rdflib meeting is to discuss this some.
eikeon: ... one of the agenda items for the next rdflib meeting is to discuss this some.
DanC: by A.M. Kuchling, for PyCon March 28, 2003
DanC: nifty!
DanC: timbl, sandro and I are giving Semantic Web Tutorial Using N3 at www2003 in budapest in may
danbri: Very nicely articulated
DanC: nifty!
DanC: timbl, sandro and I are giving Semantic Web Tutorial Using N3 at www2003 in budapest in may
danbri: Very nicely articulated
DanC: a maze of twisty specs?
DanC: vCard seems to be specified in RFC2426
DanC: entitled "vCard MIME Directory Profile"
DanC: it seems that mime directory is specified in MIME-DIR
DanC: now how does this relate to iCalendar and ldap?
DanC: DSML, directory services markup language, seems to be ldap with pointy-brackets around it, to make it java-happy. by novell.
DanC: the OpenLDAP world is big enough to have its own conferences. proceedings from SFO 2003
DanC: "The nitty-gritty details of LDAP are defined in RFC2251 "The Lightweight Directory Access Protocol (v3)" and other documents comprising the technical specification RFC3377."
DanC: --1.2. What is LDAP?
DanC: goodness... more and more syntax... RFC2252 "Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions" is full of oids and such
DanC: just what the heck is the connection between ldap and vcard? maybe just that evolution uses vcard (inside bsddb) locally but groks ldap for remote address books?
DanC: google yields RFC2739 "Calendar Attributes for vCard and LDAP" as well as Email vCard to LDAP script
DanC: wow... I just assumed vCard and ldap were based on the same modelling basis. but vCard is based on mimedir while ldap is based on ASN.1
DanC: noodling on extracting MIME-DIR and ASN.1 schema info from RFCs with perl and duct tape... frustrating that the IETF doesn't publish them in machine-readable form
DanC: hmm... a couple CategoryModellingTechnology topics are brewing here, as well as a SeedApplication around foaf and email address books.
DanC: vCard seems to be specified in RFC2426
DanC: entitled "vCard MIME Directory Profile"
DanC: it seems that mime directory is specified in MIME-DIR
DanC: now how does this relate to iCalendar and ldap?
DanC: DSML, directory services markup language, seems to be ldap with pointy-brackets around it, to make it java-happy. by novell.
DanC: the OpenLDAP world is big enough to have its own conferences. proceedings from SFO 2003
DanC: "The nitty-gritty details of LDAP are defined in RFC2251 "The Lightweight Directory Access Protocol (v3)" and other documents comprising the technical specification RFC3377."
DanC: --1.2. What is LDAP?
DanC: goodness... more and more syntax... RFC2252 "Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions" is full of oids and such
DanC: just what the heck is the connection between ldap and vcard? maybe just that evolution uses vcard (inside bsddb) locally but groks ldap for remote address books?
DanC: google yields RFC2739 "Calendar Attributes for vCard and LDAP" as well as Email vCard to LDAP script
DanC: wow... I just assumed vCard and ldap were based on the same modelling basis. but vCard is based on mimedir while ldap is based on ASN.1
DanC: noodling on extracting MIME-DIR and ASN.1 schema info from RFCs with perl and duct tape... frustrating that the IETF doesn't publish them in machine-readable form
DanC: hmm... a couple CategoryModellingTechnology topics are brewing here, as well as a SeedApplication around foaf and email address books.
dajobe: Raptor now reads the XML RSS vocab and converts to RDF and RSS1.0 vocab
danbri: Found via Map Bureau's technolgoy page.
danbri: Nearby, Notes on interpreted values vs interpretation properties.
DanC: the owl:sameAs bit is the train wreck. isn't it clear enough?
DanC: properties can be subjects of other statements.
danbri: Nearby, Notes on interpreted values vs interpretation properties.
DanC: the owl:sameAs bit is the train wreck. isn't it clear enough?
DanC: properties can be subjects of other statements.
larsbot: to be held at XML Europe 2003, 5-8 May
larsbot: still work in progress
larsbot: still work in progress
danbri: see to be under active development
danbri: "I mentioned that I was working on an RPath language, which is an XPath-like language for referring to RDF data. At first, I had implemented a very primitive version in JavaScript. Now, I've been re-implementing a better version in C++. My first goal is to create a function that will take an RPath expression and return a set of RDF resources that match it. Then, I might even be so bold as to hack the XUL template system in Mozilla to sup
danbri: "I'm not sure if adding features to XUL would be a good approach right now though. There are some existing things that need to work better, and if I was going to do development, I might be better spending time working on those. Some common wishlist items people have: editable trees, arbitrary content trees, less crashy listboxes, XUL in XML documents."
danbri: Ah, more context: " There were some folks looking into building RDFPath, an XPath-like syntax for referring to RDF data, although it hasn't had any updates for over a year. The syntax is fairly general purpose though."
danbri: "I mentioned that I was working on an RPath language, which is an XPath-like language for referring to RDF data. At first, I had implemented a very primitive version in JavaScript. Now, I've been re-implementing a better version in C++. My first goal is to create a function that will take an RPath expression and return a set of RDF resources that match it. Then, I might even be so bold as to hack the XUL template system in Mozilla to sup
danbri: "I'm not sure if adding features to XUL would be a good approach right now though. There are some existing things that need to work better, and if I was going to do development, I might be better spending time working on those. Some common wishlist items people have: editable trees, arbitrary content trees, less crashy listboxes, XUL in XML documents."
danbri: Ah, more context: " There were some folks looking into building RDFPath, an XPath-like syntax for referring to RDF data, although it hasn't had any updates for over a year. The syntax is fairly general purpose though."
DanC: very nicely put (with a few minor things I disagree with).
DanC: why haven't I seen this before?
DanC: the bit about generic browsing rings true...
DanC: and of course N-ary relationships
danbri: Yes, its a nice roundup. The bit on 'Interopability' I thought perhaps a little cheeky, stressing TMs were designed for ease of merging. RDF was too, we just layered it differently: first URIs, then later inverse-functional property classification for fancier merging. I get impression TMs started with merging rules, and came to URIs later.
danbri: Regarding n-ary and TMs, and the merging of fragmentary data... Do TMs have anything like RDF's bNodes?
danbri: Eg., if you can write: "buttered(Tom, the bread, a knife)" or "buttered(Tom, the bread, a knife, gracefully, 2003, true)"
danbri: could you encounter "buttered(Tom, the bread, a knife, gracefully, [blank1], [blank2])" ?
danbri: Are there any guarantees that fields (eg. the final 'true' in my example here) don't mean nasty things like 'negate this whole topic/assertion'?
DanC: updated VisualizingRDF w.r.t. thesis 5. Different levels of semantics