dajobe: as implemented in Jena, with a lot of optimisation
dajobe: It is not necessary to use some of the more sophisticated techniques suggested, due to the large amount of labelling found in RDF graphs.
dajobe: It is not necessary to use some of the more sophisticated techniques suggested, due to the large amount of labelling found in RDF graphs.
danbri_: Per previous discussion I didn't know whether to use the RDF testcase collection to do code generation, vs just have tests loop through each positive and negative test.
danbri_: I chose latter (implemented here), and now remember a previous headache: if an assertion fails, RubyUnit bails on the entire method.
danbri_: Which is kinda annoying as I've basically got one big fat test method and make a lot of assertions within it, since I'm driving everything from data files.
danbri_: Maybe I should go back to code generation? What do other folk do?
dajobe: test my C parser using perl
bitsko: in that situation, I'd catch the errors and count them, and just raise one failure for the test case
danbri_: I'm taking your advice...
danbri_: I chose latter (implemented here), and now remember a previous headache: if an assertion fails, RubyUnit bails on the entire method.
danbri_: Which is kinda annoying as I've basically got one big fat test method and make a lot of assertions within it, since I'm driving everything from data files.
danbri_: Maybe I should go back to code generation? What do other folk do?
dajobe: test my C parser using perl
bitsko: in that situation, I'd catch the errors and count them, and just raise one failure for the test case
danbri_: I'm taking your advice...
DanC: "a set of XSLT extension functions for Saxon and Xalan to provide access to RDF graphs stored in the Jena repository."
DanC: go Norm Walsh!
danbri_: Very nice!
bijan: 4Suite has an XSLT extension that gives access to the Versa RDF query/path language from within XSLT, too.
bijan: I've been wanting to build a pluggable XSLT implementation (perhaps on 4Suite or SXSLT/SXML), i.e., plug in different, domain specific path/query languages.
DanC: go Norm Walsh!
danbri_: Very nice!
bijan: 4Suite has an XSLT extension that gives access to the Versa RDF query/path language from within XSLT, too.
bijan: I've been wanting to build a pluggable XSLT implementation (perhaps on 4Suite or SXSLT/SXML), i.e., plug in different, domain specific path/query languages.
danbri_: EventCrawling can be seen as a specialisation of more generic RDF crawling. For FOAF documents, we currently have a bunch of crawlers which will traverse rdfs:seeAlso links between RDF documents.
danbri_: ie. when they find an RDF doc, they pay special attention to assertions of the form (?x rdfs:seeAlso ?y), typically putting ?y on the queue for further investigation / retrieval / parsing...
danbri_: In FOAF documents, we try to be kind to such crawlers, by mentioning the type of the thing that has the rdfs:seeAlso property, and (more experimentally) the type of the thing (document) referenced.
danbri_: This technique should extend to calendars and event crawling, quite naturally. You might write <util:Meeting><rdfs:seeAlso><rcal:VCalendar rdf:about="http://example.com/.../mycal.rdf"/>...
libby: vcalendar may not work as you can have mukltiple vcalendars in a docuiment...
DanC: I recently connected my foafwho document to my upcoming travel itineraries
danbri_: I wasn't quite sure whether vcalendar was the right thing, that's interesting to know.
danbri_: Just found Dan's home-smart.rdf doc. It has a bunch of (untyped) seeAlsos to more info about him.
danbri_: ie. when they find an RDF doc, they pay special attention to assertions of the form (?x rdfs:seeAlso ?y), typically putting ?y on the queue for further investigation / retrieval / parsing...
danbri_: In FOAF documents, we try to be kind to such crawlers, by mentioning the type of the thing that has the rdfs:seeAlso property, and (more experimentally) the type of the thing (document) referenced.
danbri_: This technique should extend to calendars and event crawling, quite naturally. You might write <util:Meeting><rdfs:seeAlso><rcal:VCalendar rdf:about="http://example.com/.../mycal.rdf"/>...
libby: vcalendar may not work as you can have mukltiple vcalendars in a docuiment...
DanC: I recently connected my foafwho document to my upcoming travel itineraries
danbri_: I wasn't quite sure whether vcalendar was the right thing, that's interesting to know.
danbri_: Just found Dan's home-smart.rdf doc. It has a bunch of (untyped) seeAlsos to more info about him.
danbri_: See agenda announcement
danbri_: Agenda: "We will spend the time collaboratively working on documentation for the project in the ESW wiki."
danbri_: See DanC's message for elaboration.
DanC: DanC attending
danbri_: DanBri attending
eikeon: eikeon
libby: libby attending
danbri_: In other news, I've an 12in Apple Powerbook G4 on order. So I'll hopefully get to play with Apple iCal app soon :)
DanC: RESOLVED: to use the wiki for meeting index. ACTION DanC
danbri_: New doc, EventDiscovery, 'How do I share and find RDF calendar documents?'
DanC: RESOLVED: to meet every other weds at 1500Z for up to 90 min thru WWW2003.
danbri_: Agenda: "We will spend the time collaboratively working on documentation for the project in the ESW wiki."
danbri_: See DanC's message for elaboration.
DanC: DanC attending
danbri_: DanBri attending
eikeon: eikeon
libby: libby attending
danbri_: In other news, I've an 12in Apple Powerbook G4 on order. So I'll hopefully get to play with Apple iCal app soon :)
DanC: RESOLVED: to use the wiki for meeting index. ACTION DanC
danbri_: New doc, EventDiscovery, 'How do I share and find RDF calendar documents?'
DanC: RESOLVED: to meet every other weds at 1500Z for up to 90 min thru WWW2003.
DanC: suppose, for the sake of meeting records, surname is an owl:FunctionalProperty
DanC: and every action owner has to be an attendee of the meeting
DanC: and suppose the attendees are [ owl:oneOf ( [:surname "Smith"] [:surname "Jones"])]
DanC: and we see ACTION: Williams.
DanC: there's an inconsistency there that OWL tools can find, yes?
DanC: I hope to do this with cwm today.
DanC: and every action owner has to be an attendee of the meeting
DanC: and suppose the attendees are [ owl:oneOf ( [:surname "Smith"] [:surname "Jones"])]
DanC: and we see ACTION: Williams.
DanC: there's an inconsistency there that OWL tools can find, yes?
DanC: I hope to do this with cwm today.
danbri_: "Bridging the worlds of NNTP clients and RSS feeds, nntp//rss is an application that will enable you to use your existing favorite NNTP newsreader to read your information channels."
danbri_: Popped up in context of discussing ways of keeping up with various interesting IRC chump'd feeds...
danbri_: Popped up in context of discussing ways of keeping up with various interesting IRC chump'd feeds...
danbri_: I want to do automated RDF query testing for my Ruby stuff. And have a design choice I'm puzzling over.
danbri_: Either I can write a script that reads the RDF manifest and does code-generation of Ruby test scripts.
danbri_: Or I can write a smarter generic test script that reads the manifest at runtime and just loops through each test, with assertions based on what it's just read.
danbri_: Previously I went the code-gen route, but now I'm not so sure. Advice welcomed...
bitsko: Reading the manifest at runtime sounds simpler
bitsko: also fewer steps for anyone who comes after to follow
danbri_: Now I've got an RDF parser more reliably integrated, I'm inclined to agree. I remember now that one issue was need to test query stuff in an environment without RDF/XML parsers
danbri_: Context: rdf query testcases work. See RubyRDF tests dir (messy) and brief explanation.
danbri_: See also Alberto's work on an improved manifest schema and Andy's draft of a resultset testing format.
danbri_: Either I can write a script that reads the RDF manifest and does code-generation of Ruby test scripts.
danbri_: Or I can write a smarter generic test script that reads the manifest at runtime and just loops through each test, with assertions based on what it's just read.
danbri_: Previously I went the code-gen route, but now I'm not so sure. Advice welcomed...
bitsko: Reading the manifest at runtime sounds simpler
bitsko: also fewer steps for anyone who comes after to follow
danbri_: Now I've got an RDF parser more reliably integrated, I'm inclined to agree. I remember now that one issue was need to test query stuff in an environment without RDF/XML parsers
danbri_: Context: rdf query testcases work. See RubyRDF tests dir (messy) and brief explanation.
danbri_: See also Alberto's work on an improved manifest schema and Andy's draft of a resultset testing format.
danbri: "(...) The role of schema registries will be considered, in particular looking at recent initiatives within the digital library world such as the DCMI registry, and SCHEMAS registry. Availability of appropriate schema creation tools is essential to complement the registration process, as will be illustrated by a demonstration of the recently developed Metadata for Education Group (MEG) schema creation and registration tool."
danbri: "In revolutions people used to say, 'keep your powder dry.' Now they say, 'keep your cellphone charged'"
danbri: The full story is on a different server.
danbri: The full story is on a different server.
danbri: Website accompanying the book. Couched in terms of mobile devices rather than the (Semantic) Web...
danbri: ...but raises questions about how the SW might transform activism.
danbri: He's very taken with the way SMS has been used to organise protests, for example.
danbri: I found that suprising, since my phone barely worked during the 15 Feb 2002 anti-war demo in London.
danbri: Orange, fwiw. All the SMS messages from that day arrived in batch, 2 days later, as I left London.
danbri: There's a detailed bibliography online too.
danbri: ...but raises questions about how the SW might transform activism.
danbri: He's very taken with the way SMS has been used to organise protests, for example.
danbri: I found that suprising, since my phone barely worked during the 15 Feb 2002 anti-war demo in London.
danbri: Orange, fwiw. All the SMS messages from that day arrived in batch, 2 days later, as I left London.
danbri: There's a detailed bibliography online too.
danbri_: I've not read the whole thread, but discussion touches on XML schema(s) for Dublin Core, 404s at namespace URIs, etc.
danbri_: "Somebody, I think it was Adam Bosworth of BEA, once said that every layer of abstraction costs you 50% of your audience. Or words to that effect."
danbri_: "... Abstraction creates a high priest environment in which only a few can ever hope to really understand the "vision" buried in all the abstraction. In the hands of the chosen few, the abstractions are a precision tool wielded to powerful effect. In the hands of the other 94%, the tool is more like a monkey wrench. A tool that can be used for every job but is the wrong tool for every job."
danbri_: "I fear that RDF - the uber-abstraction that underlies the Semantic Web - is one such monkey wrench. Given the undoubted benefits to all of us, if Tim Berners Lee's vision of the Semantic Web[2] becomes a reality, how can we make the abstractions it depends on, usable by the 94% of the world's system developers? The population for whom the abstractions are a step too far for them to comfortably follow?"
danbri_: I've had similar concerns: it's easy for something that's applicable to all tasks to be ideally suited to none of them.
danbri_: Nearby: Uche Ogbuji's reply.
bijan: I'm not finding this view of abstraction, and the argument from the costs thereof, persuasive.
bijan: As Russell pointed out, we start our understanding from "middle sized dry goods"...which are abstractions (at least, relative to fundemental particles)!
danbri_: Yup, I wouldn't couch it in terms of abstraction layers, more in terms of whether a technology is generalist vs attempts to solve a specific family of problems.
danbri_: RDF is pretty generalist, hmm but so is XML, I'm not even convincing myself here. Scrap that argument!
bijan: Not even clear about that, though that's a useful point. XML seems driven by the generalist desire.
danbri_: Quite
bijan: Reuse is, at some level of abstraction, about abstraction (or generality; these aren't equivalent).
bitsko: Uche is wrong on one very important point: there's a lot of people that get relational databases and code that don't get RDF.
bitsko: One need only look at the RDF mailing lists vs. the RSS-DEV mailing list to see the numerical difference in people who "get" RDF. Most of the RSS-DEV folk really want to "get" RDF, but don't, as evidenced by the near zero usage of RDF tools for RSS.
danbri_: I think RDF query has something to offer on that front. I realise that "we just need one more layer of facilitating technology" can (and should) ring alarm bells. But...
danbri_: ...many RDF query tools offer a reassuringly SQL-like mode of interaction. Send a textual query, get back a table of results, with a row for each 'hit'.
bijan: And, let's add the fact taht RDBMS have had, what, 30 years of effort, tool building, graduate and undergrad and industry course, etc. etc. etc.
bijan: And loads of folks STILL don't get it!
danbri_: "... Abstraction creates a high priest environment in which only a few can ever hope to really understand the "vision" buried in all the abstraction. In the hands of the chosen few, the abstractions are a precision tool wielded to powerful effect. In the hands of the other 94%, the tool is more like a monkey wrench. A tool that can be used for every job but is the wrong tool for every job."
danbri_: "I fear that RDF - the uber-abstraction that underlies the Semantic Web - is one such monkey wrench. Given the undoubted benefits to all of us, if Tim Berners Lee's vision of the Semantic Web[2] becomes a reality, how can we make the abstractions it depends on, usable by the 94% of the world's system developers? The population for whom the abstractions are a step too far for them to comfortably follow?"
danbri_: I've had similar concerns: it's easy for something that's applicable to all tasks to be ideally suited to none of them.
danbri_: Nearby: Uche Ogbuji's reply.
bijan: I'm not finding this view of abstraction, and the argument from the costs thereof, persuasive.
bijan: As Russell pointed out, we start our understanding from "middle sized dry goods"...which are abstractions (at least, relative to fundemental particles)!
danbri_: Yup, I wouldn't couch it in terms of abstraction layers, more in terms of whether a technology is generalist vs attempts to solve a specific family of problems.
danbri_: RDF is pretty generalist, hmm but so is XML, I'm not even convincing myself here. Scrap that argument!
bijan: Not even clear about that, though that's a useful point. XML seems driven by the generalist desire.
danbri_: Quite
bijan: Reuse is, at some level of abstraction, about abstraction (or generality; these aren't equivalent).
bitsko: Uche is wrong on one very important point: there's a lot of people that get relational databases and code that don't get RDF.
bitsko: One need only look at the RDF mailing lists vs. the RSS-DEV mailing list to see the numerical difference in people who "get" RDF. Most of the RSS-DEV folk really want to "get" RDF, but don't, as evidenced by the near zero usage of RDF tools for RSS.
danbri_: I think RDF query has something to offer on that front. I realise that "we just need one more layer of facilitating technology" can (and should) ring alarm bells. But...
danbri_: ...many RDF query tools offer a reassuringly SQL-like mode of interaction. Send a textual query, get back a table of results, with a row for each 'hit'.
bijan: And, let's add the fact taht RDBMS have had, what, 30 years of effort, tool building, graduate and undergrad and industry course, etc. etc. etc.
bijan: And loads of folks STILL don't get it!