pure RDF properties

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

pure RDF properties

Paul S Prueitt


so in pure RDF a property can have only one class in its domain.

I can see this (when using the language profile pure RDF) because I tried to
put two classes , a class and its subclass, in the domain of a single
property.  A pop up told me I could not do this.




so I change the language profile...  to do this I studied for a while and
then "found" that I can do this with the preferences... but preferences
tells me something about a user name and that is all..

Do I just start over and declare that this will be OWL lite?

Is there a different "preference" that allows me to alter a pure RDF and
create a language profile that is OWL Lite?



-------------------------------------------------------------------------
To unsubscribe go to http://protege.stanford.edu/community/subscribe.html

Reply | Threaded
Open this post in threaded view
|

Re: pure RDF properties

Andrea Proli-2
Paul, pure RDF does not provide a vocabulary to define the domain and  
range of properties. In order to do that, you need to have the  
"rdfs:domain" and "rdfs:range" properties, which are part of the RDFS  
vocabulary. In RDFS, properties can have multiple classes as their domain  
as well as multiple classes as their range.

However, including both a class and one of its subclasses in the domain of  
a property would not make a lot of sense (more precisely, it would yield  
redundant information), because asserting that multiple classes are in the  
domain of property p implies that individuals described by p are instances  
of *all* of those classes. For this reason, including two classes which  
are on the same specialization hiearchy in the domain of a property is  
equivalent to  including only the most specific one.

Andrea

In data Fri, 10 Feb 2006 23:43:13 +0100, Paul S Prueitt  
<[hidden email]> ha scritto:

>
>
> so in pure RDF a property can have only one class in its domain.
>
> I can see this (when using the language profile pure RDF) because I  
> tried to
> put two classes , a class and its subclass, in the domain of a single
> property.  A pop up told me I could not do this.
>
>
>
>
> so I change the language profile...  to do this I studied for a while and
> then "found" that I can do this with the preferences... but preferences
> tells me something about a user name and that is all..
>
> Do I just start over and declare that this will be OWL lite?
>
> Is there a different "preference" that allows me to alter a pure RDF and
> create a language profile that is OWL Lite?
>
>
>
> -------------------------------------------------------------------------
> To unsubscribe go to http://protege.stanford.edu/community/subscribe.html
>


-------------------------------------------------------------------------
To unsubscribe go to http://protege.stanford.edu/community/subscribe.html

Reply | Threaded
Open this post in threaded view
|

Re: pure RDF properties

Paul S Prueitt
Andrea, you are so kind.

I see this clearly.  The domain of a property would not need to have both a
class and and subclass as the properties of the class are inherited by the
subclass.

Can I remove properties easily in a subclass?  What does this mean for the
OWL indexing - to use Alan Rector's phrase (or reasoning), if a property is
removed from a subclass?

Is this treated as an exception and would this exception generate a new RDF
triple?

{ Note that in my task to express the SOA-IM's 38 data objects as RDF or OWL
construction, I have an "entity" called "Action" with what the reference
document terms "a parent" of "Event".   Some of the attributes of Action are
not attributes of Event.   Now this woudl seem to suggest that the IM
author's use of the term "parent" is not consistant with the class -
subclass viewpoint.  So the question arises, how does one represent the
intentions of the author of the IM?  )

This is a practical problem not one of theory.  The entities of the IM are
more "objects" with "private data" than classes with subclasses and
properties.



So Next to RDFS, which includes a "vocabulary" where defintions extend the
"language" one might put OWL Lite, then OWL DL and then OWL Full?

.





-----Original Message-----
From: [hidden email]
[mailto:[hidden email]]On Behalf Of Andrea Proli
Sent: Friday, February 10, 2006 5:50 PM
To: [hidden email]
Subject: [protege-owl] Re: pure RDF properties


Paul, pure RDF does not provide a vocabulary to define the domain and
range of properties. In order to do that, you need to have the
"rdfs:domain" and "rdfs:range" properties, which are part of the RDFS
vocabulary. In RDFS, properties can have multiple classes as their domain
as well as multiple classes as their range.

