From GK@Dial.pipex.com Mon Jan 1 13:07:11 2001
Date: Mon, 01 Jan 2001 13:07:11 +0000
From: Graham Klyne GK@Dial.pipex.com
Subject: [RDF] Re: Authorization
Craig,
This little exchange highlights something that I think may be one of the
next important steps (beyond initial implementation) for research using
your RDF-driven expert system.
#g
--
Jonas,
I've lost the context for this so my responses may be incomplete...
I think the whole area of trust modelling is a key application for RDF, and
one that I plan to explore over the coming months. Skip to [**] below for
some (few) thoughts on this.
At 12:12 AM 12/29/00 +0100, Jonas Liljegren wrote:
>Graham Klyne writes:
>
> > Suppose I wish to use RDF to model a security access scheme. Suppose
> > access controls are defined in terms of (a) a resource that may be
> > accessed, (b) an actor who may gain some access to the resource, and
> > (c) an operation type that describes the kind of access granted. (In
> > case this seems unduly artificial, this is exactly the access control
> > framework proposed for the IMXP instant messaging proposal [1].)
> >
> > How is such a system to be modelled in RDF? I present the following
> > as a reasonably obvious and direct way:
> >
> > [ACE] --rdf:type---> [AccessControlElement]
> > [ ] --actor------> [AccessorIdent]
> > [ ] --resource---> [AccessedResource]
> > [ ] --operation--> [AccessGranted]
>
>Have you done more on this?
Not the RDF stuff: that bit was entirely speculative.
>What are the possible types of operations? Is the actor and resource
>specified as types, collections or something else?
As far as the IMXP (to be renamed APEX) work is concerned, they're just
strings. Actors and resources are identified by email address like
strings:
>Who has the right to state these rules about this?
The access rules are under control of the administrative domain to which
they refer. The whole security model here involves an idea of "each domain
keeping its own house in order".
The remaining points I shall comment on without reference to IMXP/APEX...
>I and Stefan have thought and talked alot about systems there you only
>add information, and that lets anybody say anything. (I think that is
>a oart of the semantic web.)
That fits my mental model, too.
>This means that you can say that a previous stating is false. In your
>context, the statement is false. But others may not trust you and may
>regard the statement as true.
Yup. This is one of the ideas that started me thinking about contexts.
>This leads to the question on what type of statements can be trusted
>from diffrent staters. Take for example a list of persons with phone
>numbers. There may be a number of people you trust on giving accurate
>information. Those persons would in a closed system been given
>administration access to the database.
[**]
I think that this is all information that has to be coded in some way. An
RDF-based trust assessment framework should also describe its own trust
model, I think. I don't think there are any universal answers (though
there probably will be some useful trust models that will be commonly used).
>But you will also want to trust information that people gives about
>themself, as long as you know that they are who they say they are.
>How do you model that?
I haven't got there yet, but I am hoping that within 2-3 months we'll have
some software that will allow us to model and experiment with these ideas.
>And what happens if two trusted statings disagree?
Same problem. Same answer ([**] above)
>What other types of authorization criterions could there bee?
Without limit. Again, see [**] above.
#g
------------
Graham Klyne
(GK@ACM.ORG)
From GK@Dial.pipex.com Mon Jan 1 13:05:21 2001
Date: Mon, 01 Jan 2001 13:05:21 +0000
From: Graham Klyne GK@Dial.pipex.com
Subject: [RDF] Re: Authorization
Jonas,
I've lost the context for this so my responses may be incomplete...
I think the whole area of trust modelling is a key application for RDF, and
one that I plan to explore over the coming months. Skip to [**] below for
some (few) thoughts on this.
At 12:12 AM 12/29/00 +0100, Jonas Liljegren wrote:
>Graham Klyne writes:
>
> > Suppose I wish to use RDF to model a security access scheme. Suppose
> > access controls are defined in terms of (a) a resource that may be
> > accessed, (b) an actor who may gain some access to the resource, and
> > (c) an operation type that describes the kind of access granted. (In
> > case this seems unduly artificial, this is exactly the access control
> > framework proposed for the IMXP instant messaging proposal [1].)
> >
> > How is such a system to be modelled in RDF? I present the following
> > as a reasonably obvious and direct way:
> >
> > [ACE] --rdf:type---> [AccessControlElement]
> > [ ] --actor------> [AccessorIdent]
> > [ ] --resource---> [AccessedResource]
> > [ ] --operation--> [AccessGranted]
>
>Have you done more on this?
Not the RDF stuff: that bit was entirely speculative.
>What are the possible types of operations? Is the actor and resource
>specified as types, collections or something else?
As far as the IMXP (to be renamed APEX) work is concerned, they're just
strings. Actors and resources are identified by email address like
strings:
>Who has the right to state these rules about this?
The access rules are under control of the administrative domain to which
they refer. The whole security model here involves an idea of "each domain
keeping its own house in order".
The remaining points I shall comment on without reference to IMXP/APEX...
>I and Stefan have thought and talked alot about systems there you only
>add information, and that lets anybody say anything. (I think that is
>a oart of the semantic web.)
That fits my mental model, too.
>This means that you can say that a previous stating is false. In your
>context, the statement is false. But others may not trust you and may
>regard the statement as true.
Yup. This is one of the ideas that started me thinking about contexts.
>This leads to the question on what type of statements can be trusted
>from diffrent staters. Take for example a list of persons with phone
>numbers. There may be a number of people you trust on giving accurate
>information. Those persons would in a closed system been given
>administration access to the database.
[**]
I think that this is all information that has to be coded in some way. An
RDF-based trust assessment framework should also describe its own trust
model, I think. I don't think there are any universal answers (though
there probably will be some useful trust models that will be commonly used).
>But you will also want to trust information that people gives about
>themself, as long as you know that they are who they say they are.
>How do you model that?
I haven't got there yet, but I am hoping that within 2-3 months we'll have
some software that will allow us to model and experiment with these ideas.
>And what happens if two trusted statings disagree?
Same problem. Same answer ([**] above)
>What other types of authorization criterions could there bee?
Without limit. Again, see [**] above.
#g
------------
Graham Klyne
(GK@ACM.ORG)
From jonas@liljegren.org Mon Jan 1 16:36:58 2001
Date: 01 Jan 2001 17:36:58 +0100
From: Jonas Liljegren jonas@liljegren.org
Subject: [RDF] Re: Authorization
Graham Klyne writes:
> I've lost the context for this so my responses may be incomplete...
>
> I think the whole area of trust modelling is a key application for
> RDF, and one that I plan to explore over the coming months. Skip to
> [**] below for some (few) thoughts on this.
I just want to think a little about what direction this should take,
so that it will fit with the other parts developed in perallell.
> >I and Stefan have thought and talked alot about systems there you only
> >add information, and that lets anybody say anything. (I think that is
> >a part of the semantic web.)
>
> That fits my mental model, too.
>
> >This means that you can say that a previous stating is false. In your
> >context, the statement is false. But others may not trust you and may
> >regard the statement as true.
>
> Yup. This is one of the ideas that started me thinking about contexts.
>
> >This leads to the question on what type of statements can be trusted
> >from diffrent staters. Take for example a list of persons with phone
> >numbers. There may be a number of people you trust on giving accurate
> >information. Those persons would in a closed system been given
> >administration access to the database.
>
> [**]
>
> I think that this is all information that has to be coded in some way.
> An RDF-based trust assessment framework should also describe its own
> trust model, I think. I don't think there are any universal answers
> (though there probably will be some useful trust models that will be
> commonly used).
Yes. I want to find one useful general model suitable for the type of
system I am aiming at. That is:
The versioning system and the trust system are two aspects of the same
thing. To trust or not to trust is just one view. Other views is to
see what is stated in diffrent times or from diffrent perspecives or
scenarios.
I am searching for a clean and simple way to implement:
a) Content in diffrent languages
b) Diffrent levels of quality
c) Diffrent groups of staters
And it should wor well with diffrent types of statemets (or groups of
statements) that is suppoesed to override previous ones.
a) Statement for a diffrent time
b) Statement for a diffrent perspecitve
c) Statement as a correction for a previous one
And I want this to be the same thing as the standard information
queries. That is; a request for information includes a context for the
request. The answer to the request is given within the context.
This is my definition for context withing Wraf. The context is used
as the base for a information request. It's sot of part of the
request. It contains your preferences used to select the wanted
language, timeframe, version, inormation source, and more.
The context is a hierarchy of contexts. It starts with the session,
defining the time and place for the conversation. Here we identifies
the requestor agent and the service. A specific request adds to the
context. There can be a series of questions and counter-questions,
all within the context.
The basis for this is implemented in Wraf. But not yet developed.
The thing here is that the trust model and the other things is part of
the preferences in the context. The preferences of the agent is
overrided by the session preferences and later overrided by the
explicit preferences for the specific request.
So what could we use for model as a testcase for this? Something
simple and useful for a typical community database. Maby a use of
ratings to sorting or filtering discussion entries, a little like
slashdot, but simpler?
You could register yourself to diffrent types of groups and the
classification and ratings would belong to those groups.
--
/ Jonas - http://jonas.liljegren.org/myself/en/index.html
From GK@Dial.pipex.com Mon Jan 1 17:50:35 2001
Date: Mon, 01 Jan 2001 17:50:35 +0000
From: Graham Klyne GK@Dial.pipex.com
Subject: [RDF] Re: Klyne Contexts: 3. Statements sets in RDF
At 12:36 AM 12/29/00 +0100, Jonas Liljegren wrote:
>Graham Klyne writes:
>
> > It seems to me that, given an RDF graph, I should be able to extract
> > an arbitrary subgraph (i.e. a subset of the statements) and still have
> > a valid RDF graph. The RDF approach to containers doesn't permit
> > this, because (I think) the following is not valid per RDF M&S:
> >
> > [Foo] --rdf:type--> [rdf:Bag]
> > [ ] --rdf:_1----> [Member1]
> > [ ] --rdf:_3----> [Member3]
>
>I say that it must be valid. I would even allow:
>
> [Foo] --rdf:type--> [rdf:Bag]
> [ ] --rdf:_1----> [Member1]
> [ ] --rdf:_1----> [OtherMember1]
> [ ] --rdf:_3----> [Member3]
>
>
>This because anyone can say anything about everything.
Look at RDF M&S, send of section 5. It states that the ordinal properties
must be used sequentially starting with rdf:_1.
This is why I think RDFM&S collections are broken when, as you say, "anyone
can say anything about everything".
>Nobody can stop me if I feel like renumbering the properties of a
>bag. But it should be clear that the new statements is not the
>original ones.
True, but I think that introduces horrible scalability problems for
web-wide collation of information.
> > >1. With special methods for conatiner handling, you will not have to
> > > bother about the present content. Wraf will give each container
> > > the dynamic property 'size', and methods for adding and quering the
> > > container without knowing each propertys number.
> >
> > This assumes that your implementation knows about all of the members.
> > I think that's a kind of closed-world view.
>
>No. The size statement has a source. Other sources can have another
>idea about the size of the container. The statement will belong to a
>model and that model will have data about the scope of the known world.
My biggest objection to all this is that I believe all this extra logic is
simply unnecessary. It is possible to use base RDF to define container
structures that just don't have these problems. If you want to add extra
structures to facilitate your own internal processing then that should be
your choice as an implementer, not something that has to be done to
overcome problems with the standard container structures.
#g
------------
Graham Klyne
(GK@ACM.ORG)
From GK@Dial.pipex.com Mon Jan 1 19:32:12 2001
Date: Mon, 01 Jan 2001 19:32:12 +0000
From: Graham Klyne GK@Dial.pipex.com
Subject: [RDF] Re: Authorization
At 05:36 PM 1/1/01 +0100, Jonas Liljegren wrote:
> > I think that this is all information that has to be coded in some way.
> > An RDF-based trust assessment framework should also describe its own
> > trust model, I think. I don't think there are any universal answers
> > (though there probably will be some useful trust models that will be
> > commonly used).
>
>Yes. I want to find one useful general model suitable for the type of
>system I am aiming at. That is:
>
>The versioning system and the trust system are two aspects of the same
>thing. To trust or not to trust is just one view. Other views is to
>see what is stated in diffrent times or from diffrent perspecives or
>scenarios.
Hmmm... at one level I agree with this, but I was trying to suggest that
no single model will fit all cases. Rather, I see in RDF the potential to
describe and integrate multiple models, without prejudice. So, in a sense,
RDF is your 'general model'?
[...]
>And I want this to be the same thing as the standard information
>queries. That is; a request for information includes a context for the
>request. The answer to the request is given within the context.
>
>This is my definition for context withing Wraf. The context is used
>as the base for a information request. It's sot of part of the
>request. It contains your preferences used to select the wanted
>language, timeframe, version, inormation source, and more.
>
>The context is a hierarchy of contexts. It starts with the session,
>defining the time and place for the conversation. Here we identifies
>the requestor agent and the service. A specific request adds to the
>context. There can be a series of questions and counter-questions,
>all within the context.
Sounds reasonable. Your hierarchy of contexts is consistent with
McCarthy/Guha's work, in that any statement is asserted within a 'nest' of
contexts. However, I think that this doesn't necessarily mean that
contexts always form a strict hierarchy.
>The thing here is that the trust model and the other things is part of
>the preferences in the context. The preferences of the agent is
>overrided by the session preferences and later overrided by the
>explicit preferences for the specific request.
Ah, I see. My view of contexts is much more general, but this is certainly
a valid application.
>So what could we use for model as a testcase for this? Something
>simple and useful for a typical community database. Maby a use of
>ratings to sorting or filtering discussion entries, a little like
>slashdot, but simpler?
I feel that there is more groundwork to be done before I can seriously
address some of these questions. OTOH, if you have a well-specified
use-case, maybe we can work together to try and model it?
#g
------------
Graham Klyne
(GK@ACM.ORG)
From jonas@rit.se Fri Jan 5 15:59:49 2001
Date: 05 Jan 2001 16:59:49 +0100
From: Jonas Liljegren jonas@rit.se
Subject: [RDF] Working on Wraf dokumentation
Well. This is not a announcement of dokumentation.
I just want to say that I have started writing. You could say the
documentation is pre-alpha. :-)
I am posting a link for those who would like to come with suggestions
on what I have missed and thing like that.
I am going to announce the dokumentation then it's a little more
complete.
It's mainly saying what I have planned. It's not saying how or what
works in the 0.0401 release.
The link goes to one of my working directories.
http://jonas.liljegren.org/perl/proj/rdf/RDF-Service/doc/html/wraf.html
--
/ Jonas Liljegren
The Wraf project http://www.uxn.nu/wraf/
Sponsored by http://www.rit.se/
From jonas@rit.se Mon Jan 8 00:25:14 2001
Date: 08 Jan 2001 01:25:14 +0100
From: Jonas Liljegren jonas@rit.se
Subject: [RDF] Re: Statements/Reified statements
Dave Beckett writes:
> Jonas, you have obviously thought about this stuff a lot but I have a
> terrible time trying to understand what you are describing. To show
> what I mean, I'm going to take one of your emails and show your
> assumptions that I can't follow, but want to! :-)
Ok. I have spent some time, trying to write down what I hope to do
with Wraf.
I will now try to answer you questions by pointing to the
documentation pages:
http://www.uxn.nu/wraf/RDF-Service/doc/html/
I have probably failed in giving clear explanations. I would welcome
your help in pointing out what I should explain better.
> >>>Jonas Liljegren said:
> >=20
> > Graham Klyne writes:
> >=20
> > > At 09:51 AM 11/23/00 +0100, Jonas Liljegren wrote:
> > >
> > > >This means that instead of four, we have five:
> > > >
> > > >{ uri, pred, subj, obj, model }
> > >=20
> > > I considered that approach for [1], but have preferred to use
> > > properties to create the association between statement-resource and
> > > context (model). The above approach allows a given statement to be
> > > associated with only one context/model, where properties allow a
> > > given statement-resource to be incorporated into any number of
> > > contexts/models. That seems very much more in line with the RDF
> > > philosophy of "anyone can say anything about anything".
> >=20
> > This depends on if you look at it as a statement or a stating.
> > Anybody can state a specific statement but every stating is unique.
>=20
> statement, stating - what do *you* mean about these things, the word
> 'statement' is what the problem is about. Other words such as
> occurrance, fact should also be avoided.
A statement is just a triple. I would say that Wraf only deals with
statings:
http://www.uxn.nu/wraf/RDF-Service/doc/html/stating.html
The statement occure in a model. I don't use the 'fact' thing. It's
all about trusting statings.
http://www.uxn.nu/wraf/RDF-Service/doc/html/trust.html
> > There are three special cases:
>=20
> insert here - "of statements in different models ..."
>=20
> Of course that depends on what a model is defined as, see below.
>
> > 1. Two URIs for the same statement:
> > S1: [A] --B--> [C] (M1)
> > S2: [A] --B--> [C] (M2)
> >=20
> > 2. The same URI for diffrent statements:
> > S1: [A] --B--> [C] (M1)
> > S1: [D] --E--> [F] (M2)
> >=20
> > 3. The same URI for the same statement:
> > S1: [A] --B--> [C] (M1)
> > S1: [A] --B--> [C] (M2)
>=20
> You do not say what S1, S2, M1, M2 are or what this form of thing
> means:
> ..: [.] --.--> [.] (..)
>=20
> now I *assume* the thing before the : is a URI for the thing that
> follows (you don't say that). And it is pretty obvious the
> [.] --.--> [.] are the triples so we get:
> statement URI: [subject] --predicate--> [object]
> but what is the the (..) ?? A 'model' containing the statements?
Yes. Exactly. See: I didn't have to spell that out. ;-)
> What is your definition of model - a set of statements? An RDF
> collection such as rdf:bag of statements? Is that how you would
> create it?
The model is a core part of Wraf. I can model it as a bag of
statements. But internally, it will be handled as a special case.
http://www.uxn.nu/wraf/RDF-Service/doc/html/model.html
> > This means that neither the triple, nor the URI can be used as the
> > unique key in the storage of RDF. In the Wraf [2] DBI, I uses the
> > combination of model and URI as the key.
>=20
> That's a database way of thinking, not generally relevant. You mean
> the primary key of a table you use is (statement URI, model URI)
Yes...
And the database storage is separated from the internal workings.
This is explaind in the text about nodes:
http://www.uxn.nu/wraf/RDF-Service/doc/html/node.html
> > What is the most efficiant way of storing data, while still allowing
> > any combinations?
> >=20
> > I think that the most practical thing is to view the reified
> > statements as statings. Since they are stated in diffrent models,
> > they will probably have diffrent URIs. The common case will therefore
> > be that a statement belongs to just one model.
>=20
> terms statings, models used again. Introduced a new one 'stated'.
> When a 'statement' is 'stated' in a 'model' do you get a 'stating' as
> well as a 'statement' or just a 'stating'?
Just statings. There are no isolated statements. They either exist as
a stating or they doesn't exist at all.
> > The Wraf is resource centric. A resource has dynamic and static
> > properties. Also the statements are properties. Every resource is
> > said to belong to exactly one model. This means that I will have to
> > represent the special cases 2 and 3 by expanding the statements to
> > their reification.
>=20
> you say:
> "resource is said to belong to exactly one model."
>=20
> RDF says resources are identified by URIs so any model can have any
> resource in it. How can you justify the above sentence?
That's how I have have done it in Wraf. I name it the "normal single
representation":
http://www.uxn.nu/wraf/RDF-Service/doc/html/stating.html
Any model can say things about any resource. But in Wraf, the
resource stands for explicit and implicit statings, and those will
normally only belong to one model. But other models can still 'cite'
those statings:
http://www.uxn.nu/wraf/RDF-Service/doc/html/citation.html
> > A previous version (alpha 3) allowed multipple models. That solved
> > case 3, but not case 2. In addition: what should I do if one of the
> > models changed and the other didn't? This consideration led me to
> > conclude that it would be more efficient to just have one model and
> > group all the nasty cases together for special handling. (The same
> > thing goes for literals and some other things.)
>=20
> What do you mean by multiple models? (or model). In your head,
> everything is one model, but in technology terms, models are
> scattered around the world, web. You can't get away from the fact
> that I will have models of RDF content and so will you.
Wraf connects a large amount of diffrent models.
http://www.uxn.nu/wraf/RDF-Service/doc/html/interface.html
But what I meant was that a stating will usually have a unique URI.
Two models can contain the same statement, but the resource
representing the reified statemnent will not have the same URI as that
of the same statement in another model. They cold, but Wraf will
treat that as a special case.
> > Even if I store statements as {uri, pred, subj, obj, model}, they have
> > an implicit representation in the RDF graph. They are drawn as
> > reified statements contained in a model container. Another
> > representation is to give the statement the property model. (Wraf
> > will infere a lot of properties from other properties.)=20=20
>=20
>=20
> "give the statement the property model"
>=20
> That's too much shorthand. I suspect you mean attach a property to a
> statement resource/node, the property/arc is called wraf:model or
> somesuch but what does it point to?. You need to then say what that
> means.
Correct. It points to the Model object. And that object is of type
Model that is subClassOf Container. The model object will contain the
stating.
> > Case 2, above, has to be spelled out to the point there every URI only
> > belongs to one model. Here, we prefix generated URIs with G:
>=20
> "every URI only belongs to one model"
>=20
> !!! What?
I think that's have been explaind by now.
> > G1: [S1] --type--> [Statement] (M1)
> > G2: [S1] --subject--> [A] (M1)
> > G3: [S1] --predicate--> [B] (M1)
> > G4: [S1] --object--> [C] (M1)
>=20
> a break here would be clearer to show they are in different models,
> or are they? Different models but same storage?
>=20
> > G5: [S1] --type--> [Statement] (M2)
> > G6: [S1] --subject--> [D] (M2)
> > G7: [S1] --predicate--> [E] (M2)
> > G8: [S1] --object--> [F] (M2)
>=20
>=20
>=20
> > Quoting statements and the question of truth
> > --------------------------------------------
> >=20
> > Instead of having a boolean for each statement, indicating if the
> > statement is a fact or just a reified statement, we could use models
> > and selections for denoting truth.
>=20
> New term 'selection' - what is that?
Selections:
http://www.uxn.nu/wraf/RDF-Service/doc/html/selection.html=20=20=
=20=20=20
> > The idea is that nonfact statements are placed in another model, or
> > is given a special property saying that the statement is not
> > endorsed. Let's say model M1 has statements serialized as:
>=20
> "nonfact statements"
>=20
> please define. And not by saying 'statements that are not facts' -
> what kind of thing is that?
The M&S says that reified statements are not considered facts. A
nonfact statement is a statement that only exist as a reified
statement and not as a statement. This has to do with citations:
http://www.uxn.nu/wraf/RDF-Service/doc/html/citation.html
> > [S1] --type--> [Statement]
> > [S1] --subject--> [A]
> > [S1] --predicate--> [B]
> > [S1] --object--> [C]
> > [D] --E--> [S1]
> >=20
> > ( Could be drawn as { D E { A B C } }. )
> >=20
> > One thought I had was to store like this:
> >=20
> > S1: [A] --B--> [C] (G1)
> > G2: [D] --E--> [S1] (M1)
> > G3: [G1] --type--> [Model] (G1)
> > G4: [G1] --quotedIn--> [M1] (G1)
> >=20
> >=20
> > Models will have a bunch of metadata about the origin, date and other
> > things. One model could include other models. But the here invented
> > 'quotedIn' can be used to remember that the statement was explicitly
> > included in the model. The 'quotedIn' property is of no importance
> > for the reasoning. But it can be used to recreate the model in
> > serialized XML.
>=20
>=20
> Now that does make sense; I had already decided for Redland to add
> extra statements (real statements, not "non-fact" ones) to my storage
> to describe the model (set of statements) and provide a place for
> administrative information to go, provenance etc. But these would
> appear in the model like other statements.
Infered and implicit statements can be placed in other models and thus
not interfereing with the original model.
> > What's considered to be true will depend on what model's you trust.
>=20
> Yes. So I guess I can now work out that you store multiple models in
> one storage system. Why not just use rdf:bag to enclose models in
> one storage?
Huh?
> > Aliases
> > -------
> >=20
> > Another question is that of resource aliases. G2 above may be
>=20
>=20
> Which G2? You define 2 of them.
>=20
> What is a resource alias? This sounds like the resource/URI black hole.
http://www.uxn.nu/wraf/RDF-Service/doc/html/aliases.html
Maby I'm not exactly clear on this. What is the resource/URI black
hole?
> > refering to the same statement as another URI. If it's infered that
> > it's indeed the same *stating*, this will be marked up as that it's=A0an
> > alias to the 'real' name. Let's look at an example of one model with
> > the original stating and another model quoting that statement, without
> > knowing the stating URI:
> >=20
> > S1: [A] --B--> [C] (M1)
> >=20
> > S2: [A] --B--> [C] (M2)
> > S3: [D] --E--> [S2] (M2)
> >=20
> > The context of this may let the application infere that S1 and S2 are
> > indeed the same stating, thus adding:
> >=20
> > S4: [S2] --aliasFor--> [S1] (G1)
> >=20
> > G1 is here the context depending on the inference rule and the
> > involved models.
> >=20
> >=20
> >=20
> >=20
> > Am I right in thinking that you probably thinking that I make all this
> > much more complicated than it ought to be? ;-)
>=20
> Yes, sorry!
I have a habit of dreaming of large complete systems. I have only
documented a small portion of all the things I have thought about.
But I have also thought about how to implement it in a reasonable
timescale, taking one step at the time.
--=20
/ Jonas Liljegren
The Wraf project http://www.uxn.nu/wraf/
Sponsored by http://www.rit.se/
From jonas@rit.se Mon Jan 8 23:06:12 2001
Date: 09 Jan 2001 00:06:12 +0100
From: Jonas Liljegren jonas@rit.se
Subject: [RDF] Re: Poll: RDF Use Cases
"McBride, Brian" writes:
> One of the things which struck me lately during one of
> our lengthier discussions was the idea that many of our
> disagreements may be based on different assumptions
> about the applications we have in mind RDF being used
> for.
Ok. I have started trying to describe Wraf. My intended use for it is
a virtual community aimed at gathering, structuring and refining
knowledge in a web of related topics.
It will provide tools accumulating discussion entries and harvesting
every useful sentence thereof. The result will be a growing hypertext
encyclopedia and guide to find the people you search for.
And, of course, some other things:
http://www.uxn.nu/wraf/RDF-Service/doc/html/wraf.html
The above link is a request for helpful contributions. A work in
progress. Share the dream in rdf@uxn.nu
--
/ Jonas Liljegren
The Wraf project http://www.uxn.nu/wraf/
Sponsored by http://www.rit.se/
From jonas@rit.se Tue Jan 9 16:32:11 2001
Date: 09 Jan 2001 17:32:11 +0100
From: Jonas Liljegren jonas@rit.se
Subject: [RDF] Re: WRAF, HDC : similar projects
"Bernard Vatant" writes:
> At present time, I'm working in the frame of Topic Maps XTM universe. In
> the air is some convergence between XTM and RDF, and I think we badly need
> such convergences, both on syntactic and semantic grounds.
HDC is primarly an isolated thing. RDF is the internal data format.
Wraf neither imports or exports XML documents.
Interoperability is part of the plan. Thats an important reason for
using RDF. But it's a later stage.
> My thought line at the moment is the "bottom-up" construction of the
> semantic web. Various projects are emerging everywhere, they have to
> be linked and interoperative, but not merged in a single huge
> unique-thought picture. I suppose you know also
> http://www-db.stanford.edu/SKC/ , the Bootstrap Institute, OIL, etc
> ... going somehow in the same direction. To take the "global brain"
> image, neurones are there, we have to build effective synapses.=20
Yes. I vision the internet as one large thinking entity with data and
rules. A question can be answerd by forwarding parts of it to many
specialized services and gathering the responses. some of them as
plain data and other produced by using inference rules. None of the
services will be complete or able to give correct answers by
themself. The intelligence will come from the quantity. The web could
primarly consist of exceptions rather than rules.
> Looking forward for any form of link to your project.
The HDC can be integrated with library databases, Open Directory
Project and other databases on the web that can give more data about
certain types of topics. And the internal data can be exported wth
appropriate schemas.
--=20
jonas@rit.se RIT AB http://www.rit.se
Box 70, 428 21 K=E5llered Bes=F6k: G:a Riksv=E4gen 36
Tel: +46 (0)31 751 8600 Fax: +46 (0)31 751 8609
From jonas@liljegren.org Thu Jan 11 19:45:42 2001
Date: 11 Jan 2001 20:45:42 +0100
From: Jonas Liljegren jonas@liljegren.org
Subject: [RDF] Re: Authorization
Graham Klyne writes:
> At 05:36 PM 1/1/01 +0100, Jonas Liljegren wrote:
>
> >The versioning system and the trust system are two aspects of the same
> >thing. To trust or not to trust is just one view. Other views is to
> >see what is stated in diffrent times or from diffrent perspecives or
> >scenarios.
>
> Hmmm... at one level I agree with this, but I was trying to suggest that no
> single model will fit all cases. Rather, I see in RDF the potential to
> describe and integrate multiple models, without prejudice. So, in a sense,
> RDF is your 'general model'?
Yes of course. But in Wraf, I want to provide an flexible
infrastructure on which to build service applications. That's why I
introduce RDFS-classes to represent sessions, uesers, information
requests and more.
The versioning and trust system should be implemented in a way that
you can replace it with another, better suited to your needs. But I
will in any case create one system flexible enough to use for the
application i created Wraf to create.
http://jonas.rit.se/project/RDF-Service/doc/html/hdc.html
It should support multipple languages. Multipple versions. And the
user should see the version blessed by the administrators.
> >The context is a hierarchy of contexts. It starts with the session,
> >defining the time and place for the conversation. Here we identifies
> >the requestor agent and the service. A specific request adds to the
> >context. There can be a series of questions and counter-questions,
> >all within the context.
>
> Sounds reasonable. Your hierarchy of contexts is consistent with
> McCarthy/Guha's work, in that any statement is asserted within a 'nest' of
> contexts. However, I think that this doesn't necessarily mean that contexts
> always form a strict hierarchy.
No. Rather I mean that the context of a request includes who the
requestor is. Metadata about the requestor can be used to get
implicit criterions for the request. One such criterion would be the
prefered language of the response.
The heiarchy was a thought about how to handle contradicting data.
Let's say that you usually like your HTML pages formatted with heavy
graphics and stuff. But for this session, you have asked for smaller
faster pages, because you are using a handheld mobile device. The
statements in the session should have precedence over the general
preference for more graaphics.
I could think about several ways to make this happen.
One such tactic would be to looking in the session metadata before the
person metadata and don't look futher if the specific preference was
found there. Hmm...
Another would be to use exceptions. The logic could be to make a
statement and say that it should override over such statements, but
only for the current session. -- Yes. That sounds right. It would be
the same infrastructure as that used for version handling.
http://jonas.rit.se/project/RDF-Service/doc/html/context.html
> >So what could we use for model as a testcase for this? Something
> >simple and useful for a typical community database. Maby a use of
> >ratings to sorting or filtering discussion entries, a little like
> >slashdot, but simpler?
>
> I feel that there is more groundwork to be done before I can seriously address
> some of these questions. OTOH, if you have a well-specified use-case, maybe
> we can work together to try and model it?
I think that it's important to include this functionality into Wraf as
soon as possible.
But in order to build test cases, I will ned basic presentation
functions. That will be the next step.
http://jonas.rit.se/project/RDF-Service/doc/html/presentation.html
--
/ Jonas - http://jonas.liljegren.org/myself/en/index.html
From jonas@rit.se Thu Jan 11 20:48:14 2001
Date: 11 Jan 2001 21:48:14 +0100
From: Jonas Liljegren jonas@rit.se
Subject: [RDF] Re: Authorization
Oups. Those links will not work. I should have linked to the UXN site...
Jonas Liljegren writes:
> http://jonas.rit.se/project/RDF-Service/doc/html/hdc.html
Should be:
http://www.uxn.nu/wraf/RDF-Service/doc/html/hdc.html
The same for the other links...
--
/ Jonas Liljegren
The Wraf project http://www.uxn.nu/wraf/
Sponsored by http://www.rit.se/
From jonas@rit.se Fri Feb 2 21:44:22 2001
From: jonas@rit.se (Jonas Liljegren)
Date: 02 Feb 2001 22:44:22 +0100
Subject: [RDF] ANNOUNCE: RDF::Service 0.0404
Message-ID: <878znokbex.fsf@jonas.rit.se>
RDF::Service 0.0404 from the Wraf project has been released
http://www.uxn.nu/wraf/
CHANGES
* Lots of documentation
* some changes and bugfixes
DESCRIPTION
Wraf implements a RDF Perl API that hopes to realize the Semantic
Web. The framework uses RDF for data, user interface, modules and
object methods. It uses interfaces to other sources in order to
integrate all data in one enviroment, regardless of storage form.
The homepage for Wraf is http://www.uxn.nu/wraf/ there you can
find the developers mailinglist and more background information.
Please send any comments to the developer mailinglist.
--
/ Jonas Liljegren
The Wraf project http://www.uxn.nu/wraf/
Sponsored by http://www.rit.se/
From csheldon@spoint.com Wed Feb 7 01:41:03 2001
From: csheldon@spoint.com (Chuck Sheldon)
Date: Tue, 6 Feb 2001 17:41:03 -0800
Subject: [RDF] ODP Schema
Message-ID:
Hi,
I am trying to locate the ODP Schema
(RDF-compliant Open Directory Project Schema).
Does Wraf include code or templates for handling ODP?
If so, can you tell me where to find the ODP Schema?
I would be very grateful if you could.
If not, can you direct me to any Perl code that does
parse ODP dumps?
Thanks!
Chuck
P.S.
I am asking you because in:
http: //dmoz.org/Computers/Internet/Searching/Directories/
Open_Directory_Project/Use_of_ODP_Data/Upload_Tools/
the entry:
Perl and the ODP - Free script that converts RDF dumps
into HTML pages, without the use of any database software.
The parsing is done through "raw" perl regular expression
(no use of any XML parser) and HTML files are directly
generated for the selected categories.
points to the non-existant location
http://perlodp.cjb.net
and I can't find anything closer in CPAN or elsewhere.
From jonas@rit.se Wed Feb 7 08:28:36 2001
From: jonas@rit.se (Jonas Liljegren)
Date: 07 Feb 2001 09:28:36 +0100
Subject: [RDF] ODP Schema
In-Reply-To:
References:
Message-ID: <87bssex5fv.fsf@jonas.rit.se>
"Chuck Sheldon" writes:
> I am trying to locate the ODP Schema
> (RDF-compliant Open Directory Project Schema).
I don't have it. I don't think there is a ODP Schema. Just use the
examples.
> Does Wraf include code or templates for handling ODP?
No.
--
/ Jonas Liljegren
The Wraf project http://www.uxn.nu/wraf/
Sponsored by http://www.rit.se/
From vdv@dyomedea.com Wed Feb 7 08:53:51 2001
From: vdv@dyomedea.com (Eric van der Vlist)
Date: Wed, 07 Feb 2001 09:53:51 +0100
Subject: [RDF] ODP Schema
References: <87bssex5fv.fsf@jonas.rit.se>
Message-ID: <3A810D1F.8CA34C6D@dyomedea.com>
Jonas Liljegren wrote:
>
> "Chuck Sheldon" writes:
>
> > I am trying to locate the ODP Schema
> > (RDF-compliant Open Directory Project Schema).
>
> I don't have it. I don't think there is a ODP Schema. Just use the
> examples.
One should also note that the ODP format has been defined before the RDF
syntax went rec and that it is ***not*** RDF compliant.
Some (most?) of the RDF tools provide the option to read these dumps,
though.
Eric
> > Does Wraf include code or templates for handling ODP?
>
> No.
>
> --
> / Jonas Liljegren
>
> The Wraf project http://www.uxn.nu/wraf/
> Sponsored by http://www.rit.se/
>
> _______________________________________________
> RDF mailing list
> RDF@uxn.nu
> http://www.uxn.nu/cgi-bin/mailman/listinfo/rdf
--
See you in Austin (Knowledge Technologies 2001)
http://www.gca.org/attend/2001_conferences/kt_2001/mon.htm
------------------------------------------------------------------------
Eric van der Vlist Dyomedea http://dyomedea.com
http://xmlfr.org http://4xt.org http://ducotede.com
------------------------------------------------------------------------
From dave.beckett@bristol.ac.uk Wed Feb 7 09:52:54 2001
From: dave.beckett@bristol.ac.uk (Dave Beckett)
Date: Wed, 07 Feb 2001 09:52:54 +0000
Subject: [RDF] ODP Schema
In-Reply-To: Message from Eric van der Vlist
of "Wed, 07 Feb 2001 09:53:51 +0100." <3A810D1F.8CA34C6D@dyomedea.com>
Message-ID: <20538.981539574@tatooine.ilrt.bris.ac.uk>
>>>Eric van der Vlist said:
> One should also note that the ODP format has been defined before the RDF
> syntax went rec and that it is ***not*** RDF compliant.
>
> Some (most?) of the RDF tools provide the option to read these dumps,
> though.
I played with the tools from Sergey Melnik, tidied them and tried
them on recent dumps; late last year. I found that not only are the
dumps not RDF, they are not even XML or UTF-8 - so all the XML
parsers died with illegal character dumps somewhere around line
10,000,000 in processing :-)
Maybe I should write rdf-tidy?
Dave
From vdv@dyomedea.com Wed Feb 7 10:23:30 2001
From: vdv@dyomedea.com (Eric van der Vlist)
Date: Wed, 07 Feb 2001 11:23:30 +0100
Subject: [RDF] ODP Schema
References: <20538.981539574@tatooine.ilrt.bris.ac.uk>
Message-ID: <3A812222.1D07B12D@dyomedea.com>
Dave Beckett wrote:
>
> >>>Eric van der Vlist said:
> > One should also note that the ODP format has been defined before the RDF
> > syntax went rec and that it is ***not*** RDF compliant.
> >
> > Some (most?) of the RDF tools provide the option to read these dumps,
> > though.
>
> I played with the tools from Sergey Melnik, tidied them and tried
> them on recent dumps; late last year. I found that not only are the
> dumps not RDF, they are not even XML or UTF-8 - so all the XML
> parsers died with illegal character dumps somewhere around line
> 10,000,000 in processing :-)
Yes, when you say it it rings a bell, I got the same problem trying to
parse them with a simple SAX parser.
> Maybe I should write rdf-tidy?
Should be made before parsing then !
Maybe we should notify the ODP about the character issue first ;=)
Eric
> Dave
>
> _______________________________________________
> RDF mailing list
> RDF@uxn.nu
> http://www.uxn.nu/cgi-bin/mailman/listinfo/rdf
--
See you in Austin (Knowledge Technologies 2001)
http://www.gca.org/attend/2001_conferences/kt_2001/mon.htm
------------------------------------------------------------------------
Eric van der Vlist Dyomedea http://dyomedea.com
http://xmlfr.org http://4xt.org http://ducotede.com
------------------------------------------------------------------------
From csheldon@spoint.com Thu Feb 8 15:48:59 2001
From: csheldon@spoint.com (Chuck Sheldon)
Date: Thu, 8 Feb 2001 07:48:59 -0800
Subject: [RDF] ODP Schema
Message-ID:
Hi,
My deep thanks to you three for your concise
and immediate responses about the ODP Schema:
Dave Beckett
Jonas Liljegren
Eric van der Vlist
The information you provided was *very*
helpful in our effort to find a good
RDF-based standard for tree output.
We are now evaluating better defined
(at least Candidate) standards, such
as RDDL.
Chuck Sheldon
Salient Point, Inc.
From jonas@rit.se Thu Feb 15 11:06:44 2001
From: jonas@rit.se (Jonas Liljegren)
Date: 15 Feb 2001 12:06:44 +0100
Subject: [RDF] Wraf and Perl6
In-Reply-To:
References:
Message-ID: <871yt0dx2z.fsf@jonas.rit.se>
I'm switching from swedish to english, because this should go to the
Wraf list..
About authenticating the modules used by Perl code:
If it exist in the path, it's trusted. and you have the taintcheck
mode and the seldome used "safe" mode.
You could overload the use() and/or require() to check for a signature
and verifying it. And then there should be some way to tell who you
trust. That is; the diffrence between authentication and
authorization. (As I learned from the Apache architecture.)
About a wrapper module:
That's easy. There is a fun module that automaticly loads a module
then a function is used, even if you didn't required that module. And
with the CPAN module, you could even download and install the missing
module. But then you would have to have a network connection. And
it's not all modules that have a fully automate3d installation. And I
think that some modules expects you to install as root.
Remote execution is another thing. I find some SOAP things:
http://www.soaplite.com/
I haven't decided on how Wraf will do it. But we can have many
interfaces and one of them cold be SOAP.
About abbrevations:
That's now part of the latest CVS version of Wraf.
http://uxn.nu/wraf/RDF-Service/doc/html/abbrevation.html
I used the word 'aliases' for stating that two URIs represent the same
thing.
With abbrevations, every session can set up it's own abbrevations,
that can be used in place of the full URI. This could be done by
importing models with defined namespaces using xmlns.
But for now, I'm using simple one-step declaration of abbrevations.
Example:
$session_res->set_abbrev(
{
fn =3D> NS_LD.'/Property#first_name',
ln =3D> NS_LD.'/Property#last_name',
agent =3D> NS_LS.'#agent',
updated =3D> NS_LS.'#updated',
});
And this allows the abbrevations to be used as method
names. Previously (in 0.0404) we had to write (using Template Toolkit)
for displaying the first and last name of a person:
[% person.arc_obj("${NS_LD}/Property#first_name").li.value %]
[% person.arc_obj("${NS_LD}/Property#last_name").li.value %]
The current (CVS) version has changed this to:
[% person.fn.li.value %]
[% person.ln.li.value %]
The li() part says that we want a single object (list item). And
value() says that we want the scalar (literal) value of that object.
This will later be condensed to:
[% person.fn.value %]
[% person.ln.value %]
I hesitated a bit about how to implement the abbrevations, because it
would introduce yet another step in the dispatching of a method. But
then I came to think that this actually saves the object lookup, that
otherwise would have to be done either by the calling program or in
the called method. Now we look up the abbrevated resource in
advance. (ie, translate the URI to a perl object reference)
And this lookup is only done on the API level (level 0). The internal
code uses the more direct notation.
I'm happy with this. It's a big step towards v0.05. :-)
I also have done some other things to the API. But more about that later.
--=20
jonas@rit.se RIT AB http://www.rit.se
Box 70, 428 21 K=E5llered Bes=F6k: G:a Riksv=E4gen 36
Tel: +46 (0)31 751 8600 Fax: +46 (0)31 751 8609
From Stefan.Andersson@ullmans.com Thu Feb 15 12:15:08 2001
From: Stefan.Andersson@ullmans.com (Stefan Andersson)
Date: Thu, 15 Feb 2001 13:15:08 +0100
Subject: [RDF] SV: Wraf and Perl6
Message-ID:
"You could overload the use() and/or require() to check for a signature and
verifying it."
Ummm... how about
Use "http://www.uxn.nu/rpm/Math/Complex.pm" as Math::Complex;
or just
Use "http://www.uxn.nu/rpm/Math/Complex.pm";
:-D
"And then there should be some way to tell who you
trust. That is; the diffrence between authentication and
authorization. (As I learned from the Apache architecture.)"
Doesn't the 'use' clause represent an explicit trust relation?
"http://www.soaplite.com/"
Cool!
"I haven't decided on how Wraf will do it. But we can have many
interfaces and one of them cold be SOAP."
Would there be a shortcut in making a generalized perl module interface?
Something that mapped metadata about the modules to metadata about WRAF
Interfaces?
Hmm.. got to think a bit about that.
"http://uxn.nu/wraf/RDF-Service/doc/html/abbrevation.html"
"[% person.fn.li.value %]"
Now you're talking!
/Stefan
From jonas@rit.se Thu Feb 15 13:09:54 2001
From: jonas@rit.se (Jonas Liljegren)
Date: 15 Feb 2001 14:09:54 +0100
Subject: [RDF] Re: Wraf and Perl6
References:
Message-ID: <87n1bocct9.fsf@jonas.rit.se>
Removed goteborg.pm from the cc list...
Stefan Andersson writes:
> "You could overload the use() and/or require() to check for a signature a=
nd
> verifying it."
>=20
> Ummm... how about
>=20
> Use "http://www.uxn.nu/rpm/Math/Complex.pm";
Yes. That could work. And we already have (in perl) a recommended way
to say what we want to import from a module. But most modules uses
an OO interface. You should do something like:
my $obj =3D new http://www.uxn.nu/rpm/Math/Complex.pm;
But I'm sure that the Perl6 stuff will be good.
> "And then there should be some way to tell who you
> trust. That is; the diffrence between authentication and
> authorization. (As I learned from the Apache architecture.)"
>=20
> Doesn't the 'use' clause represent an explicit trust relation?
It depends on if you are stating the implementation or the function
you want to use. And maby there is someone else who wants to import
the module. The users choise has to be approved by the sysadmin.
> "I haven't decided on how Wraf will do it. But we can have many
> interfaces and one of them cold be SOAP."
>=20
> Would there be a shortcut in making a generalized perl module interface?
> Something that mapped metadata about the modules to metadata about WRAF
> Interfaces?
I'm mainly thinking about connections to other RDF services. And that
all Wraf interfaces should be extendable and upgradable through Wraf
itself.
The embedded version numbers in the interface module names is a step
on the they to eventually store the interface inside Wraf.
RDF::Service::Interface::DBI::V01
He. Another moment 22. How do I connect to the DBI interface if it's
stored in the DBI interface? :-)
and this will have two types of interfaces. The local interfaces that
transparently gets downloaded and installed. And the remote
interfaces that use another Service on another server.
The SOAP thing would be just like having an interface to retrieve
resource properties. Nothing complicated here...
> "http://uxn.nu/wraf/RDF-Service/doc/html/abbrevation.html"
>=20
> "[% person.fn.li.value %]"
>=20
> Now you're talking!
Yes. :-)
And to get the second first name you had in 1980:
[% person.fn( date =3D 1980 ).li(2).value %]
But that's not implemented yet...
RDFS:label
Now I must continue hacking. I have a stupid resource that doen't
want to be saved. It should be because i have put a label on it, and
that label should be preserved...
labels being one of the special cases. Maby it shouldn't be a special
case. Probably shouldn't... But it forces me to sort out entrypoints
for implicit properties. And that will be used by infered properties.
So this is sort of a small step toward that.
http://uxn.nu/wraf/RDF-Service/doc/html/dynamic.html
--=20
jonas@rit.se RIT AB http://www.rit.se
Box 70, 428 21 K=E5llered Bes=F6k: G:a Riksv=E4gen 36
Tel: +46 (0)31 751 8600 Fax: +46 (0)31 751 8609
From Stefan.Andersson@ullmans.com Thu Feb 15 13:18:23 2001
From: Stefan.Andersson@ullmans.com (Stefan Andersson)
Date: Thu, 15 Feb 2001 14:18:23 +0100
Subject: SV: [RDF] Re: Wraf and Perl6
Message-ID:
Will you upgrade the Demo to reflect the new possibilities?
/Stefan
> -----Ursprungligt meddelande-----
> Fr=E5n: rdf-admin@uxn.nu [mailto:rdf-admin@uxn.nu]F=F6r Jonas =
Liljegren
> Skickat: den 15 februari 2001 14:10
> Till: Stefan Andersson
> Kopia: 'masters@rit.se'; 'Wraf development'
> =C4mne: [RDF] Re: Wraf and Perl6
>=20
>=20
> Removed goteborg.pm from the cc list...
>=20
>=20
> Stefan Andersson writes:
>=20
> > "You could overload the use() and/or require() to check for=20
> a signature and
> > verifying it."
> >=20
> > Ummm... how about
> >=20
> > Use "http://www.uxn.nu/rpm/Math/Complex.pm";
>=20
> Yes. That could work. And we already have (in perl) a recommended =
way
> to say what we want to import from a module. But most modules uses
> an OO interface. You should do something like:
>=20
> my $obj =3D new http://www.uxn.nu/rpm/Math/Complex.pm;
>=20
>=20
> But I'm sure that the Perl6 stuff will be good.
>=20
>=20
> > "And then there should be some way to tell who you
> > trust. That is; the diffrence between authentication and
> > authorization. (As I learned from the Apache architecture.)"
> >=20
> > Doesn't the 'use' clause represent an explicit trust relation?
>=20
> It depends on if you are stating the implementation or the function
> you want to use. And maby there is someone else who wants to import
> the module. The users choise has to be approved by the sysadmin.
>=20
>=20
>=20
> > "I haven't decided on how Wraf will do it. But we can have many
> > interfaces and one of them cold be SOAP."
> >=20
> > Would there be a shortcut in making a generalized perl=20
> module interface?
> > Something that mapped metadata about the modules to=20
> metadata about WRAF
> > Interfaces?
>=20
> I'm mainly thinking about connections to other RDF services. And =
that
> all Wraf interfaces should be extendable and upgradable through Wraf
> itself.
>=20
> The embedded version numbers in the interface module names is a step
> on the they to eventually store the interface inside Wraf.
>=20
> RDF::Service::Interface::DBI::V01
>=20
> He. Another moment 22. How do I connect to the DBI interface if it's
> stored in the DBI interface? :-)
>=20
>=20
> and this will have two types of interfaces. The local interfaces =
that
> transparently gets downloaded and installed. And the remote
> interfaces that use another Service on another server.
>=20
>=20
> The SOAP thing would be just like having an interface to retrieve
> resource properties. Nothing complicated here...
>=20
>=20
>=20
> > "http://uxn.nu/wraf/RDF-Service/doc/html/abbrevation.html"
> >=20
> > "[% person.fn.li.value %]"
> >=20
> > Now you're talking!
>=20
> Yes. :-)
>=20
> And to get the second first name you had in 1980:
>=20
> [% person.fn( date =3D 1980 ).li(2).value %]
>=20
>=20
> But that's not implemented yet...
>=20
>=20
>=20
>=20
>=20
>=20
> RDFS:label
>=20
> Now I must continue hacking. I have a stupid resource that doen't
> want to be saved. It should be because i have put a label on it, and
> that label should be preserved...
>=20
> labels being one of the special cases. Maby it shouldn't be a =
special
> case. Probably shouldn't... But it forces me to sort out =
entrypoints
> for implicit properties. And that will be used by infered properties.
> So this is sort of a small step toward that.
>=20
> http://uxn.nu/wraf/RDF-Service/doc/html/dynamic.html
>=20
>=20
> --=20
> jonas@rit.se RIT AB http://www.rit.se
> Box 70, 428 21 K=E5llered Bes=F6k: G:a Riksv=E4gen 36
> Tel: +46 (0)31 751 8600 Fax: +46 (0)31 751 8609
>=20
>=20
> _______________________________________________
> RDF mailing list
> RDF@uxn.nu
> http://www.uxn.nu/cgi-bin/mailman/listinfo/rdf
>=20
From jonas@rit.se Thu Feb 15 14:03:24 2001
From: jonas@rit.se (Jonas Liljegren)
Date: 15 Feb 2001 15:03:24 +0100
Subject: [RDF] Replication and fault tolerance
Message-ID: <87itmccac3.fsf@jonas.rit.se>
I have been daydreaming a little about how to handle larger amounts of
data, with regard to caching and inferencing.
Caching
In real life, you are most of the time using the expiration
technique. You can get information about something from a computer.
But then you leave the computer, you don't know if the informaiton is
still current. We can't demand that the information is allways
current. The system should be able to automaticly handle and recover
from faulty information.
About diffrent strategies to use current information
1. We know it never changes
2. We check the information on demand and expect it not to change
before we use the infromation
3. Potential information users are contacted then the information
changes
4. The used information is validated against the source before it
gets commited
5. A transitional period is used there the previus information is
still valid. The user can use expiration date without the risk of
using faulty information
6. An exact time for the transition could be announced a period in
advace
7. Changed information can be discoverd and used to correct previuos
data and maby undo actions
Fault tolerance
I don't want a minimalistic approach. The same information can be
stored in many ways. hooks will be set up to relate dependent
information. But mych related information will not have a connection
because you don't know that the information is related until you have
tried it for the relation.
The system will have to handle contradicting information and to
prioritize and sort out things. The process of finding connectins and
sort out unwanted data is done in the pricess of dreaming.
Dreams
A sleep cycle consist of the deep sleep and the dream sleep. In the
deep sleap, the system is normalized. Unreferenced resources gets
flushed out. Equivalent resources gets merged. Containers gets
reorderd. Stuff like that.
The dream sleep is the process of trying out scenarios. A lot of new
connections between the new memories from the day and all things
thought about is tried. New useful connections is kept.
The deep sleep cleans up after the dream. The result from the
previous dream period is used as inut for the next cycle. Intresing
scenarios gets repeated in search for more connections.
Replication
Who should we go to for service then Wraf is sleeping? Two services
could talk to each other. They would be individuals even if they
worked with the same data. Changes would continously be transferd
between the systems to keep them in sync regarding the intresting
matters.
But the important thing is that tey aren't exactly the same. They
will probably be given the same desires. Their dreams will naturally
be similar because they work with the same stuff. But they will not
be identical.
In the morning (or after a vacation) the system will catch up with
what has happend. It will have to resolve problems. Some things maby
has to be undone. The actual update could in itself turn up faults
that will have to be corrected.
Isn't this fun? :-)
--
/ Jonas Liljegren
The Wraf project http://www.uxn.nu/wraf/
Sponsored by http://www.rit.se/
From jonas@rit.se Thu Feb 15 14:12:43 2001
From: jonas@rit.se (Jonas Liljegren)
Date: 15 Feb 2001 15:12:43 +0100
Subject: SV: [RDF] Re: Wraf and Perl6
In-Reply-To:
References:
Message-ID: <87d7ckc9wk.fsf@jonas.rit.se>
Stefan Andersson writes:
> Will you upgrade the Demo to reflect the new possibilities?
:-) Hmm... I haven't changed the version number...
I will test out my current version, bump up the version number and
make a pre-release as 0.0451.
It will include the search form and the abbrevations.
--
/ Jonas Liljegren
The Wraf project http://www.uxn.nu/wraf/
Sponsored by http://www.rit.se/
From jonas@rit.se Thu Feb 15 14:55:15 2001
From: jonas@rit.se (Jonas Liljegren)
Date: 15 Feb 2001 15:55:15 +0100
Subject: [RDF] Wraf v0.0451
In-Reply-To:
References:
Message-ID: <87zofoatd8.fsf@jonas.rit.se>
Ok. I have now tagged Release-v0_0451 and checked it out to the Wraf
demo.
The demo is moved to a demo directory and there is a start to another
demo parallell to the person demo. The templates for the person demo
is here:
http://uxn.nu/wraf/RDF-Service/demo/pers1/bin/tmpl/
--
/ Jonas Liljegren
The Wraf project http://www.uxn.nu/wraf/
Sponsored by http://www.rit.se/
From jonas@rit.se Mon Feb 19 13:01:36 2001
From: jonas@rit.se (Jonas Liljegren)
Date: 19 Feb 2001 14:01:36 +0100
Subject: [RDF] Sorting selections
Message-ID: <87vgq66d3j.fsf@jonas.rit.se>
I started this message two weeks ago. I have prosponed this topic,
but may as well send out this now.
I was thinking about how to sort selections.
Let's say we have four interfaces and asks for resources with a
specific property.
If there are a lot of resources that match the criterion, it would
generate a very large selection. But we may only want to list the
first five.
In order to save time and memory, we only put the criterion in the
selection and doesn't compute the result. Then li($n) is called to
get the $n entry, the selection entry is expanded.
If the selection comes from only one interface, we could let the
interface directly return the $n resource. But because several
interfaces is onvolved, none of the interface know which enty is
number $n. We have to get one by one until we get to $n.
If the ordering isn't important, we could return the objects from one
interface after another. If we request numer 248, and a size()
request to the first interface gives 235, we continue with the next
interface.
But a size() should not have to count all resources if the point is to
know in which interface number 248 resides in.
Dynamic properties could be computed based on many things. If we want
all objects of a specific type, we cant let the backend only retrieve
those resources. anotther interface could say that another class is a
subClassOf that type. It could be very complicated. many selections
would have to be done.
If the order is significant, we have to build an internal list of
resources in the container. If the conteiner is very larg, we don't
want to have the whole list in memory.
We could do some sorts of partial sorting. For example, if we only
want the top three items, we wouldn't have to sort the bottom 9997
items.
--
/ Jonas Liljegren
The Wraf project http://www.uxn.nu/wraf/
Sponsored by http://www.rit.se/
From Stefan.Andersson@ullmans.com Mon Feb 19 13:31:31 2001
From: Stefan.Andersson@ullmans.com (Stefan Andersson)
Date: Mon, 19 Feb 2001 14:31:31 +0100
Subject: SV: [RDF] Sorting selections
Message-ID:
Yo!
Actually, I have been thinking about this issue for some time. I haven't
read anything, though, so supposedly somebody somewhere already have solved
the problem. Oh, well. That won't stop me from thinking loudly for myself:
I was wondering whether this actually is a problem of defining exactly
_what_ you want, not how to pick a certain number more or less randomly.
So, when you say 'I just want _one_ occurence', what do you _really_ say,
i.e. _why_ do you just want one occurence?
And, implicitly, what should we do with the rest of them?
Ok. Maybe banal, maybe naive, but I think resolving the question is so
complex, maybe what you would want to do, is redefine the _question_?
And I have a hunch that the 'dialogue' approach is one way of solving
this...
Just my ha'penny.
/Stefan
> -----Ursprungligt meddelande-----
> Fran: rdf-admin@uxn.nu [mailto:rdf-admin@uxn.nu]For Jonas Liljegren
> Skickat: den 19 februari 2001 14:02
> Till: Wraf development
> Amne: [RDF] Sorting selections
>
>
> I started this message two weeks ago. I have prosponed this topic,
> but may as well send out this now.
>
>
> I was thinking about how to sort selections.
>
> Let's say we have four interfaces and asks for resources with a
> specific property.
>
> If there are a lot of resources that match the criterion, it would
> generate a very large selection. But we may only want to list the
> first five.
>
> In order to save time and memory, we only put the criterion in the
> selection and doesn't compute the result. Then li($n) is called to
> get the $n entry, the selection entry is expanded.
>
> If the selection comes from only one interface, we could let the
> interface directly return the $n resource. But because several
> interfaces is onvolved, none of the interface know which enty is
> number $n. We have to get one by one until we get to $n.
>
> If the ordering isn't important, we could return the objects from one
> interface after another. If we request numer 248, and a size()
> request to the first interface gives 235, we continue with the next
> interface.
>
> But a size() should not have to count all resources if the point is to
> know in which interface number 248 resides in.
>
>
> Dynamic properties could be computed based on many things. If we want
> all objects of a specific type, we cant let the backend only retrieve
> those resources. anotther interface could say that another class is a
> subClassOf that type. It could be very complicated. many selections
> would have to be done.
>
>
> If the order is significant, we have to build an internal list of
> resources in the container. If the conteiner is very larg, we don't
> want to have the whole list in memory.
>
> We could do some sorts of partial sorting. For example, if we only
> want the top three items, we wouldn't have to sort the bottom 9997
> items.
>
>
> --
> / Jonas Liljegren
>
> The Wraf project http://www.uxn.nu/wraf/
> Sponsored by http://www.rit.se/
>
> _______________________________________________
> RDF mailing list
> RDF@uxn.nu
> http://www.uxn.nu/cgi-bin/mailman/listinfo/rdf
>
From jonas@rit.se Fri Feb 23 21:36:05 2001
From: jonas@rit.se (Jonas Liljegren)
Date: 23 Feb 2001 22:36:05 +0100
Subject: [RDF] Progres report
Message-ID: <87r90pt73u.fsf@jonas.rit.se>
I have woked full time on Wraf for some time now. The system
continues to evolve.
I find it relatively easy to discover the existence of bugs in the
system. To find the source of the bugs can, on the other hand be,
quite time consuming. But the system feels stable. And thats nice,
considering the chaos that's going on inside.
I have restructured the jumptables by extracting the dynamic
properties. The value of LS:size and LS:level now looks like ordinary
properties, but are in fact calculated by functions provided by
interfaces. The RDFS:subClassOf should also be a dynamic propertu,
but that's not done yet.
The RDFS:label predicate became a testcase for the connection between
the core and the interface. The DBI interface stores the label in a
special field, apart from other properties. But the core (now)
handles RDFS:label the same as other properties. This wa an important
test, since you should be able to construct an interface using a
custom database for your data.
This change led to some restructuring and simplification of the
declaration and storage system. I think the number of methods has
decreased. And this should also result in some speed increase.
The latest CVS commit is tagged as Release-v0_0452
--
/ Jonas Liljegren
The Wraf project http://www.uxn.nu/wraf/
Sponsored by http://www.rit.se/
From jonas@rit.se Fri Feb 23 22:26:04 2001
From: jonas@rit.se (Jonas Liljegren)
Date: 23 Feb 2001 23:26:04 +0100
Subject: [RDF] The model of dynamic properties
Message-ID: <87n1bdt4sj.fsf@jonas.rit.se>
The latest bug in Wraf is the reason for this post.
It manifests as an undefined value of LS:level in the Person Demo.
LS:level is a dynamic property. It was previously a method provided
by the Base interface:
http://uxn.nu/wraf/RDF-Service/doc/html/api/RDF/Service/Interface/Base/V01.html#level()
The problem occures during the schema initialization (triggerd by a
link in the Demo). It defines the Person to be a class:
sub do_initiate_db
{
my $model = $s->get_model(NS_LD.'#M1');
$model->get(NS_LD.'/Class#Person')->set( [NS_RDFS.'Class'] );
$model->get(NS_LD.'/Property#first_name')->set( [NS_RDF.'Property'] );
$model->get(NS_LD.'/Property#last_name')->set( [NS_RDF.'Property'] );
return "DB initiated";
}
The set() method completely defines the resource. If the resource
currently has other properties, they are removed. but properties
defined in other models should not be removed.
During the process of set(), the Person resource is initialized (ie,
set up with the properties returned from the interfaces). The
LS:level property is initialized to '1'.
But this propery is shortly after removed, because it's not specified
by set(). (The Person set() above only sets the type to RDFS:Class.)
This is allowed since the statement is created in the working model
(ie, LD:#M1).
Of, course, you should never be allowed to remove dynamic
properties. They should only be modified by their dependencies.
But now for the 'question'
..........................
This raised for me the question of what the model for the dynamic
properties should be. Who is stating the statement? It's a
combination of:
- The model of the program code
- The model of all data used as input
My previous thought, if I remember, was to create a custom model for
the specific combination, and put the data about the involved models
as metadata for that model.
I think that the agent property of the model will be used as a base
for trust. For dynamic properties, a group could be used as agent.
The first time the group is encounterd, we could check each agent.
But then we could trust the group. That would mean that the agent
would be a bag of agents.
Should every dynamic property be placed in a unique model? Or should
we group properties that has identical metadata, maby within the same
session? But the session doesn't have a clear connection to the
dynamic properties, other than maby as the model for a part of the
source data. Ah, thats it! A new session results in a new source
model and a new dynamic model.
Thank you for your time! ;-)
--
/ Jonas Liljegren
The Wraf project http://www.uxn.nu/wraf/
Sponsored by http://www.rit.se/
From jonas@rit.se Mon Feb 26 10:37:20 2001
From: jonas@rit.se (Jonas Liljegren)
Date: 26 Feb 2001 11:37:20 +0100
Subject: [RDF] v0.0453
Message-ID: <877l2dzq5b.fsf@jonas.rit.se>
I have optimized the storage a bit. The node LOCAL slot remebers
uniquely generated URIs thats guaranteed not to have information in
interfaces. There is also a check during storage to not access the
interfaces if there isn't anything that needs to be stored. This
reduces the amount of DBI access.
I have introduced a Dynamic_Model to place all dynamic properties in.
Until the time we implement the full metadata for dynamic models.
The autorization check for edit and delete seems to be broken... The
demo uses 0.0453 now. For some reason, the demo wasn't running
resently. i couldn't find an error in the log. If you manage to
crach it, please report what you did. :) Or I will increase the debug
level to 3 or 4...
My plan for v0.05 is to have a little more search functionality and
maby implement the dependency check for the dynamic properties.
--
/ Jonas Liljegren
The Wraf project http://www.uxn.nu/wraf/
Sponsored by http://www.rit.se/
From jonas@rit.se Thu Mar 1 11:35:00 2001
From: jonas@rit.se (Jonas Liljegren)
Date: 01 Mar 2001 12:35:00 +0100
Subject: [RDF] DAML+OIL for queries
Message-ID: <87lmqp90yj.fsf@jonas.rit.se>
Can DAML+OIL be used for declaring wanted resources?
Maby by defining a class, and saying that it's members must have
specific properties? Or that it should have either this or that
property, but not both?
I am now looking back on some thoughts on how to represent questions
in RDF. I am inclined to use the model of asking questions by
describing the thing you search for.
You describe X by its properties and types. You may say that it's
either this or that.
Let's say you are describing a trafic light. You say that X is a
thing that is either red or green or yellow (in Sweden). This is a
description of a thing with a colour property that alterate over time.
It would be another thing to talk about something there the property
is constant, but you are not sure on it. X is a ball and it is either
red or blue.
A RDF service should answer the question by saying that the thing
described has the same properties as this list of resources. The list
will be diffrent if you are searching for things that has=A0one of the
properties (as the ball), or things that could have all of the
properties (as with the trafic light). And you could also say things
that it will not have. Maby you describe two colours of the thing and
imples that it does not have more than those two colours.
What I want to say:
A question can also be a description using a bag of statements. The
description could be about a hypothetical object, or it could be about
a collection of objects. By letting the service find aliases, you
don't have to use any type of variables.
Has anyone here a suggestions on how to write those descriptions? You
basicly have to insert a way to add ORs and NOTs. AND is the
default. Is it a good idea to use DAML+OIL for this?
--=20
/ Jonas Liljegren
The Wraf project http://www.uxn.nu/wraf/
Sponsored by http://www.rit.se/
From jonas@rit.se Thu Mar 1 18:35:55 2001
From: jonas@rit.se (Jonas Liljegren)
Date: 01 Mar 2001 19:35:55 +0100
Subject: [RDF] Cookie problem
Message-ID: <87snkxcp6c.fsf@jonas.rit.se>
I think I know what the problem is.
The cookie is set by the usertrack apach module. It will set the
cookie with the return of the first page.
But if that first page was expecting the cookie, it would not get it.
I guess that means that we must set the usertrack cookie ourself...
--
/ Jonas Liljegren
The Wraf project http://www.uxn.nu/wraf/
Sponsored by http://www.rit.se/
From der@hplb.hpl.hp.com Fri Mar 2 13:42:15 2001
From: der@hplb.hpl.hp.com (Dave Reynolds)
Date: Fri, 02 Mar 2001 13:42:15 +0000
Subject: [RDF] Re: DAML+OIL for queries
References: <87lmqp90yj.fsf@jonas.rit.se>
Message-ID: <3A9FA337.BF7EC8FD@hplb.hpl.hp.com>
> Can DAML+OIL be used for declaring wanted resources?
I believe so. In particular DAML+OIL are based on the notion of
description logics and there has been work done in using description
logics to specify queries in deductive database systems. A good overview
paper that I found helpful in understanding the area was "Description
Logics in Data Management", Alex Borgida, IEEE Trans Knowledge and Data
Eng, 7, #5, Oct 95. Doubtless there is more recent work in the area.
> Has anyone here a suggestions on how to write those descriptions? You
> basicly have to insert a way to add ORs and NOTs. AND is the
> default.
I may be misunderstanding the question but while "AND" is sort-of the
default for the RDF assertions, DAML+OIL is richer. Taking the approach of
treating DAML+OIL as specifying descriptions then the unionOf,
intersectionOf, complementOf properties give you AND, OR and NOT. You
could generate a description of the things you are trying to retrieve
using these properties and then have a reasoner/database retrieve those
objects which are instances of your specified class.
I confess to being new to description logics and DAML so if my assumptions
that it all fits together this way are wrong then please correct me!
Dave
------------------------------------------------------------------
Hewlett-Packard Laboratories | Phone: +44-117-3128165
Filton Road, Stoke Gifford | FAX: +44-117-3128925
Bristol BS34 8QZ, UK | dave_reynolds@hpl.hp.com
From jonas@rit.se Fri Mar 2 18:15:32 2001
From: jonas@rit.se (Jonas Liljegren)
Date: 02 Mar 2001 19:15:32 +0100
Subject: [RDF] Re: DAML+OIL for queries
References: <87lmqp90yj.fsf@jonas.rit.se> <3A9FA337.BF7EC8FD@hplb.hpl.hp.com>
Message-ID: <87ae74avgb.fsf@jonas.rit.se>
I would first like to apology for my confused posting. I should have
hold back one day more. My understanding of DAML is now much better.
I have now found that searches can be done by defining a class. The
search result will be the resources belonging to that class.
One search form I am experimenting with is intended for finding object
bleonging to one or more of the selected classes.
In hidden fields in the search form, I put statements equivalent of:
And the list of searchable classes, using Template Toolkit (for Perl),
simplified:
[% FOREACH type = types %]
[% type.label.value %]
[% END %]
On Submit, the new statements is inserted in the RDF space. The
container content is determined by the chosed checkboxes.
The search result page simply views the objects for the class #gen1,
simplified:
[% FOREACH object = query.rev_type.list %]
[% object.label.value %]
[% END %]
I guess that this will work for any type of search criterions. I
think that I can find a way to include substring searches by just
creating dynamic substring properties for the resources.
All this, within the Wraf project:
http://uxn.nu/wraf/
The templates above are a temporary solution. We will later crate a
presentation layer in RDF using semantic presentation components, as a
part of the agent/server conversation (session) context.
Dave Reynolds writes:
> > Has anyone here a suggestions on how to write those descriptions?
> > You basicly have to insert a way to add ORs and NOTs. AND is the
> > default.
>
> I may be misunderstanding the question but while "AND" is sort-of the
> default for the RDF assertions, DAML+OIL is richer.
It seems to me that AND is default also for DAML+OIL. I read about
boolean combinations in:
http://www.daml.org/2000/12/reference.html#Class
The class C must be equivalent to the class defined by each of the
boolean class expression,
I would have prefered this to be clearer. But I guess that this means
that if I have:
it would be equivalent to:
Is this correct?
> Taking the approach of treating DAML+OIL as specifying descriptions
> then the unionOf, intersectionOf, complementOf properties give you
> AND, OR and NOT. You could generate a description of the things you
> are trying to retrieve using these properties and then have a
> reasoner/database retrieve those objects which are instances of your
> specified class.
Yes. That's what I found out after I actually read the documents and
examples. :-)
--
/ Jonas Liljegren
The Wraf project http://www.uxn.nu/wraf/
Sponsored by http://www.rit.se/
From timbl@w3.org Wed Mar 7 04:12:36 2001
From: timbl@w3.org (Tim Berners-Lee)
Date: Tue, 6 Mar 2001 23:12:36 -0500
Subject: [RDF] Re: DAML+OIL for queries
References: <87lmqp90yj.fsf@jonas.rit.se> <3A9FA337.BF7EC8FD@hplb.hpl.hp.com> <87ae74avgb.fsf@jonas.rit.se>
Message-ID: <01f401c0a6bc$e314d670$c1defea9@CREST>
What N3 does is to use RDF (including RDF+OIL) as queries.
A simple query, as you suggest, can be just a DAML expression to match.
You need a way of clarifying which are variables.
More comples queries need plain DAML to be extended to contain
nested formulae. The N3 experiment was aimed at seeing whther you could
smoothly integrate forumlae on top of DAML and it seems to work.
But you might decide you prefer to switch to lisplike syntax as it gets more
formula-like and less data-like.
tim
----- Original Message -----
From: "Jonas Liljegren"
To: "Dave Reynolds"
Cc: ; "Wraf development"
Sent: Friday, March 02, 2001 1:15 PM
Subject: Re: DAML+OIL for queries
> I would first like to apology for my confused posting. I should have
> hold back one day more. My understanding of DAML is now much better.
>
>
>
> I have now found that searches can be done by defining a class. The
> search result will be the resources belonging to that class.
>
>
> One search form I am experimenting with is intended for finding object
> bleonging to one or more of the selected classes.
>
> In hidden fields in the search form, I put statements equivalent of:
>
>
>
>
> And the list of searchable classes, using Template Toolkit (for Perl),
> simplified:
>
>
> [% FOREACH type = types %]
>
> [% END %]
>
>
>
> On Submit, the new statements is inserted in the RDF space. The
> container content is determined by the chosed checkboxes.
>
>
> The search result page simply views the objects for the class #gen1,
> simplified:
>
>
> [% FOREACH object = query.rev_type.list %]
>
> [% object.label.value %]
>
> [% END %]
>
>
>
>
>
> I guess that this will work for any type of search criterions. I
> think that I can find a way to include substring searches by just
> creating dynamic substring properties for the resources.
>
>
> All this, within the Wraf project:
>
> http://uxn.nu/wraf/
>
>
>
> The templates above are a temporary solution. We will later crate a
> presentation layer in RDF using semantic presentation components, as a
> part of the agent/server conversation (session) context.
>
>
>
>
> Dave Reynolds writes:
>
> > > Has anyone here a suggestions on how to write those descriptions?
> > > You basicly have to insert a way to add ORs and NOTs. AND is the
> > > default.
> >
> > I may be misunderstanding the question but while "AND" is sort-of the
> > default for the RDF assertions, DAML+OIL is richer.
>
> It seems to me that AND is default also for DAML+OIL. I read about
> boolean combinations in:
> http://www.daml.org/2000/12/reference.html#Class
>
> The class C must be equivalent to the class defined by each of the
> boolean class expression,
>
> I would have prefered this to be clearer. But I guess that this means
> that if I have:
>
>
>
>
>
>
>
>
>
>
>
>
> it would be equivalent to:
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Is this correct?
>
>
>
>
> > Taking the approach of treating DAML+OIL as specifying descriptions
> > then the unionOf, intersectionOf, complementOf properties give you
> > AND, OR and NOT. You could generate a description of the things you
> > are trying to retrieve using these properties and then have a
> > reasoner/database retrieve those objects which are instances of your
> > specified class.
>
> Yes. That's what I found out after I actually read the documents and
> examples. :-)
>
> --
> / Jonas Liljegren
>
> The Wraf project http://www.uxn.nu/wraf/
> Sponsored by http://www.rit.se/
>
From jonas@rit.se Mon Mar 12 08:04:53 2001
From: jonas@rit.se (Jonas Liljegren)
Date: 12 Mar 2001 09:04:53 +0100
Subject: [RDF] World modelling
Message-ID: <87hf0z1kgq.fsf@jonas.rit.se>
My intret in RDF is in part my intrest to model the world. This
modelling is also done in classic RPGs and in games.
This MUD has a kind of intresting model, talking about fractals and
emergent behaviours. I'm reading this section:
http://docs.FaerieMUD.org/bin/view/Dream/ThePattern
It resembles a bit the the heiarcies described by Ken Wilber.
And one author also talks about using WordNet... :)
--
/ Jonas Liljegren
The Wraf project http://www.uxn.nu/wraf/
Sponsored by http://www.rit.se/
From jonas@rit.se Mon Mar 12 15:16:47 2001
From: jonas@rit.se (Jonas Liljegren)
Date: 12 Mar 2001 16:16:47 +0100
Subject: [RDF] GET and POST RDF with HTML forms
Message-ID: <87ae6r10gw.fsf@jonas.rit.se>
In Wraf [1], we will build a presentation system there the
presentation logic is stored in RDF. This builds on a concept for the
session, that in turn builds on a query language.
I have recently discussed this with Stefan, and I have also reviewd
some earlier discussions on the subject from last year.
The goal is to find a way to create a web application for a knowledge
community:
http://uxn.nu/wraf/RDF-Service/doc/html/hdc.html
A generic session is any type of communication between two agents.
But the focus here is the session that consists of people using web
browsers to communicate with the service through a HTML interface.
The session consists of information requests and information
presentation. The 'user' will ask for specific information and many
times also give information.
The simplest way to request information is to just ask for a specific
resource, as with a normal URL. The answer to the question depends on
the context. The context will consist of HTTP request metadata and
the session. The session will often hold the identity of the user and
the users preferences. It tells the service to give the answer in
HTML form and to give an answer of 'medium length'.
We would like to use the semantics of http GET and POST. GET is for
requesting information and POST is for submitting information. The
PATH specifies the focus resource. The QUERYSTRING part can be used
as a presentation modifier.
We are here looking for a way to ask question using HTTP. Simple
question should just use the URL. But what will more complex
questions look like? Questions could maby look like:
http://give.me/person/jonas_liljegren
http://give.me/person/jonas_liljegren/intrests
http://give.me/person/liljegren/intrest/RDF
http://give.me/person/jonas/thoughts_about/RDF/related_to/AI
http://give.me/AI/related_to/RDF/according_to/jonas
http://give.me/liljegren_j.html
http://give.me/persons?order_by=last_name
http://give.me/liljegren_j?mode=edit
The URL is here just a type of query. It has no relation to physical
storage of the information. The actual information could even be
stored on another server. But the server part says something about
the authority of the answer.
The point here is to let the service try to answer every GET request.
The URLs should be easy to remember. Old URLs should work even after
reorganisations of the material.
The URL parser will mainly work by mapping path segments to resource
labels. The focus resource is identified by the whole path. If the
first segment is a predicate, the next segment is taken to be the
object of the resource property. The remaining segments is parsed to
add more restrictions to the query. If a segment is a class, the
resource will be of that type. The following segment can be a
subclass of the class or another class. The whole URL could also
match a known resource URL.
The request URL will create a new resource representing the answer to
the parsed question. This resource could take the form of a DAML
class, defining the criterions for class membership.
The dot-extension will, if existing, be taken as the prefered response
format. It could for example be html, xhtml, rdf or txt. The
http ACCEPT metadata should also be used.
The presentation of the answer will be formatted according to the
number of matched resources, the specific criterions and the session
context. With only one matching resource, it will probably be
displayed in whole. With several matches, there will probably be a
list of answers.
If you ask for a person phone number, but the service finds two
persons with the same name, the service will have to ask for more
information about which person you are refering to. If the
alternatives are few, this counterquestion is best put in the form of
a list of options. For a larger amount of alternatives, a list of
classes could be presented, or you could just be asked to give more
specific criterions. This makes up the steps of refining a query;
from list to item to subitem.
The POST part has been detaild in a previous posting. It's basicly
about submitting new statements. The statements could be said to be
related to the URL if nothing else is explicitly specified.
HTML FORMS
Stefan proposed that the HTML form itself should be a resource that
gives metadata for all the fields. Every time a form is to be filled
out, it gets a unique resourse, as an instance of the specific form
class. Each field is a resource containing data about what is valid
data and how the field value will be inteprated. Some values could
be translated to statements and other values could be used as
metainformation for the submitted data. The fild names would be the
URIs for the resources.
The form data is stored as properties for the unique form resource.
This data is translated into new statements by some "parser" specified
by the metadata for the form class. In most cases, the original raw
form data will soon expire into oblivion.
[1] http://www.uxn.nu/wraf/
--
/ Jonas Liljegren
The Wraf project http://www.uxn.nu/wraf/
Sponsored by http://www.rit.se/
From jonas@rit.se Tue Mar 13 14:19:13 2001
From: jonas@rit.se (Jonas Liljegren)
Date: 13 Mar 2001 15:19:13 +0100
Subject: [RDF] Comments on N3 and its use for writing rules
In-Reply-To: <01f401c0a6bc$e314d670$c1defea9@CREST>
References: <87lmqp90yj.fsf@jonas.rit.se> <3A9FA337.BF7EC8FD@hplb.hpl.hp.com>
<87ae74avgb.fsf@jonas.rit.se> <01f401c0a6bc$e314d670$c1defea9@CREST>
Message-ID: <87wv9tn44e.fsf_-_@jonas.rit.se>
I have now read these pages of yours:
http://www.w3.org/DesignIssues/Notation3.html
http://www.w3.org/DesignIssues/Anonymous.html
http://www.w3.org/2000/10/swap/Primer.html
There is a lot on inconsistencys. Both <#g> and '#g' and :g is used.
But <#g> is not defiend in the BNF. I guess you have replaced '' with
<>.
I also guess that the dot at the end inside {} is optional.
EXPLOSION OF NESTED MODELS
(I am using the word model[1], since I have put a diffrent meaning in
the word context[7].)
I would like to comment on the last part of the Primer:
<> log:forAll :p, :q.
{ :p ont:inverse :q } log:implies
{
{
{ :x :p :y } log:implies { :y :q :x }
} a log:Truth; log:forAll :x, :y.
}.
And Now blow it to pieces, using the format "Model Stating[2]
Subject Predicate Object" (Triple, quad, whats next? penta something?)
C00 S01 C00 log:forAll :p
C00 S02 C00 log:forAll :q
C01 S03 :p ont:inverse :q
C02 S04 :x :p :y
C03 S05 :y :q :x
C04 S06 C02 log:implies C03
C05 S07 C04 rdf:type log:Truth
C05 S08 C04 log:forAll :x
C05 S09 C04 log:forAll :y
C00 S10 C01 log:implies C05
That log:Truth statement got me thinking. Let's consider your first
rule of models: "The statements are all independent, in that you can
remove any of the statements and the rest are still true".
What happens if we kill S07? We would still have the statements S08
and S09. Can't we implicitly say that C4 is true for all :x and :y?
Ok. Maby not.
Now, let us see this thing in action. We start by Inserting some
seeds in the system. Here we declare our trust in the infered
statements [3], here placed in L01:
C11 S11 C00 rdf:type log:Truth
C11 S12 :child ont:inverse :parent
C11 S13 :agnus :child :bengt
C11 S14 L01 rdf:type log:Truth
And now press GO!
R01 L01->imports( C11 )
R02 L01->imports( C00 )
R03 L01->state( :p, rdf:type, log:variable )
R04 L01->state( :q, rdf:type, log:variable )
R05 L02 = L01->eval( C01 )
R06 L01->find( *, ont:inverse, * )
R07 L01->state( :p, =, :child )
R08 L01->state( :q, =, :parent )
R09 L01->imports( C05 )
R10 L01->state( :x, rdf:type, log:variable )
R11 L01->state( :y, rdf:type, log:variable )
R12 L03 = L01->eval( C04 )
R13 L04 = L01->eval( C02 )
R14 L01->find( *, :child, * )
R15 L01->state( :x, =, :agnus )
R16 L01->state( :y, =, :bengt )
R17 L03->imports( C03 )
R18 L03->state( :bengt, :parent, :agnus )
R19 L01->imports( L03 )
Ok. That seems to work. :)
This was just some pseudocode I invented as I wrote it. The L01-L04 is
models produced by the inference function. R01-R19 are just row
numbers. The L01->f() syntax is for specifying in which model the
function operates. See the Wraf API [4].
I was trying to find out for myself if we could keep the models
separated as in your example with an inner and outer model.
In Wraf, I will mostly use inverse inference. I will start with the
sought after property and determine its value. We just have to turn
the logic functions outside in.
BINDING QUANTIFIERS
I don't think it's necessary to bind quantifiers to a specific
model. All statings already are in a model. Look at S01 and
S02 above. You don't have to say the same thing twice. log:forAll is
not a binary predicate.
I suggest we declare them as special types of variables:
log:Variable rdf:type rdfs:Class.
log:ForAll rdfs:subClassOf log:Variable.
UNIVERSAL
I don't think it is meaningful to say in what model a resource is a
variable and in what model it isn't. The result would be the same
if you said:
<> log:forAll :p, :q, :x, :y.
{ :p ont:inverse :q } log:implies
{
{ :x :p :y } log:implies { :y :q :x }
}.
Or, treating them as variables:
my:revtype ont:inverse rdf:type.
log:ForAll my:revtype :p, :q, :x, :y.
{ :p ont:inverse :q } log:implies
{
{ :x :p :y } log:implies { :y :q :x }
}.
Hehe. And thats Yet Another Recursive Dependency (YARD). ;-)
EXISTENTIAL
So, what about log:forSome ? In the Notation3 page under #quoting,
you give the example:
{
[x:firstname "Ora"] dc:wrote [dc:title "Moby Dick"]
} a n3:falsehood .
And you give this translation (model, stating, p, s, o ):
#c1 #s1 n3:forSome #c1 #g1
#c1 #s2 x:firstname #g1 "Ora"
#c1 #s3 n3:forSome #c1 #g2
#c1 #s4 dc:wrote #g1 #g2
#c1 #s5 dc:title #g2 "Moby Dick"
doc #s6 n3:forSome doc #c1
doc #s7 n3:subExpression doc #c1
doc #s8 rdf:type #c1 n3:falsehood
Hum... I don't agree with #s6. The model #c1 says that there exist
some #g1 and #g2 such that #g1 wrote #g2. #s8 negates that. #s6
doesn't make sense. #c1 is an generated resource. But it's properties
is fully defined. #c1 is not a variable.
Futher, there is no need for #s7.
We can write back the remaining statings in n3, using the method from
above:
n3:ForSome my:revtype :g1, :g2.
:c1 =
{
:g1 x:firstname "Ora".
:g1 dc:wrote :g2.
:g2 dc:title "Moby Dick".
} a n3:falsehood .
BOTH UNIVERSAL AND EXISTENTIAL
Notation3 page section #quantification gives this example:
{{:g :loves :h} log:forSome :g} log:forAll :h.
My nonattached version is ambigous:
:g a log:ForSome.
:h a log:forAll.
:g :loves :h.
:g and :h is variables. Let me rewrite a bit:
:g a log:ForSome.
:h a log:forAll.
:h log:implies { :g :loves :h }.
Now, that takes care of it. And for the other direction:
:g a log:ForSome.
:h a log:forAll.
:g log:implies { :g :loves :h }.
Now, a lone resource is here taken to mean "{ :g a rdfs:Resource}".
But we would usually say something more about the resource. Probably
this:
:g a log:ForSome.
:h a log:forAll.
{:h a ont:Person} log:implies { :g :loves :h }.
THE MODEL FOR INFERED STATINGS
The Notation3 page introduces the log:parsesTo predicate. I don't
like that name.
The thing here is that we in some way declare our trust[5] in a) source
data and b) a inference service[6]. When we ask the service to find some
infered data for us, we tell it what sources we trust. We resulting
statings is placed in a separate model.
This resulting model should have metadata saying that it is infered
data, and the inference service and source data used. The same source
model can be used in many inference models and the same inference
model can use many sources.
Let the model with the infered statings declare its sources. If we
wan't we can state the trust in the resulting data.
[1] http://uxn.nu/wraf/RDF-Service/doc/html/model.html
[2] http://uxn.nu/wraf/RDF-Service/doc/html/stating.html
[3] http://uxn.nu/wraf/RDF-Service/doc/html/inference.html
[4] http://uxn.nu/wraf/RDF-Service/doc/html/api.html
[5] http://uxn.nu/wraf/RDF-Service/doc/html/trust.html
[6] http://uxn.nu/wraf/RDF-Service/doc/html/service.html
[7] http://uxn.nu/wraf/RDF-Service/doc/html/context.html
--
/ Jonas Liljegren
The Wraf project http://www.uxn.nu/wraf/
Sponsored by http://www.rit.se/
From Stefan.Andersson@ullmans.com Tue Mar 13 15:25:21 2001
From: Stefan.Andersson@ullmans.com (Stefan Andersson)
Date: Tue, 13 Mar 2001 16:25:21 +0100
Subject: SV: [RDF] World modelling
Message-ID:
Way!
Have these guys [1] been smoking a lot of naughty herbs?
/Stefan
[1] http://docs.FaerieMUD.org/bin/view/Dream/ThePattern
> -----Ursprungligt meddelande-----
> Fran: rdf-admin@uxn.nu [mailto:rdf-admin@uxn.nu]For Jonas Liljegren
> Skickat: den 12 mars 2001 09:05
> Till: Wraf development
> Amne: [RDF] World modelling
>
>
> My intret in RDF is in part my intrest to model the world. This
> modelling is also done in classic RPGs and in games.
>
> This MUD has a kind of intresting model, talking about fractals and
> emergent behaviours. I'm reading this section:
>
> http://docs.FaerieMUD.org/bin/view/Dream/ThePattern
>
>
> It resembles a bit the the heiarcies described by Ken Wilber.
>
>
>
> And one author also talks about using WordNet... :)
>
> --
> / Jonas Liljegren
>
> The Wraf project http://www.uxn.nu/wraf/
> Sponsored by http://www.rit.se/
>
> _______________________________________________
> RDF mailing list
> RDF@uxn.nu
> http://www.uxn.nu/cgi-bin/mailman/listinfo/rdf
>
From jonas@rit.se Wed Mar 14 14:27:35 2001
From: jonas@rit.se (Jonas Liljegren)
Date: 14 Mar 2001 15:27:35 +0100
Subject: [RDF] Stand alone server
Message-ID: <871ys0l92g.fsf@jonas.rit.se>
For a implementation of the mapping of the URL path to resource
queries, I think it would be better to don't use Apache at all.
The two existing demos only packs the incomming data into a string and
sends it over to the server. The client part doesn't know anything
about RDF.
Since the service will handle everything in a way diffrent from
filebased web servers, I don't think we have much to win in using
Apache.
I haven't yet found hellper modules for this. But there should exist
a perl HTTP server somewhere.
The basic functionality is very easy to write.
--
/ Jonas Liljegren
The Wraf project http://www.uxn.nu/wraf/
Sponsored by http://www.rit.se/
From christine@trafficmagnet.net Thu Mar 15 12:41:13 2001
From: christine@trafficmagnet.net (Christine Hall)
Date: Thu, 15 Mar 2001 20:41:13 +0800
Subject: [RDF] UXN.NU
Message-ID: <200103151241.UAA17033@ns2.trafficmagnet.net>
Hello,
I visited
uxn.nu
and I
noticed that you are not listed on some search engines. I am sure you can
increase the number of people who visit
uxn.nu
. Do you know TrafficMagnet? TrafficMagnet is a unique technology that automatically submits your
web site to over 300,000+ search engines and directories every month. This is a
very low-cost and effective way of advertising your site.
From timbl@w3.org Fri Mar 16 22:37:24 2001
From: timbl@w3.org (Tim Berners-Lee)
Date: Fri, 16 Mar 2001 17:37:24 -0500
Subject: [RDF] Re: Comments on N3 and its use for writing rules
References: <87lmqp90yj.fsf@jonas.rit.se> <3A9FA337.BF7EC8FD@hplb.hpl.hp.com><87ae74avgb.fsf@jonas.rit.se> <01f401c0a6bc$e314d670$c1defea9@CREST> <87wv9tn44e.fsf_-_@jonas.rit.se>
Message-ID: <043201c0ae69$ac7ce800$84001d12@w3.org>
----- Original Message -----
From: "Jonas Liljegren"
To: "Tim Berners-Lee"
Cc: "Dave Reynolds" ; ; "Wraf
development"
Sent: Tuesday, March 13, 2001 9:19 AM
Subject: Comments on N3 and its use for writing rules
> I have now read these pages of yours:
> http://www.w3.org/DesignIssues/Notation3.html
> http://www.w3.org/DesignIssues/Anonymous.html
> http://www.w3.org/2000/10/swap/Primer.html
>
> There is a lot on inconsistencys. Both <#g> and '#g' and :g is used.
> But <#g> is not defiend in the BNF. I guess you have replaced '' with
> <>.
Ooops. Excuse me. I changed '' to <> a long time ago but eth BNF is still
wrong
It should 9and now does) read:
uri-ref2
qname
< URI-Reference >
> I also guess that the dot at the end inside {} is optional.
True. In the production for statementlist the dot is used as a separtor.
It isn't introdued that way in the primer. There are many ways yu can write
N3 which are not introduced in the primer, as the primer's goal is to get
people
unconfused and expressing themselves as fast as possible.
>
>
>
>
> EXPLOSION OF NESTED MODELS
>
> (I am using the word model[1], since I have put a diffrent meaning in
> the word context[7].)
OK
> I would like to comment on the last part of the Primer:
>
> <> log:forAll :p, :q.
> { :p ont:inverse :q } log:implies
> {
> {
> { :x :p :y } log:implies { :y :q :x }
> } a log:Truth; log:forAll :x, :y.
> }.
>
> And Now blow it to pieces, using the format "Model Stating[2]
> Subject Predicate Object" (Triple, quad, whats next? penta something?)
>
> C00 S01 C00 log:forAll :p
> C00 S02 C00 log:forAll :q
> C01 S03 :p ont:inverse :q
> C02 S04 :x :p :y
> C03 S05 :y :q :x
> C04 S06 C02 log:implies C03
> C05 S07 C04 rdf:type log:Truth
> C05 S08 C04 log:forAll :x
> C05 S09 C04 log:forAll :y
> C00 S10 C01 log:implies C05
>
>
> That log:Truth statement got me thinking. Let's consider your first
> rule of models: "The statements are all independent, in that you can
> remove any of the statements and the rest are still true".
That only applies to models which are true. It is a property of
"and" which is the operator connecting the statements.
It does not hold in a negated model or a model on the left hand
side of an implication, or a formula in general.
> What happens if we kill S07? We would still have the statements S08
> and S09. Can't we implicitly say that C4 is true for all :x and :y?
No, that is not the way I defined forAll, as for example I don't want to
imply truth in a condition on the left of log:implies.
> Ok. Maby not.
>
>
>
> Now, let us see this thing in action. We start by Inserting some
> seeds in the system. Here we declare our trust in the infered
> statements [3], here placed in L01:
>
> C11 S11 C00 rdf:type log:Truth
> C11 S12 :child ont:inverse :parent
> C11 S13 :agnus :child :bengt
> C11 S14 L01 rdf:type log:Truth
>
>
> And now press GO!
>
> R01 L01->imports( C11 )
> R02 L01->imports( C00 )
> R03 L01->state( :p, rdf:type, log:variable )
> R04 L01->state( :q, rdf:type, log:variable )
> R05 L02 = L01->eval( C01 )
> R06 L01->find( *, ont:inverse, * )
> R07 L01->state( :p, =, :child )
> R08 L01->state( :q, =, :parent )
> R09 L01->imports( C05 )
> R10 L01->state( :x, rdf:type, log:variable )
> R11 L01->state( :y, rdf:type, log:variable )
> R12 L03 = L01->eval( C04 )
> R13 L04 = L01->eval( C02 )
> R14 L01->find( *, :child, * )
> R15 L01->state( :x, =, :agnus )
> R16 L01->state( :y, =, :bengt )
> R17 L03->imports( C03 )
> R18 L03->state( :bengt, :parent, :agnus )
> R19 L01->imports( L03 )
>
> Ok. That seems to work. :)
>
> This was just some pseudocode I invented as I wrote it. The L01-L04 is
> models produced by the inference function. R01-R19 are just row
> numbers. The L01->f() syntax is for specifying in which model the
> function operates. See the Wraf API [4].
>
> I was trying to find out for myself if we could keep the models
> separated as in your example with an inner and outer model.
>
>
> In Wraf, I will mostly use inverse inference. I will start with the
> sought after property and determine its value. We just have to turn
> the logic functions outside in.
yes. That will be interesting to see the same rules being used in
forward chaining and backward chaining.
> BINDING QUANTIFIERS
>
> I don't think it's necessary to bind quantifiers to a specific
> model. All statings already are in a model. Look at S01 and
> S02 above. You don't have to say the same thing twice. log:forAll is
> not a binary predicate.
On the contrary, you must specify the scope of a quantifier.
Compare (in lispy syntax):
(exists (x)
(forall (y)
(loves x y)))
with:
(forall (y)
(exists (x)
(loves x y)))
The type of quantification going on is the same in each case but the
scoping is different and the mean ing is quite different
(There is somebody who loves everybody, vs every person is loved by someone)
> I suggest we declare them as special types of variables:
>
> log:Variable rdf:type rdfs:Class.
> log:ForAll rdfs:subClassOf log:Variable.
If you use type, and you don't use a special property which links to the
context,
then you are saying something about the thing, not the variable. It
doesn't work.
You need to break out of the logic, adding something new. You can't overload
type with this.
>
> UNIVERSAL
>
> I don't think it is meaningful to say in what model a resource is a
> variable and in what model it isn't. The result would be the same
> if you said:
>
> <> log:forAll :p, :q, :x, :y.
> { :p ont:inverse :q } log:implies
> {
> { :x :p :y } log:implies { :y :q :x }
> }.
Yes, it would. My software would not (I think) do
the right thing with this - I haven't written code
to handle left over universals in the conclusion.
@@
> Or, treating them as variables:
>
> my:revtype ont:inverse rdf:type.
> log:ForAll my:revtype :p, :q, :x, :y.
> { :p ont:inverse :q } log:implies
> {
> { :x :p :y } log:implies { :y :q :x }
> }.
>
> Hehe. And thats Yet Another Recursive Dependency (YARD). ;-)
>
>
>
> EXISTENTIAL
le me say straight off thatthere is a bug with the tripples representation
I use for forSome.
> So, what about log:forSome ? In the Notation3 page under #quoting,
> you give the example:
>
> {
> [x:firstname "Ora"] dc:wrote [dc:title "Moby Dick"]
> } a n3:falsehood .
>
> And you give this translation (model, stating, p, s, o ):
>
> #c1 #s1 n3:forSome #c1 #g1
> #c1 #s2 x:firstname #g1 "Ora"
> #c1 #s3 n3:forSome #c1 #g2
> #c1 #s4 dc:wrote #g1 #g2
> #c1 #s5 dc:title #g2 "Moby Dick"
> doc #s6 n3:forSome doc #c1
> doc #s7 n3:subExpression doc #c1
> doc #s8 rdf:type #c1 n3:falsehood
>
>
> Hum... I don't agree with #s6. The model #c1 says that there exist
> some #g1 and #g2 such that #g1 wrote #g2. #s8 negates that. #s6
> doesn't make sense. #c1 is an generated resource. But it's properties
> is fully defined. #c1 is not a variable.
Yes, that "forSome" statement was put there to tell the code that
c1 was a variable, existentially qualified, with scope doc.
> Futher, there is no need for #s7.
True, that has been removed from the code and that page now.
Thanks for pointing it out.
> We can write back the remaining statings in n3, using the method from
> above:
>
> n3:ForSome my:revtype :g1, :g2.
[[[ yes .. I keep wanting revtype. You know you can say in N3
n3:ForSome is rdf:type of :g1 , :g2.
The reverse syntax was introduced just for this. I'm also toying
with introducing comma-separated lists in the subject or even predicate
fields:
:g1, :g2 rdf:type n3:ForSome .
Of couse n3:ForSome is your invention I still maintain doesn't work
for reasons given above. End syntax diversional]]]
> :c1 =
> {
> :g1 x:firstname "Ora".
> :g1 dc:wrote :g2.
> :g2 dc:title "Moby Dick".
> } a n3:falsehood .
When you don't state something has been given a name which is arbitrary
then you can never make it anonymous again.
> BOTH UNIVERSAL AND EXISTENTIAL
>
> Notation3 page section #quantification gives this example:
>
> {{:g :loves :h} log:forSome :g} log:forAll :h.
>
> My nonattached version is ambigous:
>
> :g a log:ForSome.
> :h a log:forAll.
> :g :loves :h.
>
> :g and :h is variables. Let me rewrite a bit:
>
> :g a log:ForSome.
> :h a log:forAll.
> :h log:implies { :g :loves :h }.
That I don't understand - you have some new meaning for log:implies.
You can't do that - its my term. I tink you mean a relationship between
h the context, which is probably my forAll relation.
> Now, that takes care of it. And for the other direction:
>
> :g a log:ForSome.
> :h a log:forAll.
> :g log:implies { :g :loves :h }.
>
> Now, a lone resource is here taken to mean "{ :g a rdfs:Resource}".
You mean [ :g a rdfs:Resource ] . ?
True for any :g.
> But we would usually say something more about the resource. Probably
> this:
>
> :g a log:ForSome.
> :h a log:forAll.
> {:h a ont:Person} log:implies { :g :loves :h }.
>
_________________________
I had to leave at this point
Tim
>
>
> THE MODEL FOR INFERED STATINGS
>
> The Notation3 page introduces the log:parsesTo predicate. I don't
> like that name.
>
> The thing here is that we in some way declare our trust[5] in a) source
> data and b) a inference service[6]. When we ask the service to find some
> infered data for us, we tell it what sources we trust. We resulting
> statings is placed in a separate model.
>
> This resulting model should have metadata saying that it is infered
> data, and the inference service and source data used. The same source
> model can be used in many inference models and the same inference
> model can use many sources.
>
> Let the model with the infered statings declare its sources. If we
> wan't we can state the trust in the resulting data.
>
>
>
> [1] http://uxn.nu/wraf/RDF-Service/doc/html/model.html
> [2] http://uxn.nu/wraf/RDF-Service/doc/html/stating.html
> [3] http://uxn.nu/wraf/RDF-Service/doc/html/inference.html
> [4] http://uxn.nu/wraf/RDF-Service/doc/html/api.html
> [5] http://uxn.nu/wraf/RDF-Service/doc/html/trust.html
> [6] http://uxn.nu/wraf/RDF-Service/doc/html/service.html
> [7] http://uxn.nu/wraf/RDF-Service/doc/html/context.html
>
> --
> / Jonas Liljegren
>
> The Wraf project http://www.uxn.nu/wraf/
> Sponsored by http://www.rit.se/
>
From jonas@rit.se Mon Mar 19 19:51:46 2001
From: jonas@rit.se (Jonas Liljegren)
Date: 19 Mar 2001 20:51:46 +0100
Subject: [RDF] HTML forms for RDF data manipulation
Message-ID: <87n1ahpmel.fsf@jonas.rit.se>
I have thought about how to manipulate RDF data usin HTML forms.
The current system only allows creation of statements by encoding them
in fields and hidden fields.
What I want to do is to have control over how the existing data in
controlled by the form data.
The schema should be used for determining the expected properties for
a resource, based on the class. And for validating the value of a
resource properties.
But, apart from that, we want to explain the logic of a certain widget
in a form. Two widgets could possible manipulate the sama data, but in
diffrent ways.
The specific problem I wanted to solve was to have a list of
checkboxes coupled to a container. Each checkd box will place the
corresponding resource in the container. If the container exist, it
will be cleared from resources not among the checked boxes. If no
boxes is checked, the container will be completely removed along with
the property that points at it.
This logic will be encoded by a 'field type' resource:
:fa a :Field;
:field_type :Container;
:trim_value :truth;
:connection daml:unionOf;
:remove_if_empty :truth.
Something like that. The connection explains how the widget is
coupled to the resource that is suppouesd to be modified.
The form will specify:
a. The field resorce abouve
b. The resource having this proerty
c. The availible values in the form
For a spelled out list of checkboxes, 'a' and 'b' will be repeated for
each availible value.
This is my preliminary thought. I will try this tomorrow.
--
/ Jonas Liljegren
The Wraf project http://www.uxn.nu/wraf/
Sponsored by http://www.rit.se/
From jonas@rit.se Thu Mar 29 10:59:20 2001
From: jonas@rit.se (Jonas Liljegren)
Date: 29 Mar 2001 11:59:20 +0200
Subject: [RDF] Re: DAML+OIL (March 2001) released
References: <200103280648.BAA24464@cam-mbx1.bbn.com>
<87r8zixmht.fsf@jonas.rit.se> <3AC1E8C3.DE97603A@w3.org>
Message-ID: <87g0fwx5dz.fsf@jonas.rit.se>
Reply to http://lists.w3.org/Archives/Public/www-rdf-logic/2001Mar/0105.html
And now some comments on this text about the datatype extension:
http://www.daml.org/2001/03/differences-daml+oil.html
> The idea behind DAML+OIL (March 2001) is to extend DAML+OIL
> (December 2000) with arbitrary datatypes from the XML Schema type
> system (http://www.w3.org/TR/xmlschema-2/#typesystem), while still
> retaining the desirable properties of the ontology language, in
> particular its (relative) simplicity and its well defined semantics.
That is OK.
> This is achieved by maintaining a clear separation between instances
> of "object" classes (those defined using our ontology language) and
> instances of datatypes (defined using the XML Schema type
> system). In particular, it is assumed that the domain of
> interpretation of object classes is disjoint from the domain of
> interpretation of datatypes, so that an instance of an object class
> (e.g., Leo the Lion) can never have the same interpretation as a
> value of a datatype (e.g., the integer 5), and that the set of
> object properties (which map individuals to individuals) is disjoint
> from the set of datatype properties (which map individuals to
> datatype values).
This solution is not in the spirit of RDF. Of course the resources is
disjoint from the actual literals. And that goes also for how to
validate them.
* The datatype tells something about the content of a literal.
* The schema tells something about the properties of a resource.
There is no need to split up the rdfs:Class or rdfs:Property. RDFS
already has this distinction in the rdfs:Literal class.
Datatype properties are recognised by having Datatype as range.
Datatype is recognised by being subClassOf rdfs:Literal.
The classes daml:ObjectProperty, daml:DatatypeProperty and daml:Class
should go away.
I can see that the property classes are a result from the need to
declare that we are pointing into the XML Schema domain. And
daml:Class is used for asserting that daml will not be used for doing
logic with the datatypes.
You can't isolate DAML from the rest of the world. What about the
next expansion? Will DAML subclass more RDFS classes and properties,
just to make certain that it can not be used with anything except
itself? Why should we not be able to use DAML for adding cardinality
information to a class defined in a non-DAML schema?
We must be able to represent the datatypes in the RDF graph. That
doesn't mean that all the datatypes should be included in the DAML
schema. There is probably a difference between daml:unionOf and
xsd:union. But that is not a problem. Let XSD define it's xsd:union.
RDFS should probably not be used for the RDF representation of XSD,
since xsd isn't talking about resources. The actual mapping to RDF is
trivial. It will almost suffice to enclose the schema with a RDF tag.
The important thing here is to make { xsd:element rdfs:subClassOf
rdfs:Literal }. That's the way to integrate XML schema into RDF. No
need for alienating DAML or use those extra property types.
> The disjointness of object and datatype domains is motivated by both
> philosophical and pragmatic considerations:
>
> 1. Datatypes are considered to be already sufficiently structured
> by the built-in predicates; therefore, it is not appropriate to
> form new classes of datatype values using the ontology language.
What built-in predicates?
> 2. The simplicity and compactness of the ontology language are not
> compromised; even enumerating all the XML Schema datatypes would
> add greatly to its complexity, while adding a theory for each
> datatype, even if it were possible, would lead to a language of
> monumental proportions.
Why the need to encapsulate DAML? This is the same thing as with all
those imported terms from RDF/RDFS. Thats not the way to do it. Were
you planning to introduce XML schema datatypes to RDF, but *only* for
those using DAML?
The datatypes should be in a separate schema. It should be a simple
mapping to the xmlschema typesystem. The logic lies in the xmlschema
spec.
> 3. The semantic integrity of the language is not compromised;
> defining theories for all the XML Schema datatypes would be
> difficult or impossible without extending the language in
> directions whose semantics may be difficult to capture in the
> existing framework.
What existing framework? Treat DAML as a confined language if you
must. But DAML and xmlschema should both be part of the bigger RDF
network.
> 4.The "implementatibility" of the language is not compromised;
> applications (including reasoners) can simply exploit the services
> of XML Schema type checker/validater (assuming that such a
> component exists, or soon will exist).
The soon to exist xmlschema validators can still be used. We are just
talking about a RDF representation of the datatypes and it's
relationship to the Literal class.
The committee lists both Ora Lassila and Tim Berners-Lee. How can it
be that they haven't objected to this new version? We have discussed
this thing many times on the list in the past. It seems like the
authors hasn't got the big picture here.
>From "Issues Raised in the RDF Interest Group":
http://www-uk.hpl.hp.com/people/bwm/rdf/issues.htm
* Unifying Literals and Resources
* Typing Literals
* URI References/Mime-Types and Resources
Some of my previous thoughts:
http://jonas.liljegren.org/perl/proj/rdf/schema_editor/letters/literals_2.txt
http://jonas.liljegren.org/perl/proj/rdf/schema_editor/letters/literals_3.txt
--
/ Jonas Liljegren
The Wraf project http://www.uxn.nu/wraf/
Sponsored by http://www.rit.se/
From connolly@w3.org Thu Mar 29 15:32:29 2001
From: connolly@w3.org (Dan Connolly)
Date: Thu, 29 Mar 2001 08:32:29 -0600
Subject: [RDF] Re: DAML+OIL (March 2001) released
References: <200103280648.BAA24464@cam-mbx1.bbn.com>
<87r8zixmht.fsf@jonas.rit.se> <3AC1E8C3.DE97603A@w3.org> <87g0fwx5dz.fsf@jonas.rit.se>
Message-ID: <3AC3477D.CC07A161@w3.org>
Jonas Liljegren wrote:
>
> Reply to http://lists.w3.org/Archives/Public/www-rdf-logic/2001Mar/0105.html
>
> And now some comments on this text about the datatype extension:
> http://www.daml.org/2001/03/differences-daml+oil.html
[...]
> > This is achieved by maintaining a clear separation between instances
> > of "object" classes (those defined using our ontology language) and
> > instances of datatypes (defined using the XML Schema type
> > system). [...]
>
> This solution is not in the spirit of RDF.
Yes, it's far from ideal.
[...]
> The committee lists both Ora Lassila and Tim Berners-Lee. How can it
> be that they haven't objected to this new version?
I argued (with Tim) against splitting the domains; but
tools like OILed require the split in order to do
efficient reasoning, and while I eventually want to
get beyond that requirement, the group agreed it's
worth keeping for at least a little while longer;
but we agreed to note that it's a stop-gap solution:
[[[
RESOLVED: We will release an updated language release
incorporating the current proposal, acknowledge the outstanding
issues and concerns, and solicit feedback from the larger
community.
]]]
-- Joint Committee Minutes 20 February 2001
http://www.daml.org/committee/minutes/2001-02-20.html
Ian, Frank, Peter, where is the acknowledgement that
some folks in the group don't like the split?
--
Dan Connolly, W3C http://www.w3.org/People/Connolly/
From jonas@rit.se Thu Mar 29 18:00:49 2001
From: jonas@rit.se (Jonas Liljegren)
Date: 29 Mar 2001 19:00:49 +0200
Subject: [RDF] Re: Comments on N3 and its use for writing rules
References: <87lmqp90yj.fsf@jonas.rit.se> <3A9FA337.BF7EC8FD@hplb.hpl.hp.com>
<87ae74avgb.fsf@jonas.rit.se> <01f401c0a6bc$e314d670$c1defea9@CREST>
<87wv9tn44e.fsf_-_@jonas.rit.se>
<043201c0ae69$ac7ce800$84001d12@w3.org>
Message-ID: <87puf0tsqm.fsf@jonas.rit.se>
This is a reply to
http://lists.w3.org/Archives/Public/www-rdf-logic/2001Mar/0080.html
Ouch.
I was trying to suggest an alternative to the log:forAll, log:forSome
properties.
But I may have ended up making things more complicated.
> > BOTH UNIVERSAL AND EXISTENTIAL
> >
> > Notation3 page section #quantification gives this example:
> >
> > {{:g :loves :h} log:forSome :g} log:forAll :h.
My objection against this is that the resources :g and :h can be used
in many contexts, each giving it diffrent propertis.
I look at :g and :h as a special type of resources, namely variables.
Variables is resources that can be aliases to other resources. That
is done by using an alias property, stated in a specific context.
That's why I was trying to find another way to express the same thing,
without binding variables to contexts, making the variables global.
:g a log:ForSome.
:h a log:forAll.
{:h a rdfs:Resource} log:implies { :g :loves :h }.
This is written for how I could imagine the inference engine work. :h
is an alias for all known resources. :g is an alias for one
unspecified resource.
The inference enginge works by stating those aliases in the specific
context.
... But I think I will give up on this. At least for now.
> > THE MODEL FOR INFERED STATINGS
> >
> > The Notation3 page introduces the log:parsesTo predicate. I don't
> > like that name.
> >
> > The thing here is that we in some way declare our trust[5] in a) source
> > data and b) a inference service[6]. When we ask the service to find some
> > infered data for us, we tell it what sources we trust. We resulting
> > statings is placed in a separate model.
> >
> > This resulting model should have metadata saying that it is infered
> > data, and the inference service and source data used. The same source
> > model can be used in many inference models and the same inference
> > model can use many sources.
> >
> > Let the model with the infered statings declare its sources. If we
> > wan't we can state the trust in the resulting data.
> >
> >
> > [5] http://uxn.nu/wraf/RDF-Service/doc/html/trust.html
> > [6] http://uxn.nu/wraf/RDF-Service/doc/html/service.html
--
/ Jonas Liljegren
The Wraf project http://www.uxn.nu/wraf/
Sponsored by http://www.rit.se/
From jonas@rit.se Fri Mar 30 13:32:12 2001
From: jonas@rit.se (Jonas Liljegren)
Date: 30 Mar 2001 14:32:12 +0200
Subject: [RDF] Re: Aside - Re: Question: DAML cardinality restrictions
In-Reply-To:
References:
Message-ID: <87k857v3n7.fsf@jonas.rit.se>
Peter Crowther writes:
> > From: Jan Grant [mailto:Jan.Grant@bristol.ac.uk]
> >
> > I can't help feeling a little worried by these examples. Yes, I know
> > they're "only" examples. But the model of the world they present is
> > broken - will DAML be good for describing the real world or just
> > mathematical arenas and EDI? Is it even wise to tr