Re: ALL: philosophy of SWBPD (was Re: [OPEN] and/or [PORT] : a practical question)

* Pat Hayes <phayes@ihmc.us> [2004-03-26 18:41-0800]
> >[snipping to some points]
[...]
> than just keep on quarreling, let me suggest that we try to adopt 
> some criterion for giving best-practice advice. If anyone wants to 
> say that some technique or style is 'bad', let them rather phrase the 
> advice in the form 'if you use this technique or style, the following 
> consequences may arise, which could be undesireable because the 
> following could happen..' The 'following' might include: failures of 
> interoperability with other techniques or styles; dangers of 
> misunderstandings arising; failure to conform to one or more existing 
> standards (particularly ones in widespread use); inability to make 
> use of existing engines or inference techniques.  But I would suggest 
> that reasons based on philosophical opinions, or which amount to 
> little more than 'people that I know and admire have tended to always 
> do it that way' should not be offered as pest-practice advice; and 
> that in cases (which may well include the classes-as-instances issue) 
> where it seems that entire communities disagree, then we should say 
> that, and give the pros and cons in both directions.

I agree very much with this approach. It is how I encourage folks in the 
Interest Group to work too. At the Cannes meeting (sorry you weren't
there) I encouraged WG members to focus on a "real world storytelling" 
approach, even to the extent of conducting and publishing human-face 
interviews with users of semweb technology. Eg. "We tried designing
our app this way and it was great because the Xyz DL reasoner just 
worked out of the box!", "We used some constructs that put our data into
OWL Full, because we wanted to be able to ....; while this was useful,
we had to jump through various [detail here] hoops to allow DL-based 
systems to consumer our data...". I expect it will be much easier to 
explain the tradeoffs through reference to real systems that people are
building...

> What is driving me crazy is this simplistic view that one can clearly 
> distinguish 'good' and 'bad' here. Can we try to adopt a more nuanced 
> form of words, and try to avoid the (ultimately simply ridiculous) 
> posturing about being an Authority on how to write Good SW content? 
> The fact is, this has not really ever been done before by anyone, 
> including us. We are like writers of essays on literary style setting 
> out to give advice on how to write hypertext before there were any 
> web pages. A little humility might be a useful thing to wear at this 
> point.

Very well put.

> >under what criteria?  As long as we specify the  criteria set we're 
> >working against when we call something "bad" then I'm okay   - I 
> >don't think KR is completely (or, frankly speaking, even nearly) a 
> >science, and there's a tendency on our part to try to push it too 
> >hard in that direction -- but every "theory of representation" 
> >developed to date has proved to be flawed, and most of us in the 
> >field admit there's a certain "art" to getting it right -- and 
> >crticizing someone else's art is moving in a dangerous direction, 
> >esp. on the Web.
> 
> Amen.

+1

Here's an example I'm thinking through at the moment. Let's perhaps 
try to work through what style of best practice guidance we might offer regarding 
use of owl:InverseFunctionalProperty and literal-valued properties.

Some observations...

1) identifying things that don't have widely known URIs (eg. people,
companies) is a useful thing for SW apps to be able to do

2) the owl:InverseFunctionalProperty is helpful in this, it allows 
apps to (sometimes!) figure out when two descriptions are describing the self-same 
thing, even when common URIs aren't used to denote those things.

3) literal-valued owl:InverseFunctionalProperties (IFPs) put us into OWL Full

4) literals are self-evidently distinct, we can tell that "MSFT" and
"APPL" are different things. With URIs, by contrast, we must allow that 
http://example.com/corpid#MSFT and http://example.com/corpid#APPL could 
(unless we're told otherwise) potentially denote the selfsame thing.

5) if we write <Company><stockTicker>MSFT</stockTicker></Company> and
claim 'stockTicker' as an IFP, we make certain kinds of (DL-oriented) 
reasoning harder.

5) if we write <Company><stockTicker2 
  rdf:resource="http://example.com/corpid#MSFT"/></Company> and claim 
  'stockTicker2' as an IFP, we make certain kinds of (identity-oriented)
  reasoning harder. 
  Specifically, we couldn't tell without further evidence that 
  <Company><stockTicker2
    rdf:resource="http://example.com/corpid#APPL"/></Company> was 
  a different company. (we'd also need to assert the property was
  functional, which seems reasonable since it is, at least if we 
  specify that these are nasdaq codes)


Unless I'm missing something, this seems to me to be a clear case of 
'no right answer', only tradeoffs, tools, perspectives. If someone 
comes to the WG and says, "help, I am designing an 
RDF property that relates companies to their (uniquely identifying) 
stockticker codes, and am unsure whether to use literals or URIs to 
encode the stockticker codes...", what Best Practice advice might we
offer?

BTW, what should I do? (1/2 ;)

Dan

Received on Saturday, 27 March 2004 03:57:29 UTC