However, including both a class and one of its subclasses in the domain of
a property would not make a lot of sense (more precisely, it would yield
redundant information), because asserting that multiple classes are in the
domain of property p implies that individuals described by p are instances
of *all* of those classes. For this reason, including two classes which
are on the same specialization hiearchy in the domain of a property is
equivalent to  including only the most specific one.

Andrea

In data Fri, 10 Feb 2006 23:43:13 +0100, Paul S Prueitt
<[hidden email]> ha scritto:

>
>
> so in pure RDF a property can have only one class in its domain.
>
> I can see this (when using the language profile pure RDF) because I
> tried to
> put two classes , a class and its subclass, in the domain of a single
> property.  A pop up told me I could not do this.
>
>
>
>
> so I change the language profile...  to do this I studied for a while and
> then "found" that I can do this with the preferences... but preferences
> tells me something about a user name and that is all..
>
> Do I just start over and declare that this will be OWL lite?
>
> Is there a different "preference" that allows me to alter a pure RDF and
> create a language profile that is OWL Lite?
>
>
>
> -------------------------------------------------------------------------
> To unsubscribe go to http://protege.stanford.edu/community/subscribe.html
>


-------------------------------------------------------------------------
To unsubscribe go to http://protege.stanford.edu/community/subscribe.html



-------------------------------------------------------------------------
To unsubscribe go to http://protege.stanford.edu/community/subscribe.html

Reply | Threaded
Open this post in threaded view
|

Re: pure RDF properties

Andrea Proli-2
Hi Paul,
as usual, this reply is very verbose and pedantic but it is the only way I  
am able to give an effective (I hope) explanation to what I think are the  
answers to your questions. I know someone does not like to be overwhelmed  
with words, so please, if I am saying something that you already know or  
that you find straightforward, then skip to the end and proceed backwards  
to find the motivations of my statements :-)





OK, I am not sure it is not a matter of theory, as you say. At least two  
theoretical issues are involved here: the first is monotonicity vs  
non-monotonicity, and the second is the so-called "Closed World vs Open  
World Assumption". I will first address them separately, but it will turn  
out that they actually are intertwined.


-------- CWA vs OWA ----------
Adopting the Closed World Assumption (CWA) means that, by giving a set of  
statements (an RDF document, say) S and a set of inference rules R (which  
you can think to be obtained from a set of semantic conditions), you are  
implicitly specifying a total truth-value assignment to the set of all  
possible statements P. Let's call I the set of statements that contains  
all of the statements in S plus all of the statements which can be proved  
to be true by applying inference rules in R to statements in S (formally,  
the closure of S w.r.t. R). Then, if the CWA is adopted, any document  
containing a set of statements defines a *total* function isTrue:P-->{T,F)  
such that every statement in S' is assigned the truth value "TRUE", and  
every statement in (P-S') is assigned the truth value "FALSE". There is no  
"uncertainty".

On the contrary, under the Open World Assumption (OWA), it is never the  
case that a statement is considered to be "FALSE" just because you cannot  
prove (or, as a particular case, just because you do not have explicitly  
asserted) that it is "TRUE". In order to say that, you would have to prove  
that it is actually "FALSE". A straightforward example:

ontologystream:Paul mynamespace:knowsAbout rosentheory:complexity
computerscience:Andrea mynamespace:isFriendOf ontologystream:Paul

What does this document tell? If you want to give an "a priori" answer, it  
tells the things it asserts. Not that great. Now, if we adopt the CWA,  
then we are able to conclude much more things than those it asserts: for  
example, that it is "FALSE" that "computerscience:Andrea  
mynamespace:knowsAbout rosentheory:complexity", and that it is also  
"FALSE" that "ontologystream:Paul mynamespace:isFriendOf  
computerscience:Andrea", because these statements are neither asserted nor  
inferred (we have no inference rule yet). Now, let's keep our CWA  
assumption but add some inference rule. Let's suppose that friends of a  
person know about everything that person knows about (because of  
communication, say), and that friendship is a symmetrical relationship.  
Then, you can now assign a value of "TRUE" also to statements  
"computerscience:Andrea mynamespace:knowsAbout rosentheory:complexity" and  
"ontologystream:Paul mynamespace:isFriendOf computerscience:Andrea", and  
"FALSE" to all others.

Instead, under the OWA, you can say nothing of what is neither asserted  
nor proved by inference rules: mathematically, the above isTrue function  
is not total, indeed it is undefined for (P-S').

Now, given an RDF document, it is important to recognize that while the  
choice of the inference rules is a "late binding" in the sense that  
semantic conditions are not a property of the document but rather of the  
answering engine (as I told you in a previous post), with regards to the  
OWA vs CWA issue there is an "early binding", in the sense that everything  
you write in RDF syntax *must* be seen under the OWA.






-------- Non-monotonicity vs Monotonicity ----------
I am slowly approaching your questions, please be patient. At this point,  
I need to generalize. First, let's define function  
truthValueOf:P-->{T,F,U} (where U stands for "UNKNOWN") as:

truthValueOf(s) = "U" if isTrue is not defined on s,
truthValueOf(s) = isTrue(s) otherwise

And let's introduce the monotonicity issue. Suppose to have two sets of  
RDF statements (i.e. RDF documents) T1 and T2, T1 being a subset of T2,  
and denote function truthValueOf for document T1 as tv1, and function  
truthValueOf for document T2 as tv2. Then, you have a *monotonic* logic  
whenever

for all statements t, (not(tv1(t)=tv2(t)))->(tv1(t)=U),

that is, whenever adding statements *does not change* the truth value of  
any statement which was already known to be "TRUE" or "FALSE", but can  
change the truth value of statements that was "UNKNOWN" to either "TRUE"  
or "FALSE". In other words, adding information only reinforces your  
certainties.

Viceversa, in a non-monotonic environment this not always occurs: in such  
a setting, in fact, adding new statements to a document could change the  
truth assignments for statements that were previously known to be "TRUE"  
or "FALSE".






-------- Clarifying Example ----------
To illustrate the difference, the following example is commonly used.  
Suppose to be in a monotonic setting, and to have the following set of  
statements (no need to be RDF, it's a general issue):

"Birds can fly. Penguins are birds. Jack is a penguin."

 From them, you can infer that "Jack can fly". Statement "Jack can fly"  
assumes value "TRUE". Now, suppose you want to model an *exception*, that  
is birds *usually* can fly but penguins cannot, and add statement  
"Penguins cannot fly": from this, you can infer that "Jack cannot fly".  
However, in a monotonic setting, statements that was previously "TRUE"  
remain "TRUE", so having both "Jack can fly" and "Jack cannot fly"  
assigned to "TRUE" yields to an inconsistency. Full stop. Your document is  
nonsensical.

In a non-monotonic setting, instead, you are allowed to assert something  
like this:

"By default, birds can fly. Penguins are birds. Jack is a penguin."

And this is equivalent to tell your answering engine "well my friend, if  
you cannot otherwise prove that a bird cannot fly, then please assume that  
every bird can fly". Here, you are establishing an inference meta-rule.  
Now, suppose to add the sentence "Penguins cannot fly": no inconsistency  
arises, because your engine can now "retract" the previously inferred  
statement "Jack can fly" (more precisely, it can reconsider its assignment  
to value "TRUTH") and you don't have as a result that two conflicting  
statements are both evaluated as "TRUE". This process is called "default  
reasoning".






-------- Approach to the solution ----------
Ah, eventually, I come to the point: what does this stuff has to do with  
your questions.
In case of "Action" and "Event", you say

"I have an 'entity' called 'Action' with what the reference document terms  
'a parent' of'Event'", and "Some of the attributes of Action are not  
attributes of Event".

Assuming that 'parent' means rdfs:subclassOf, that is to say "all Events  
are also Actions", then what you have is a non-monotonic modeling. BY  
DEFAULT, Actions have this and this and this property, BUT some of them do  
not apply to Events (remember? BY DEFAULT, birds can fly, BUT that does  
not apply to penguins).

Non-monotonicity is a convenient facility, but unfortunately (for you,  
obviously there are motivations for having monotonicity in RDF) it is not  
trivial to rewrite a model written for a non-monotonic environment into an  
equivalent model written for a monotonic environment, where for  
*equivalent* I mean that their truthValueOf functions are identical  
(assign the same truth value to all statements).

So, in order to correctly map your specification into an document RDF, you  
have to transform it so that it assigns every sentence involving Events,  
Actions, their properties, and so on, the same truth values they are  
assigned in the non-monotonic, original environment.

The good news is that this is a very general problem, and that design  
patterns exist. I am not a guru, though. So, I just give you some example  
in order to let you understand the nature of the problem, but please do  
not expect that I can give you the universal solution or algorithm because  
I don't even know whether it exists.






-------- Solution ----------
Let's say that we have these sentences you need to model in RDF:

1) I have categories (entities, classes) Action and Event
2) Action is a broader category than Event, in the sense that all Events  
are also Actions but there are some Actions which are not Events
3) Action has an attribute performedBy which indicates which Person is the  
author of the Action (i'm inventing here)
4) The same attribute is not relevant to Events, rather it does not apply  
to Events because Events are not performed by any Person, they just happen  
(i'm inventing here, too).

Now, points 3) and 4) express non-monotonicity because they say that all  
Actions have an author, except for Events which are Actions without any  
author; so, we have to take care about how we perform the translation.  
Let's proceed with order. In a naive translation to RDF, not surprisingly,  
two mismatches would occur: a CWA vs OWA mismatch, and a Monotonic vs  
Non-Monotonic setting mismatch. Let's see.

First, we could be tempted to model the above specifications 1)-4) by  
starting as follows:

SOA:Action rdf:type SOA:Class .
SOA:Event rdfs:subclassOf SOA:Action .
SOA:performedBy rdfs:range SOA:Action .
SOA:performedBy rdfs:domain SOA:Person .
...

-------------------------------------------------------
FIRST MISMATCH: Closed World vs Open World Assumption!
-------------------------------------------------------
The above RDFS statement "SOA:performedBy rdfs:domain SOA:Action" above  
does not say that all Actions, and ONLY all Actions, MUST have a  
"SOA:performedBy" property, and it does not even say that it must have  
only ONE of such descriptions. SOA:performedBy here is neither "private"  
to Actions nor it is constrained to assume exactly one value. Instead,  
what the statement says is that "should you ever find out that something  
is linked by the 'SOA:performedBy' to anything else, then you could infer  
that such thing is certainly an Action" (now, I think, you can more easily  
understand why having multiple classes in the domain of a property implies  
that individuals described by that property are instances of *all* of  
those classes, in a monotonic environment). The same applies to the range  
of a property.

In order to solve this first mismatch and preserve the semantics after  
translation, you have to adjust your document as follows, and you need OWL  
to do that, because of the use of concept negation and cardinality  
restriction:

SOA:Action rdf:type SOA:Class .
SOA:Event rdfs:subclassOf SOA:Action .
SOA:Action owl:equivalentClass SOA:ThingsPerformedByExactlyOnePerson .
SOA:ThingsPerformedByExactlyOnePerson rdf:type owl:Restriction .
SOA:ThingsPerformedByExactlyOnePerson owl:onProperty SOA:performedBy .
SOA:ThingsPerformedByExactlyOnePerson owl:cardinality "1"^^xsd:integer .
SOA:ThingsPerformedByExactlyOnePerson owl:allValuesFrom SOA:Person .
...

This allows to model under OWA the equivalent of points 1)-3) in our  
specification, that is "Action (implicit: and ONLY Action!) has an  
attribute performedBy which indicates which Person is the author of the  
Action".
But now, if we want to model point 4), we have a problem.

-------------------------------------------------------
SECOND MISMATCH: Non-monotonic vs. Monotonic setting!
-------------------------------------------------------
If we naively extended our document by saying that the domain of property  
"SOA:performedBy" never includes an Event, i.e. that "SOA:performedBy"  
does not "apply" to Events, we would contradict ourselves: the reason is  
due to the monotonic setting in which we are talking, and the pattern is  
exactly the same as for the penguin example. The above statements say that  
all actions have an author. If we now say that everything which has an  
author (i.e., which is an Action!) is never an Event, we have an  
inconsistency. You see? "SOA:Event rdfs:subclassOf SOA:Action" tells us  
that all Events are also Actions, and Actions always have an author, and  
if we also say that everything which has an author is not an Event... we  
are just inconsistent in what we say.

So, if you simply transfer our 1)-4) points with their original  
non-monotonic meaning in a *syntactically* equivalent document to which  
you give, instead, a monotonic meaning, it is perfectly right what you say  
that the "use of the term 'parent' is not consistant with the  
class-subclass viewpoint".

Clearly, this happens because in our above RDF document we was saying that  
Actions *always* have an author. Instead, what our 3)-4) points want to  
say (maybe implicitly, maybe ambiguously) is that *by default* Actions  
have an authour, i.e. we assume a non-monotonic environment. Fortunately,  
translating them into equivalent, monotonic ones is quite an easy task,  
but it requires the introduction of more information (in the very general  
case, it requires the introduction of *much* more information, and this is  
the reason why non-monotonicity is so useful in practice).

Let's see how. First, we recognize that saying "by default Actions have an  
authour" means that not all Actions have an author, only some of them have  
one. So, we create two subclasses of Actions which we name  
ActionWithAnAuthor and ActionWithoutAnAuthor. Then, Event is a subclass of  
the latter only, and not of the former. Correctly, it remains true that  
all Events are also Actions:

SOA:Action rdf:type SOA:Class .
SOA:ActionWithAnAuthor rdfs:subclassOf SOA:Action .
SOA:ActionWithoutAnAuthor rdfs:subclassOf SOA:Action .
SOA:Event rdfs:subclassOf SOA:ActionWithoutAnAuthor .

Now, the description we gave for Action in our initial RDF document is the  
one we want for ActionWithAnAuthor (again, you need OWL for the same  
reasons):

SOA:Action rdf:type SOA:Class .
SOA:ActionWithAnAuthor rdfs:subclassOf SOA:Action .
SOA:ActionWithoutAnAuthor rdfs:subclassOf SOA:Action .
SOA:Event rdfs:subclassOf SOA:ActionWithoutAnAuthor .
SOA:ActionWithAnAuthor owl:equivalentClass  
SOA:ThingsPerformedByExactlyOnePerson .
SOA:ThingsPerformedByExactlyOnePerson rdf:type owl:Restriction .
SOA:ThingsPerformedByExactlyOnePerson owl:onProperty SOA:performedBy .
SOA:ThingsPerformedByExactlyOnePerson owl:cardinality "1"^^xsd:integer .
SOA:ThingsPerformedByExactlyOnePerson owl:allValuesFrom SOA:Person .

Furthermore, the two subclasses ActionWithAnAuthor and  
ActionWithoutAnAuthor are cleary disjoint and, together, they cover all of  
the set of Actions, and this is not captured yet by our document. So, we  
also need to add:

SOA:ActionWithAnAuthor owl:disjointWith SOA:ActionWithoutAnAuthor .
SOA:UnionOfActionWithAnAuthorAndActionWithoutAnAuthor owl:unionOf  
SOA:myList1 .
SOA:myList rdf:type rdf:List .
SOA:myList rdf:first SOA:ActionWithAnAuthor .
SOA:myList rdf:rest rdf:List SOA:myList2 .
SOA:myList2 rdf:type rdf:List .
SOA:myList2 rdf:first SOA:ActionWithoutAnAuthor .
SOA:myList2 rdf:rest rdf:nil .
SOA:Action rdf:subclassOf  
SOA:UnionOfActionWithAnAuthorAndActionWithoutAnAuthor .

and this completes the translation of our specification. Of the above 9  
statements, the first one models the disjointness between the two newly  
introduced classes ActionWithAnAuthor and ActionWithoutAnAuthor, while the  
remaining (quite weird, ok) 8 statements model the total covering of  
ActionWithAnAuthor and ActionWithoutAnAuthor (mathematically, the  
extensions of ActionWithAnAuthor and ActionWithoutAnAuthor are a partition  
of the extension of Action). So, the resulting document:

SOA:Action rdf:type SOA:Class .
SOA:ActionWithAnAuthor rdfs:subclassOf SOA:Action .
SOA:ActionWithoutAnAuthor rdfs:subclassOf SOA:Action .
SOA:Event rdfs:subclassOf SOA:ActionWithoutAnAuthor .
SOA:ActionWithAnAuthor owl:equivalentClass  
SOA:ThingsPerformedByExactlyOnePerson .
SOA:ThingsPerformedByExactlyOnePerson rdf:type owl:Restriction .
SOA:ThingsPerformedByExactlyOnePerson owl:onProperty SOA:performedBy .
SOA:ThingsPerformedByExactlyOnePerson owl:cardinality "1"^^xsd:integer .
SOA:ThingsPerformedByExactlyOnePerson owl:allValuesFrom SOA:Person .
SOA:ActionWithAnAuthor owl:disjointWith SOA:ActionWithoutAnAuthor .
SOA:UnionOfActionWithAnAuthorAndActionWithoutAnAuthor owl:unionOf  
SOA:myList1 .
SOA:myList rdf:type rdf:List .
SOA:myList rdf:first SOA:ActionWithAnAuthor .
SOA:myList rdf:rest rdf:List SOA:myList2 .
SOA:myList2 rdf:type rdf:List .
SOA:myList2 rdf:first SOA:ActionWithoutAnAuthor .
SOA:myList2 rdf:rest rdf:nil .
SOA:Action rdf:subclassOf  
SOA:UnionOfActionWithAnAuthorAndActionWithoutAnAuthor .

is a semantics-preserving translation of points 1)-4) of our  
specification, giving in the OWA, monotonic settings the same entailments  
that were given in the native CWA, non-monotonic setting of 1)-4). In this  
sense, the above modeling is "correct". If you now want to build an RDF  
translation of the entire SOA specification, you need to proceed likewise  
for other classes, attributes and so on. As you can imagine, the output  
document will be much more verbose and heavy than the original one, but  
this is unavoidable if you want to preserve its semantics while bridging  
it from a CWA, non-monotonic setting into an OWA, monotonic setting.

Now, you could wonder why we need the OWA, monotonic setting, if it is so  
unwieldy to do correct modeling with it. Well, the answer is much more  
complicated and deserves books, not posts, but still is there, and I am  
sure RDF was designed with that answer in mind.

Paul, I hope this explanation will be helpful to you. Please tell me in  
case I did not satisfactorily address your questions.
Best regards,

Andrea








In data Sat, 11 Feb 2006 03:16:49 +0100, Paul S Prueitt  
<[hidden email]> ha scritto:

