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 %] >

name="li_subj #gen2" > value="[% type.uri %]" /> > > [% 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 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.

To check our prices and submit uxn.nu to 300,000+ search engines, go to TrafficMagnet.net

I would love to hear from you.

Best Regards,
Christine Hall
Sales & Marketing
www.TrafficMagnet.net

   

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