On 4/3/12 1:46 PM, David Booth wrote:
Hi Kingsley,On Sat, 2012-03-31 at 16:51 -0400, Kingsley Idehen wrote: [ . . . ]'definition' doesn't work, ultimately. This discourse domain (AWWW and Web lore in general) is already littered with literature that's uses 'description' where you seek to replace with 'definition'.That's fine. None of that has to change. The important thing is to understand the distinction between the two notions. It doesn't matter so much what we call them, though for the moment I'll continue to call them 'description' and 'definition'.
Okay.
The only difference between a definition and a description (as I am using these terms) is that a definition has been specially designated to be a definition.
Yes, and a good example of that is what you get from the content of RDFS and OWL resources.
I.e., a definition is merely a description that someone has blessed as being a definition.
Maybe, but sometimes it is also a precise domain (e.g. knowledgebase TBox) specific description.
This sets an expectation that if the URI is used in a statement, it should be used in a way that is consistent with the definition.
Yes.
The same is not true of what I am calling a description.
Yes, in the sense that 'description' is much looser.
Anybody can write a description, and it can say anything.
Yes.
There is no expectation that you should *agree* with that description when you use the URI to make statements. As Dan Connolly put it in "A Pragmatic Theory of Reference for the Web": http://www.w3.org/2006/04/irw65/urisym 1. To mint a term in the community, choose a URI of the form doc#id and publish at doc some information that motivates others to use the term in a manner that is consistent with your intended meaning(s). 2. Use of a URI of the form. doc#id implies agreement to information published at doc. This use of URI definitions helps to anchor the "meaning" of the URI, so that it does not drift uncontrollably.
Yes, but today, that's the dominant pattern for OWL and RDFS resources.
This is often a benefit, but not always. In some cases a URI owner may *want* the "meaning" of a URI to drift and evolve according to community usage. That's fine, and that can be done by providing an empty URI definition. But in other cases the URI owner may want to offer more stability, by providing a URI definition.
But once on the Web the user really looses control. There is not such thing as real stability per se. Only when you have system faults can one at least pivot accordingly. Thus, you only get the aforementioned behavior in the context of a specific system and its associated rules.
These choices are enabled by the distinction between definition and description. If we only had descriptions (as I am using the term) then those who choose to anchor the URI's "meaning" would have no mechanism to do so.
I don't really agree with that. Basically, as per my comment about illusion of control and stability once a URI is live on the Web.
Where are the resources on the Web today that bear content with rdfs:isDefinedBy relations in the manner you suggest?There is currently very little. As I said, the distinction between a definition and a description (as I am using these terms) is not yet well established in the community.
But I have a massive number of resources in :describedby and :isDefinedBy relations. That's my point. I am talking about serious numbers here, certainly over the 100 million mark.
I can show you asignificant amount of resources that bear content with "describedby" (or similar) relations. Thus, you suggestion ultimately triggers: 1. IANA registration 2. Regeneration of existing resources. And all of the above, you still have lots of debates to follow. 'definition' is too specific and its intuition value is very low, in this context.I guess YMMV when it comes to the intuitive value of the term. We could choose a different term if people as a whole liked something else better. But the word "definition" is commonly used in other areas for this kind of role.
Remember, there is a solution to this problem, one that actually helps others appreciate the virtues of OWL:
rdfs:isDefinedBy rdfs:subPropertyOf wdrs:describedby .Our conversation doesn't contradict the semantics of the relation above. Thus, any reflection of the relation above in your suggestion goes a long way. It resolves my issue re. existing resources etc..
A URI is an Identifier. In the Web medium (or system) it can identify the location of a Web resource en route to actual content access. It can also be used to name entities from other non Web realms where de-reference resolves to a location from which description oriented content (constrained by content mime type) is accessed. For what system do you anticipate explicit URI definition being definitively useful? An ontology for Linked Data? An ontology for the Semantic Web? An ontology of the World Wide Web?Semantic web data, Linked Data, etc.David, Here is another route to solving the issue of preferred relation predicates re. wdrs:describedby and rdfs:isDefinedBy. Instead of simply requiring rdfs:isDefinedBy, why not add the following relation: rdfs:isDefinedBy rdfs:subPropertyOf wdrs:describedby .That is exactly the right idea, though there is the issue that both of these terms have already been defined in specifications. David
Yes, but this is the kind of relation that ends our argument while also showcasing virtues of the Web's dimension we are collectively trying to unveil, coherently. It resolves natural human arguments :-)
I can add the relation above to an ontology that I use for my inference context. Once in place, where you see rdfs:isDefinedBy I will have the option to see either rdfs:isDefinedBy or my preferred wdrs:describedby. All of this happens in the TBox leaving masses of existing ABox relations out in the wild unchanged. How about that? I've cc'd in the LOD mailing list as this is a great example of semantic relations delivering amicability :-)
-- Regards, Kingsley Idehen Founder& CEO OpenLink Software Company Web: http://www.openlinksw.com Personal Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca handle: @kidehen Google+ Profile: https://plus.google.com/112399767740508618350/about LinkedIn Profile: http://www.linkedin.com/in/kidehen
smime.p7s
Description: S/MIME Cryptographic Signature