> Andrea, you are so kind.
>
> I see this clearly.  The domain of a property would not need to have  
> both a
> class and and subclass as the properties of the class are inherited by  
> the
> subclass.
>
> Can I remove properties easily in a subclass?  What does this mean for  
> the
> OWL indexing - to use Alan Rector's phrase (or reasoning), if a property  
> is
> removed from a subclass?
>
> Is this treated as an exception and would this exception generate a new  
> RDF
> triple?
>
> { Note that in my task to express the SOA-IM's 38 data objects as RDF or  
> OWL
> construction, I have an "entity" called "Action" with what the reference
> document terms "a parent" of "Event".   Some of the attributes of Action  
> are
> not attributes of Event.   Now this woudl seem to suggest that the IM
> author's use of the term "parent" is not consistant with the class -
> subclass viewpoint.  So the question arises, how does one represent the
> intentions of the author of the IM?  )
>
> This is a practical problem not one of theory.  The entities of the IM  
> are
> more "objects" with "private data" than classes with subclasses and
> properties.
>
>
>
> So Next to RDFS, which includes a "vocabulary" where defintions extend  
> the
> "language" one might put OWL Lite, then OWL DL and then OWL Full?
>
> .
>
>
>
>
>
> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]]On Behalf Of Andrea Proli
> Sent: Friday, February 10, 2006 5:50 PM
> To: [hidden email]
> Subject: [protege-owl] Re: pure RDF properties
>
>
> Paul, pure RDF does not provide a vocabulary to define the domain and
> range of properties. In order to do that, you need to have the
> "rdfs:domain" and "rdfs:range" properties, which are part of the RDFS
> vocabulary. In RDFS, properties can have multiple classes as their domain
> as well as multiple classes as their range.
>
> However, including both a class and one of its subclasses in the domain  
> of
> a property would not make a lot of sense (more precisely, it would yield
> redundant information), because asserting that multiple classes are in  
> the
> domain of property p implies that individuals described by p are  
> instances
> of *all* of those classes. For this reason, including two classes which
> are on the same specialization hiearchy in the domain of a property is
> equivalent to  including only the most specific one.
>
> Andrea
>
> In data Fri, 10 Feb 2006 23:43:13 +0100, Paul S Prueitt
> <[hidden email]> ha scritto:
>
>>
>>
>> so in pure RDF a property can have only one class in its domain.
>>
>> I can see this (when using the language profile pure RDF) because I
>> tried to
>> put two classes , a class and its subclass, in the domain of a single
>> property.  A pop up told me I could not do this.
>>
>>
>>
>>
>> so I change the language profile...  to do this I studied for a while  
>> and
>> then "found" that I can do this with the preferences... but preferences
>> tells me something about a user name and that is all..
>>
>> Do I just start over and declare that this will be OWL lite?
>>
>> Is there a different "preference" that allows me to alter a pure RDF and
>> create a language profile that is OWL Lite?
>>
>>
>>
>> -------------------------------------------------------------------------
>> To unsubscribe go to  
>> http://protege.stanford.edu/community/subscribe.html
>>
>
>
> -------------------------------------------------------------------------
> To unsubscribe go to http://protege.stanford.edu/community/subscribe.html
>
>
>
> -------------------------------------------------------------------------
> To unsubscribe go to http://protege.stanford.edu/community/subscribe.html
>


-------------------------------------------------------------------------
To unsubscribe go to http://protege.stanford.edu/community/subscribe.html

Reply | Threaded
Open this post in threaded view
|

Re: pure RDF properties

Paul S Prueitt

Andrea's note is posted at

http://www.bcngroup.org/beadgames/generativeMethodology/166.htm

with footnotes by Paul

We are going to make some additional comments after we define the OWL (Full)
ontology following Andrea's perfectly correct solution.

THANKS

Paul Prueitt


-------------------------------------------------------------------------
To unsubscribe go to http://protege.stanford.edu/community/subscribe.html

Reply | Threaded
Open this post in threaded view
|

Re: pure RDF properties

Nick Drummond
In reply to this post by Paul S Prueitt
Thanks to Andrea for a substantial answer to a later question in the
thread - I hope to have time to read through it all.

Just to clarify the issue of the Preferences dialog.
In OWL, this is available under the OWL menu - for historical reasons,
when the number of options required for OWL massively outgrew those
needed for frames - we hope to integrate all of these in one *sensible*
place.

Nick

Paul S Prueitt wrote:

>so in pure RDF a property can have only one class in its domain.
>
>I can see this (when using the language profile pure RDF) because I tried to
>put two classes , a class and its subclass, in the domain of a single
>property.  A pop up told me I could not do this.
>
>
>
>
>so I change the language profile...  to do this I studied for a while and
>then "found" that I can do this with the preferences... but preferences
>tells me something about a user name and that is all..
>
>Do I just start over and declare that this will be OWL lite?
>
>Is there a different "preference" that allows me to alter a pure RDF and
>create a language profile that is OWL Lite?
>
>
>
>-------------------------------------------------------------------------
>To unsubscribe go to http://protege.stanford.edu/community/subscribe.html
>
>
>  
>

--

Nick Drummond

http://www.cs.man.ac.uk/~drummond/ <http://www.cs.man.ac.uk/%7Edrummond/>
-------------------------------------------------------------------------
To unsubscribe go to http://protege.stanford.edu/community/subscribe.html