OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   RE: A certain difficulty

[ Lists Home | Date Index | Thread Index ]
  • From: Mark Birbeck <Mark.Birbeck@iedigital.net>
  • To: xml-dev@xml.org
  • Date: Sat, 26 Feb 2000 21:06:47 -0000

David Megginson wrote:
> Perhaps you're a little confused because my example was too short.
> Try a slightly longer version:

Thanks ... but I wasn't confused.

> 
>   <rdf:RDF ...>
> 
>   <ppl:Person rdf:about="http://www.people.org/a">
>     <dc:title>Jane Smith</dc:title>
>   </ppl:Person>
> 
>   <ppl:Person rdf:about="http://www.people.org/b">
>     <dc:title>John Doe</dc:title>
>   </ppl:Person>
> 
>   <megg:Jumper rdf:about="http://www.foo.com/1">
>     <dc:creator rdf:about="http://www.people.org/a"/>
>   </megg:Jumper>
> 
>   <megg:Book rdf:about="http://www.amazon.com/ids/00002">
>     <dc:creator rdf:about="http://www.people.org/b"/>
>   </megg:Book>
> 
>   </rdf:RDF>
> 
> Of course, the best class design depends on the specific domain being
> modelled, but it doesn't usually make sense to have classes like
> "Author" or "Knitter", since the same person is often both; instead,
> you have a class like "Person" (or "Entity" or "Party" or something
> like that).  When a Person appears as the creator of a Book, then the
> person is an author; when the Person appears as the creator of a
> Jumper, then the Person also happens to be a knitter.  This is
> standard OO -- nothing RDF-specific here.

I don't recognise this OO. Classes like 'Author' and 'Knitter' is nearly
always what you DO have. We've all seen the boring old introductions to
any OO tutorial with the good old "Person", "Employee", "Manager" set
up, with "Person" as the base class. A manager can manage an employee,
but that employee may in turn be either an employee or another manager.
If you put a 'managed by' property in the employee class the manager
will inherit it. Standard stuff.

Note that in this scenario a manager is an object in its own right - it
does not exist *only* in relationship with another object. I'm making
this point in relation to your statement that when a Person appears as
the creator of a Jumper they become a Knitter. We may want them to be a
Knitter (or manager, or athlete) independent of the thing that their
role implies they have relationship to. (In my last email I put this a
different way; I said that I may want to store a list of Authors,
without storing a list of Books. In your scenario, no books, no author.)

> Mark Birbeck <Mark.Birbeck@iedigital.net> writes:
> > Another problem with your example is that you're dealing 
> > with instances of the class and not the class itself. I
> > might not have any information in my database about books
> > that you have written David, but I could still use RDFS to
> > find out that you are an author. With the example you gave
> > above, I would only know that you are an author if I have a
> > book in my database.
> 
> That's really a classification problem.  If you're working in a
> problem domain where you're more interested in classification (here's
> what she is) rather than relationships (here's what she interacts
> with), then you could do something like this:
> 
>   <ppl:Person rdf:about="http://www.people.org/a">
>     <dc:title>Jane Smith</dc:title>
>     <ppl:category>knitter</ppl:category>
>     <ppl:category>author</ppl:category>
>     <ppl:category>beekeeper</ppl:category>
>   </ppl:Person>

That's one solution, but really you have just illustrated my main point
- about the distinction between instantiation and definition. I am
saying that the following is preferable to what you have just presented:

<rdf:RDF ...
 xmlns:ppl="http://ppl"
 xmlns:mb="http://mb.com/"
>
	<rdfs:Class ID="Knitter">
		<rdfs:subClassOf rdf:resource="http://ppl/Types/Person"
/>
		<rdfs:label>Knitter</rdfs:label>
		<rdfs:comment>Someone who knits</rdfs:comment>
	</rdfs:Class>

	<mb:Knitter rdf:about="http://www.people.org/a">
		<dc:title>Jane Smith</dc:title>
	</mb:Knitter>
</rdf:RDF>

because I can now augment the class Knitter - I can give it a property
that refers to Jumper objects and so on, as can you, or anyone else. If
we go back to the OO example, what I'm saying is that three classes like
Person, Manager and Employee are better than one class - Person - that
has a Type property that can be P, M, E, or some combination..

Anyway, if you want to say that Jane has more strings to her bow, then
with the RDFS approach we could do the following:

	<rdf:Description about="http://www.people.org/a">
		<rdf:type resource="http://mb.com/knitter" />
		<rdf:type resource="http://mb.com/author" />
		<rdf:type resource="http://mb.com/beekeeper" />
		<dc:title>Jane Smith</dc:title>
	</rdf:Description>

But this is very different to using multiple 'dc:category' values,
because now I can follow the reference to the class definitions and pick
up the other properties of Knitter, Author and Beekeeper, as well as
disovering what their base classes are.

But my most important point is that these are *my* statements, for my
database, or my users. If you were running a portal site just for
beekeepers you might only store:

	<mb:Beekeeper
	 rdf:about="http://www.people.org/a"
	 xmlns:mb="http://mb.com/"
	>
		<dc:title>Jane Smith</dc:title>
	</mb:Beekeeper>

> In any case, none if these is really an RDF- or DC-specific issue: you
> can model things any way you want.  The advantage of the RDF
> (bottom-up) approach is that it's possible, when you want, to
> recognize properties even when you don't know about the class, and
> that encourages us to write global, general-purpose reusable
> properties (which will probably be a good thing).

I agree that that is one use, David. But I feel that the "semantic web
hooey", as you describe it, is much more significant than it is being
credited with.

In order to save ourselves (and those we may be boring on this list)
another round, I think I may have sussed the essence of our differences.
I am saying that RDFS is important, and I believe that you are saying it
isn't (or at least, is not as important as base RDF). From what you have
described you seem to be implying that RDF is sufficient on its own
because it allows you to "recognize properties even when you don't know
about the class", whereas I'm saying I want to know about the class. In
my view though you need to be able to dynamically retrieve the
definitions that you need, whereas in your view you can do the whole
thing standalone if you need to (as in, you could process an RDF file
independent of the web if you wanted to, whereas in my scenario you
couldn't).

Is that a fair distinction?

Mark

***************************************************************************
This is xml-dev, the mailing list for XML developers.
To unsubscribe, mailto:majordomo@xml.org&BODY=unsubscribe%20xml-dev
List archives are available at http://xml.org/archives/xml-dev/threads.html
***************************************************************************




 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS