Hello!
The comments on this profile are unclaimed and thus are unverified.
Do they belong to you? Claim these comments.
Bijan Parsia
Is this you? Claim Profile »
9 months ago
in Managing XACML Policies: A DL Perspective on Thinking Clearly
If I write a test which says:
SHOULDFAIL: Student writes ownGrade
I feel pretty confident that the intent was to test that no student should be able to write their own grades. As you say, this test *is* the second description.
Now, I might have gotten the second description wrong! There might be exceptions when students are allowed to write their own grades (but really? c'mon!). Deep testing will *show me* those exceptions. To make this test *right* then I can incorporate those exceptions into my test i.e.
SHOULDFAIL: Student writes ownGrade UNLESS their parents are rich doners
You can think of it from a query perspective too. "Are there any circumstances which, according to this policy, it would be legal for a student to write her own grade?" Which shallow query, the answer would be "no". But that's the *wrong answer*.
SHOULDFAIL: Student writes ownGrade
I feel pretty confident that the intent was to test that no student should be able to write their own grades. As you say, this test *is* the second description.
Now, I might have gotten the second description wrong! There might be exceptions when students are allowed to write their own grades (but really? c'mon!). Deep testing will *show me* those exceptions. To make this test *right* then I can incorporate those exceptions into my test i.e.
SHOULDFAIL: Student writes ownGrade UNLESS their parents are rich doners
You can think of it from a query perspective too. "Are there any circumstances which, according to this policy, it would be legal for a student to write her own grade?" Which shallow query, the answer would be "no". But that's the *wrong answer*.
11 months ago
in Managing XACML Policies: A DL Perspective on Thinking Clearly
Well, uhm, testing involves, y'know, writing some stuff that isn't, well, the original policy.
If you write a test which says "Student accessing own grade SHOULD fail" it seems pretty clear what you mean, i.e., that the student, regardless of other roles, shouldn't be able to access their own grades. Obviously, if you mean something else, you need to write something else. But exceptions seem *exceptional*, whereas in shallow testing they are *presumed good*.
Let's supposed you *do* want to allow students with parents who donate large amounts of money to be able to change their own grade. Presumably, you would want to test for that and would write the test accordingly. Then you would have, in some sense, inconsistent tests (you'd want to update the first one to say "Student who is not a richbrat writing own grade"). But this will be helped by deep testing. Suppose the original test fails. Then the system will report *all* the combination of roles that allow a student to write their own grade. If you see the richbrat exemption in the list you go, "D'oh! forgot about that. I'll rewrite my test."
As with any testing methodology, feedback should help improve the test suite. Without deep testing you could end up in the situation where you had *both* "Students can't write grade" *and* "RichBrat Students CAN write their grades" and it *also* be the case that Student TAs can write their own grades.
Deep testing can help sort this out.
If you write a test which says "Student accessing own grade SHOULD fail" it seems pretty clear what you mean, i.e., that the student, regardless of other roles, shouldn't be able to access their own grades. Obviously, if you mean something else, you need to write something else. But exceptions seem *exceptional*, whereas in shallow testing they are *presumed good*.
Let's supposed you *do* want to allow students with parents who donate large amounts of money to be able to change their own grade. Presumably, you would want to test for that and would write the test accordingly. Then you would have, in some sense, inconsistent tests (you'd want to update the first one to say "Student who is not a richbrat writing own grade"). But this will be helped by deep testing. Suppose the original test fails. Then the system will report *all* the combination of roles that allow a student to write their own grade. If you see the richbrat exemption in the list you go, "D'oh! forgot about that. I'll rewrite my test."
As with any testing methodology, feedback should help improve the test suite. Without deep testing you could end up in the situation where you had *both* "Students can't write grade" *and* "RichBrat Students CAN write their grades" and it *also* be the case that Student TAs can write their own grades.
Deep testing can help sort this out.
11 months ago
in Managing XACML Policies: A DL Perspective on Thinking Clearly
Hi Jacek,
Consider the following (fairly standard) simple example. Suppose you have two roles, Teaching Assistent (TA) and Student. You want to set access to the grades for the course as follows: A TA can read and write any grade and a student can only read their own grade. Suppose you test this, e.g., you set up a test case where the role of the requester is a student and they try to write their grade or read/write someone elses. The request, obviously, is going to fail since you have an XACML rule explicitly set up for this.
Now suppose someone is a TA and a student? If the rules combine in just the right way, their TAship will override their studentness and they'll have write access to their own grades. Of course, we could think about that and add an explicit test for that.
But we don't need too. Deep testing takes a test like "a student tries to write their own grade" and reasons out every possible situation (given the policies and background knowledge) that a student could try to write their grade.
Hope this helps. Markus and I are working on a detailed working example which will demonstrate this.
Consider the following (fairly standard) simple example. Suppose you have two roles, Teaching Assistent (TA) and Student. You want to set access to the grades for the course as follows: A TA can read and write any grade and a student can only read their own grade. Suppose you test this, e.g., you set up a test case where the role of the requester is a student and they try to write their grade or read/write someone elses. The request, obviously, is going to fail since you have an XACML rule explicitly set up for this.
Now suppose someone is a TA and a student? If the rules combine in just the right way, their TAship will override their studentness and they'll have write access to their own grades. Of course, we could think about that and add an explicit test for that.
But we don't need too. Deep testing takes a test like "a student tries to write their own grade" and reasons out every possible situation (given the policies and background knowledge) that a student could try to write their grade.
Hope this helps. Markus and I are working on a detailed working example which will demonstrate this.
11 months ago
in “Major-league bullshit” on Thinking Clearly
I'm pretty sure I mean this as being about *you*!
1 year ago
in Architectural Arguments on Thinking Clearly
Oh, about "agreed to". I just meant that it's unclear whether it really reflects global consensus de jure. What organizations say, even in their public voice, and what they actually mean can come apart. If we buy "rough consensus and running code" then formal consensus may be less important that field consensus. So, I didn't mean that people weren't involved with a spec process and agreed to it. I just meant that that might not reflect existing consensus. That seems uncontroversial, so I apologize for the confusion.
1 year ago
in Architectural Arguments on Thinking Clearly
Roy, I'm well aware of your background. I taught web architecture to MSc students last year and used your dissertation in my class (albeit critically).
I never said you needed to repeat your background. I just pointed out that your message conflated spec structure and system architecture and made no technical point. No more, no less. That still seems true.
(Your last paragraph is, indeed, technical. But it's a proposal, not a justification of that proposal. And it's hard to see how that proposal is justified by your architectural claims.)
Of course, I don't believe the web has an architecture, certainly not a prescriptive one. So we're going to be at odds from the start, since things like "TAG consensus" doesn't have evidentiary weight for me. Thus the fact of that consensus is also irrelevant.
You slide even in this message from spec considerations (orthogonal things deserve orthogonal specs) to system considerations (HTML is one data format). It's perfectly possible to have an orthogonal system architecture speced non-orthogonally without violating that system's orthogonality. It may be risky (because hard to manage), but it's certainly possible and logically independent.
Ian indeed asked for things to be specced orthogonally and was refused. This is why things ended up this way. But all this has been pretty clearly explained on list.
Clearly, further discussion in this vein would be useless. One thing that might be useful is for us to change dialectical roles, i.e., you argue my part and I argue yours.
I never said you needed to repeat your background. I just pointed out that your message conflated spec structure and system architecture and made no technical point. No more, no less. That still seems true.
(Your last paragraph is, indeed, technical. But it's a proposal, not a justification of that proposal. And it's hard to see how that proposal is justified by your architectural claims.)
Of course, I don't believe the web has an architecture, certainly not a prescriptive one. So we're going to be at odds from the start, since things like "TAG consensus" doesn't have evidentiary weight for me. Thus the fact of that consensus is also irrelevant.
You slide even in this message from spec considerations (orthogonal things deserve orthogonal specs) to system considerations (HTML is one data format). It's perfectly possible to have an orthogonal system architecture speced non-orthogonally without violating that system's orthogonality. It may be risky (because hard to manage), but it's certainly possible and logically independent.
Ian indeed asked for things to be specced orthogonally and was refused. This is why things ended up this way. But all this has been pretty clearly explained on list.
Clearly, further discussion in this vein would be useless. One thing that might be useful is for us to change dialectical roles, i.e., you argue my part and I argue yours.
1 year ago
in Command Line Renaissance on Thinking Clearly
C'mon! Only people easily beaten by 5 year olds are into cmd lines!
How do I crush those attacking 5 year olds? I make them *GUI*.
Where as you, clearly, Can't Live Intensely (CLI) enough to beat up small children effectively! :)
How do I crush those attacking 5 year olds? I make them *GUI*.
Where as you, clearly, Can't Live Intensely (CLI) enough to beat up small children effectively! :)
1 year ago
in Command Line Renaissance on Thinking Clearly
Have I mentioned lately that this is conclusive evidence that you're a freak! ;)
No wonder 5 year olds find you easy meat.
No wonder 5 year olds find you easy meat.
1 year ago
in No Publication Without Evaluation on Thinking Clearly
I clearly talk only to myself ;)
1 year ago
in New jSpace App: Baseball Stats Browser on Thinking Clearly
Ahem. I'm not a baseball fan! And I live in the UK where "the" national pastime is either football (the kicky kind) or cricket!
Bloody Americans with their Americancentric sports imperialism!
Hint! It's not a world series if only Yank-city hosted teams compete!
Besides, I thought everyone knew that baseball was like "professional" wrestling...all faked for entertainment value. How else to explain the Yankees?
Bloody Americans with their Americancentric sports imperialism!
Hint! It's not a world series if only Yank-city hosted teams compete!
Besides, I thought everyone knew that baseball was like "professional" wrestling...all faked for entertainment value. How else to explain the Yankees?
2 years ago
in Exhibit-ionism on Thinking Clearly
I'm aware of Fresnel (and, indeed, we use it in JSpace.
My point is completely distinct from RDF. My point is that there is a lot of Javascript + CSS out there that make many sites way more usable (for certainly classes of users, including me!), but I wish more of these interactive features were available without having to use an idiosyncratic implementation of them in a full fledged, but inconsistently implemented, programming language.
Javascript programmers have done amazing things (just see OAT), but I like web pages to be safer than they are and still usable. Some things are easy to roll in (toggling visibility of text...that should be built in; footnotes; lots of widgets). They would be easier to use as well (though the best Javascript libraries do a pretty good job of making widgets plug and go).
Finally, none of the Fresnel implementations have one of the most charming features of Exhibit: working in standalone pages. It's obviously not impossible to make one up, but doing it straight from RDF would probably be pretty painful. Something Fresnelish tuned for Exhibit databases would certainly be easier to get going, I'd imagine.
My point is completely distinct from RDF. My point is that there is a lot of Javascript + CSS out there that make many sites way more usable (for certainly classes of users, including me!), but I wish more of these interactive features were available without having to use an idiosyncratic implementation of them in a full fledged, but inconsistently implemented, programming language.
Javascript programmers have done amazing things (just see OAT), but I like web pages to be safer than they are and still usable. Some things are easy to roll in (toggling visibility of text...that should be built in; footnotes; lots of widgets). They would be easier to use as well (though the best Javascript libraries do a pretty good job of making widgets plug and go).
Finally, none of the Fresnel implementations have one of the most charming features of Exhibit: working in standalone pages. It's obviously not impossible to make one up, but doing it straight from RDF would probably be pretty painful. Something Fresnelish tuned for Exhibit databases would certainly be easier to get going, I'd imagine.
2 years ago
in Exhibit-ionism on Thinking Clearly
I didn't know about that site. It looks handy.
I might try the experiment of extracting stuff via this RDFization. Though, the XSLT is pretty trivial and has done the job.
I might try the experiment of extracting stuff via this RDFization. Though, the XSLT is pretty trivial and has done the job.
2 years ago
in XFN vs. FOAF on Thinking Clearly
No, I mean the FOAF empire as in FOAF per se. FOAF files, FOAF tools, etc. etc. Even the canonical FOAF spec. I don't see a link on the FOAF project site to any of these things. Perhaps someone should update the FOAF wiki page on extensions? And why is that on the developers page instead of also on the user oriented pages?
RELATIONSHIP seems like it would be a reasonable canonical extension....except "ambivelentOf"? Yick.
(FOAF-a-matic is still oriented toward a separate FOAF file rather than generating useful web pages.)
RELATIONSHIP seems like it would be a reasonable canonical extension....except "ambivelentOf"? Yick.
(FOAF-a-matic is still oriented toward a separate FOAF file rather than generating useful web pages.)
2 years ago
in DabbleDB vs. Exhibit on Thinking Clearly
dfhuynh, DabbleDB seems to be (still) in rapid change mode, so no worries.
I was able to take the tab delimited output of Exhibit and pop it into DabbleDB with ease. Yay. Tab delim rocks! (though the typing is a bit weird...value typing so one could more easily pass, e.g., dates around would be nice)
I don't know how illuminating that survey would be. I only recently updated my web page (really set up my web page) at Manchester. My CV is perennially out of date. I hate it when, e.g., ISWC forces me to drum up some metadata for a paper I submit. Hate it!
Yet, I would like high quality Bibtex for every paper I find. Citeseer's is icky (but I use it!) DBLP is nicer (but has some usability issues...those cite keys).
There are lots of little barriers to doing stuff.
OTOH, I now intend to use Exhibit for my pubs (and other aspects of my home page). I was planning to do something neat with Javascript and the HTML, but why build from scratch?
I was able to take the tab delimited output of Exhibit and pop it into DabbleDB with ease. Yay. Tab delim rocks! (though the typing is a bit weird...value typing so one could more easily pass, e.g., dates around would be nice)
I don't know how illuminating that survey would be. I only recently updated my web page (really set up my web page) at Manchester. My CV is perennially out of date. I hate it when, e.g., ISWC forces me to drum up some metadata for a paper I submit. Hate it!
Yet, I would like high quality Bibtex for every paper I find. Citeseer's is icky (but I use it!) DBLP is nicer (but has some usability issues...those cite keys).
There are lots of little barriers to doing stuff.
OTOH, I now intend to use Exhibit for my pubs (and other aspects of my home page). I was planning to do something neat with Javascript and the HTML, but why build from scratch?
2 years ago
in DabbleDB vs. Exhibit on Thinking Clearly
Thanks for the comments. I updated the main post with a correction about RDF/XML export.
David, you can extend DabbleDB in a variety of ways (and, really, do you need the translators built in, per se?). In particular, you can create a plugin hosted on your site that DabbleDB will call out to. This is definitely weirder and less flexible than Exhibit, but also seems pretty workable for a class of extensions.
David, you can extend DabbleDB in a variety of ways (and, really, do you need the translators built in, per se?). In particular, you can create a plugin hosted on your site that DabbleDB will call out to. This is definitely weirder and less flexible than Exhibit, but also seems pretty workable for a class of extensions.
2 years ago
in 5 Best Semantic Web Tools on Thinking Clearly
zzpaul,
You might look at some of the demo demo movies which, while quite old, should give you some idea.
Cheers,
Bijan.
You might look at some of the demo demo movies which, while quite old, should give you some idea.
Cheers,
Bijan.
2 years ago
in Snow, SPARQL, and SoemthingElseThatBeginsWithS on Thinking Clearly
So, I heard. Our snow disappeared almost as soon as it happen. Sigh.
Re: What DAWG Does. Sure, clearly it's not something for the group at this time, but either a member submission or a WG submission isn't a bad idea. After all, they'll be in CR at some point soon (we all hope :)), and even a rec track for such a thing wouldn't be too hard given its parasitic nature.
On the other hand, I don't know it needs to be a rec, or any other W3C document, rather than a nice spec.
Re: What DAWG Does. Sure, clearly it's not something for the group at this time, but either a member submission or a WG submission isn't a bad idea. After all, they'll be in CR at some point soon (we all hope :)), and even a rec track for such a thing wouldn't be too hard given its parasitic nature.
On the other hand, I don't know it needs to be a rec, or any other W3C document, rather than a nice spec.
2 years ago
in Witchly interlude: SPASSing out on Thinking Clearly
I'll be using a ground semantic calculus, since that's what's most commonly used in DL reasoners. I suppose I could do a free variable one as well, which will pop in unification.
RETE and LP (by which I presume you mean logic programming) don't most naturally conflate in my lexicon. The bog standard framework for LP is resolution, from Prolog and Datalog to disjunctive datalog and answer set programming.
But the most natural metric would be performance, I would think :)
And do you mean "optimizations" by "heuristics"? Many optimizations are not heuristic, at least not in how I understand "heuristic".
RETE and LP (by which I presume you mean logic programming) don't most naturally conflate in my lexicon. The bog standard framework for LP is resolution, from Prolog and Datalog to disjunctive datalog and answer set programming.
But the most natural metric would be performance, I would think :)
And do you mean "optimizations" by "heuristics"? Many optimizations are not heuristic, at least not in how I understand "heuristic".
2 years ago
in OWLED 2006 is Here on Thinking Clearly
Danny,
I'm glad to finally see a concrete question. Putting aside whether I agree that this is a criterion for "non-web breakage", I can answer this:
"Yes". Consistency is fairly easy to assure when dropping functionality (in a monotonic system). Now, if you drop a feature, inconsistent documents might go consistent, but that's true now. There are inconsistent RDFS documents which are consistent RDF documents.
I'm glad to finally see a concrete question. Putting aside whether I agree that this is a criterion for "non-web breakage", I can answer this:
"Yes". Consistency is fairly easy to assure when dropping functionality (in a monotonic system). Now, if you drop a feature, inconsistent documents might go consistent, but that's true now. There are inconsistent RDFS documents which are consistent RDF documents.
2 years ago
in OWLED 2006 is Here on Thinking Clearly
I see Danny is back.
RDF/XML doesn't encode all legal RDF graphs. I fail to see where OWL 1.1 is worse off.
The OWL 1.1 Mapping to RDF is considerably less mature than the rest, and we know the rest isn't yet recommendation ready yet. That's why one should have a working group. I don't see that you've even begun to build a case that there is a serious problem here.
As long as the cardinality of the sets are denumerable, you can always have a 1:1 mapping without missing any bits. So, any (denumerable) set can be mapped 1:1 to any other (denumerable) set without loss. These mappings are not necessarily useful. So, converage doesn't necessarily indicate utility.
"Moving away" requires a determination of intent. We provided a mapping document which does a fair chunk of the work and I've as much said that this is part of the WGs job, as I understand it. Of course, it's for the WG to decide exactly what it is going to do.
Finally, I find that "from the requirements of the Web" fallacy to be just that, a fallacy. There are real users with significant uses who would like additional expressivity in the Web Ontology Language. I do not see how adding that expressivity (and rationalizations) breaks any aspect of the Web. That there is significant intranet use does not mean that there is not significant Web use. And even if the features were only helpful intranetly, I fail to see why that is a problem. Intranet use can helpfully complement internet use. Just because information isn't universality available does not mean it should not be homogenuously presented. If anything, making intranet use of designed to be open protocols and formats further encourages their use and adoption, promotes the development of tools and experience, and makes transition from private to public easier.
A final technical point: If you actually read the RDF mapping you'll see that currently two features "defeat the mapping". One of those features is annotations of axioms. That is, for example, if I have an axiom:
I may want to say that that axiom was added by Bijan on May 5th. Given the standard and natural mapping of OWL to RDF, this requires making an assertion about one or more triples. The only mechanism currently available for that is reification. So it would be, in some sense, easy to add these features to the mapping, but it's questionable that it would be useful due to issues with RDF.
Again, this would be a matter for the WG to decide what it could live with. But this is hardly an unknown difficulty.
RDF/XML doesn't encode all legal RDF graphs. I fail to see where OWL 1.1 is worse off.
The OWL 1.1 Mapping to RDF is considerably less mature than the rest, and we know the rest isn't yet recommendation ready yet. That's why one should have a working group. I don't see that you've even begun to build a case that there is a serious problem here.
As long as the cardinality of the sets are denumerable, you can always have a 1:1 mapping without missing any bits. So, any (denumerable) set can be mapped 1:1 to any other (denumerable) set without loss. These mappings are not necessarily useful. So, converage doesn't necessarily indicate utility.
"Moving away" requires a determination of intent. We provided a mapping document which does a fair chunk of the work and I've as much said that this is part of the WGs job, as I understand it. Of course, it's for the WG to decide exactly what it is going to do.
Finally, I find that "from the requirements of the Web" fallacy to be just that, a fallacy. There are real users with significant uses who would like additional expressivity in the Web Ontology Language. I do not see how adding that expressivity (and rationalizations) breaks any aspect of the Web. That there is significant intranet use does not mean that there is not significant Web use. And even if the features were only helpful intranetly, I fail to see why that is a problem. Intranet use can helpfully complement internet use. Just because information isn't universality available does not mean it should not be homogenuously presented. If anything, making intranet use of designed to be open protocols and formats further encourages their use and adoption, promotes the development of tools and experience, and makes transition from private to public easier.
A final technical point: If you actually read the RDF mapping you'll see that currently two features "defeat the mapping". One of those features is annotations of axioms. That is, for example, if I have an axiom:
A rdfs:subClassOf B
I may want to say that that axiom was added by Bijan on May 5th. Given the standard and natural mapping of OWL to RDF, this requires making an assertion about one or more triples. The only mechanism currently available for that is reification. So it would be, in some sense, easy to add these features to the mapping, but it's questionable that it would be useful due to issues with RDF.
Again, this would be a matter for the WG to decide what it could live with. But this is hardly an unknown difficulty.
