Re: modelling issue?

On Oct 4, 2009, at 12:35 PM, Paola Di Maio wrote:

> Pat,
>
> As I said earlier, going through various replies
>
> (btw most of  the book is on googlebooks!)
>
> Semantic web for the working ontologist: modeling in RDF, RDFS and  
> OWL - Google Books Result
>
> by Dean Allemang, James A. Hendler - 2008 - Computers - 330 pages
> Semantic Web for the Working Ontologist transforms this information  
> into the practical knowledge that programmers and subject domain  
> experts need.
> books.google.co.uk/books?isbn=0123735564... -
>
>
Excellent book.

> I have come to the conclusions that although  there may be  
> conceptual modelling issues somewhere that I havent been able to put  
> my finger on yet (will work on it ), it's pretty clear that some  
> additional ambiguity emerges in the way the information is presented/ 
> discussed by different proponents (when I first came across RDF it  
> looked really straighforward, now that I try to
> work it it a bit less, and get different messages too)

Well, this may be partly caused by the various terminologies in use,  
eg RDF "property" is sometimes called a "relation" and RDFS/OWL  
"class" is sometimes (confusingly) called "property" and sometimes  
called "set".

>
> I do get different answers, which in turn point to different issues,  
> for example the interesting recent discussion on extensionality and  
> intensionality that may be possibly overlapping some of what I am  
> trying to put my fingers on
>
> http://www.semanticuniverse.com/blogs-intensional-and-extensional-sets.html
> http://www.semanticuniverse.com/blogs-intensional-and-extensional-owl.html
>
> Since you offer to districate, let me ask:
>
>
>
>
> That is the full story on domains and ranges in RDFS (and in OWL,  
> for that matter). So I'm not sure what you mean by the domain/range  
> of an *entity*.
>
> sorry that was just wrong, legacy of previous conversations
>
>
> BTW, there is no RDF requirement that domains and ranges be  
> specified. You can just say nothing about them unless you want to.
>
> I think here I was seeking for some guidance: is ther a rule/ 
> recommendation for when I should, and when I shouldnt
> or
> is there a natural way of making the choice ? (rather than just  
> leave it blank where I am not sure, which does not see right)

No, there is no actual rule. In general, its often a good idea to  
provide all information that you have available, so if indeed you know  
the domain and range then you might as well write that down. In doubt,  
it is fine to specify a more vaguely defined superclass: that is  
always harmless and might be useful.


>
>
> class:relation:class
>
>  but also
> class:attribute:value
>
> Of this i would like some confirmtion (is this right?
>
> No. Or at any rate, not if I am following you. First, the first item  
> (subject) of the triple isn't necessarily a class.
>
> okay, I have always assumed that the subject *is* a class, any hints  
> as to what are my options?
> or what chapter of the book/tutorial I can find the relevant info?

Well, there is no info because there are no constraints. The subject  
of an RDF triple can be anything. If you can refer to it using a URI,  
then it can be a subject, i.e. you can say something about it.

>
>
> Second, the terms 'relation' and 'attribute' are not used in RDF,  
> though they are both used more widely to mean what RDF calls a  
> property.
>
> yeah, well.  I am trying to match the UML and E/R view of the world  
> into RDF.

Ah, I see. You will have to ask someone else about UML, it is quite  
opaque to me.

> i understand that some plugins will convert UML into RDF or OWL, but  
> I do not want to trust machine just yet (plus I have to learn to use  
> these other tools first)
>
>
> Can you give some examples of the kind of contrast you have in mind  
> here?
>
>
> One of the working example below. See either l diagram below  
> (probably not the final version, just a working draft of it). I mean  
> I can get other people to rdfize a model, but I am trying to see  
> what barriers I hit if I do it myself by hand (exercise)
>
> http://www.w3.org/2005/Incubator/eiif/XGR-Framework-20090806/
>
> scroll down to FIG 7

Again. I am afraid that I have no sure idea what this diagram is  
supposed to mean. I will however make some guesses, based in part on  
your translation. Correct me if I am wrong.  The boxes are classes,  
with their names written in the top panel of the box. (But what are  
the other names in the second pane?) A line from one box to another  
with a blue arrowhead indicates a subclass relationship. A line with  
no arrowhead and a label indicates a relation (RDF: property) , but Im  
not sure if this holds between the classes or between the things in  
the class. Take the example of
Organization --Has -- Affiliated_Person, which is a long slightly  
curved line on the LH side of the diagram. Does this mean that things  
in the Organization class, i.e. organizations, all have an affiliated  
person who is a member of the class Affiliated_Person? Because if so,  
this is not adequately represented by a single RDF triple.

>
> So, to sum up, after realising that we can use RDF equall to triplify
>
> ORGANISATION   HAS     CONTACDETAILS
> (class)                   rel        (class)
>

This says that the HAS relationship holds between the actual classes,  
not between the elements of the classes. Is this really what you  
intend to say?

Pat

>
> but also
>
> ORGANISATION     IS        OFTYPE
>
> or
> ORGANISATION     HAS    WEBSITE
>
>
>
> is this 'versatility' of using RDF in the same way for either/both
>
> a) what is referred to as an RDF weakness?
> b) never been thought of as a problem when modelling data?
> c) related to the intensional /extensional discussion referred to as  
> above?
>
>
>
> Finally, not sure to what thread the observation pertains, that  
> developers manage to find workaround to 'non optimal'
> representation issues. Yes, we can find workarounds, but on a large  
> scale, repeated over a period of time these
> can cost massively, at some point it may be worth considering  
> addressing weaknesses to reduce the instability
> of systems that may built around our workarounds :-)
>
> And if this is just too boring for others, happy to take the rest of  
> this convesation offlist
>
> thanks in advance
>
> PDM
>
>
>
>
> ),
>

------------------------------------------------------------
IHMC                                     (850)434 8903 or (650)494 3973
40 South Alcaniz St.           (850)202 4416   office
Pensacola                            (850)202 4440   fax
FL 32502                              (850)291 0667   mobile
phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes