Re: Southampton Pub data as linked open data

On Jul 30, 2008, at 1:57 AM, Sampo Syreeni wrote:

> On 2008-07-30, Bijan Parsia wrote:
>
>> For many reasons. I.e., I would recommend this even if  
>> subpropertying rdfs:label becomes legit OWL DL.
>
> I already know that you're one of the few people who're intimate  
> with the logical details, so... Could you recap, after such an  
> extensive discussion, *why* subproperties of rdfs:label (or any  
> other property for that matter) aren't compatible with OWL DL?

The basic reason is that you want to be able to apply rdfs:label to  
classes and properties. Because it is (or looks like) a property this  
means that we have to do some work to fit into a basically standard  
first order logic framework (like OWL DL). The choice in OWL DL was  
to treat it as a kind of comment and to prevent other axiomiation of  
those properties. In OWL 2, with punning, you can subproperty  
properties that are meant to apply to classes, but even then, you end  
up contaminating your domain model with things that aren't in the  
domain. This has led to various "separate domain" approaches like my  
Rich Annotation proposal:
	http://www.w3.org/2007/OWL/wiki/Annotation_System

Is this clear enough? It's a bit late here so I'm not sure how much  
detail to supply. Please ask for more clarification if needed.

>> From what I can understand, either the relevant portion of the  
>> combined
> grammar will not be utilized in inference/rewriting, or it will and  
> the results will agree higher up the ladder. The cinch would then  
> be that there's something very special about the computational  
> realization of RDFS semantics which would kill the nice termination  
> properties of the inferencing process at the OWL DL level.
>
> If I'm right, what is it that causes said problem? Or if I'm wrong,  
> could you elaborate?

First, can I ask you what the requirements are? I mean, if the only  
think subpropertying rdfs:label does is tag properties as "for  
display" (a really useful thing!) then why use subproperty syntax (if  
there were an alternative)?

If one had complete punning (including between data and object  
properties) then one could get pretty close to the behavior people  
are doing not in RDFland in OWL DL. (Note, data and object property  
punning were removed from OWL 2 because of the effect on the RDF  
serialization at the request of self-described RDF champions.)

(There's a somewhat subtle problem with the punning approach to  
syntactic freedom, to wit, you need to be able to contexualize the  
user of URIs so you know whether you  are restricting and object or a  
data property. RDF has very few facilities for contexualization and  
none for URIs labeling nodes in the graph except coining lots of  
vocabulary.)

So, let's presume we've hurdled that technical barrier is this still  
a good idea? It's it preferable to tagging/stylesheeting? I would  
argue "no".

>> """(rdfs:comment, rdfs:seeAlso, rdfs:isDefinedBy and rdfs:label  
>> are included here because some constraints which apply to their  
>> use can be stated using rdfs:domain, rdfs:range and  
>> rdfs:subPropertyOf. Other than this, the formal semantics does not  
>> assign them any particular meanings.)"""
>
> They don't possess *formal* semantics,

They don't possess any normative, defined semantics as far as I know.

> other than those assigned to them via application of  
> rdfs:subPropertyOf and so on. So the pure formalists amongst the  
> RDF/RDFS/OWL/DAML/whatever crowd would say *just* that.

I don't know that there are any such people. I pointed to what I  
believe is the normative text. If you have some other normative text,  
please point me there.

You don't need a model theory to have well specced terms.  
owl:deprecatedClass isn't ill defined because it doesn't have a  
formal definition but because it doesn't have a *definition*: there's  
no speccing of what tools should do with it.

Consider the (informative?) text for label:
http://www.w3.org/TR/rdf-schema/#ch_label

"3.6 rdfs:label
rdfs:label is an instance of rdf:Property that may be used to provide  
a human-readable version of a resource's name.

A triple of the form:

R rdfs:label L

states that L is a human readable label for R.""

If one were being picky, one could even read the "that may be used"  
as allowing "but may be used for something else". (See the  
rdfs:subproperty text above it which uses "is" instead.)

There is a *community* meaning which is pretty good and a practice of  
using rdfs:subProperty to tag other properties with a similar  
meaning. That's worth some respect. (But that's not what Richard  
claimed. He explicitly made a spec claim.)

> That still doesn't mean said primitives possess *no* semantics at  
> *all*. Their *formal* semantics are restricted to whatever  
> derivative, inferential assertions they give rise to in combination  
> with the rest of the asserted theory, to be sure. But they *do*  
> still have their separate, hazy, intuitive, linguistic, common  
> sense meanings/semantics.

Then we can't realistically or usefully talk about "conformance".

Forget formal semantics: this just isn't useful specing. If it's all  
hazy wifty whatevery then interoperability is going to be, mildly  
speaking, a challenge.
[snip]

> I would also argue that that's why Tim would, in my mind, so much  
> like to subclass

Subproperty?

> rdfs:label for every kind of name:

Property?

> ideally a human software developer would like every kind of human  
> readable label/name to present itself automatically to him.

What? I wouldn't. My understanding of at least some of the use is to  
single out certain properties as for display. (Contrast foaf:name  
with the hashsum thingy.)

> And what then is a human readable name/label but a subtype of the  
> original, purposely included, singular RDF label "rdfs:label"?

I don't think this was the meaning per se.

> That what it was *meant* for, and the same goes for the rest of the  
> "hazy" stuff like comments...

Well, we'd have to ask folks, but it's unclear to mean that what it  
was meant for was selection of properties to display. My  
understanding it was to help with things like uris that were gensyms.  
So it provides an alternative name.

Alternative names and "show me in your display" are fairly different  
things. Is my name a human readable lable for me? (I don't think of  
it as such :))

> The real world denotations of those formal URI's are meant to  
> document and distinquish certain central, useful, human intuitions  
> about the concepts the RDF family of languages formally reasons  
> upon. If we, for some formal reason, cannot subtype them, we'd be  
> losing the logical unity of the framework, at least at the human  
> readable level. I mean, two different kinds of labels/names? In the  
> same language? What if some idiot declared both? What would I call  
> my concept *then*?!?

I've lost your point.

>>> 4. OWL people ask RDF people to stop subclassing these properties  
>>> in order to meet the restrictions imposed by OWL-DL.
>>
>> Do whatever you want.
>
> That is not a very constructive answer,

Richard's post wasn't very constructive. I'm not telling RDF people  
(including myself) to do anything. He wants to tell other people what  
to do.

> in my mind. I'd rather see a consensus on what the problem is, and  
> then a clean, mutually agreeable solution which adapts one -- or  
> more likely both -- of the standards so that these sorts of clashes  
> just cease to be. And *especially* at such a fundamental level as  
> OWL DL: that wasn't supposed to be the specification that gives us  
> the most trouble within the RDF family of formal languages. It was  
> supposed to be the easiest and most useful. Now I'm already  
> beginning to be disappointed...

I don't understand. RDF made a lot of choices that are very hard to  
accommodate. Consider the existential semantics of BNodes. That's  
just a bear. It's a bear for everyone, really. Metamodeling is really  
fairly tricky. Some of the trickiness doesn't show up until you have  
enough power for it to matter. OWL DL has enough power so feels the  
price very hard.

But I'm still confused at why you think subPropertying is the right  
way to go, so right that using another mechanism is off the table.  
What's so right about it *other* than it's what's happen to have  
happened?

Cheers,
Bijan.

Received on Wednesday, 30 July 2008 01:46:54 UTC