[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xdi] Bill and Giovanni - special note about today's call
Hi,not sure to have understood correctly, however: in OWL you can specify that a property (either a datatype property or an object property) is functional, i.e. that, like a function, has one and only one value when applied to an individual. Examples:
voc:hasMother rdf:type owl:FunctionalProperty . ex:joe voc:hasMother ex:carla .This tells that voc:hasMother is functional and consequently Joe has one and only one mother, Carla. In XDI this would be, according to what you're proposing
=joe/$!(+mother)/=carlaHowever, if your reasoner doesn't know that a property is functional (note that by default, i.e. without stating any constraint, a reasoner does not assume that the property is functional -- you have to tell this explicitly) it can accept many statements, e.g.:
ex:joe voc:hasMother ex:carla . ex:joe voc:hasMother ex:janet . In XDI this would be =joe/+mother/=carla =joe/+mother/=janet So $!(+mother) is the XDI equivalent for the constraint voc:hasMother rdf:type owl:FunctionalProperty . Is this your desired behavior? Best Regards, Giovanni Def. Quota Drummond Reed <drummond.reed@xdi.org>:
Markus, exactly right - in fact that's a primary use case that was motivating making a clear semantic difference between single-valued and multi-valued contexts. In fact, the server wouldn't even necessarily need to be that smart, because you can put both single-valued and multi-valued contexts of the same type in the same graph. Example: =!1111$!(+tel)/$is/=!1111+tel$!2 Here the singlar or canonical reference "=!1111$!(+tel)" is just a reference to the second instance in a multi-valued set. I have more thoughts on how we can use $ cross-references to make singular vs. plural explicit - I'm working on the graph pattern diagrams and will post when ready. =Drummond On Sat, Mar 24, 2012 at 7:19 AM, Markus Sabadello <markus.sabadello@xdi.org>wrote:Sometimes a client may just want an email address, and it might not know or care if the context on the server is single-valued or multi-valued. In this case, I guess it could just ask for $!(+tel) , and the server could be smart enough to simply return one (the canonical) value, even if there are multiple values stored in a +tel context on the server. In the past we had a similar pattern, using e.g. +tel$ to request the "canonical" value, Markus On Sat, Mar 24, 2012 at 8:16 AM, Drummond Reed <drummond.reed@xdi.org>wrote:Bill and Giovanni: Just a note to you both, since you were not able to attend today's call,about agenda item #3 below (RE the latest XDI Graph Patterns<http://www.oasis-open.org/committees/download.php/45530/xdi-graph-patterns-2012-03-22.pdf%20>doc).As two of the semantics experts on the TC, I wanted to call to your attention the proposal in this latest version that solves the single-valued vs. multi-valued contexts problem, i.e., can we avoid in an XDI dictionary having to define whether a context intended to represent a literal takes only a single value or multiple values. For example, it would be ideal if +tel could simply be defined in the dictionary as: +tel/$is$a/$a$json$string Note: there would be more statements in the dictionary than this one, e.g., XBNF, human-readable description, labels in various languages, etc. But my point is that it would be ideal if the dictionary definition did not by itself have to say anything about cardinality. That has not been the case so far, i.e., if you saw the XDI statement =drummond+tel, you don't know whether it is referring to a single instance of a phone number or a set of phone numbers, i.e., whether it is single-valued or multi-valued. That is the equivalent in English of not being able to distinguish whether a noun is singular or plural. In English, the solution is to do an algorithmic transformation from singular to plural by adding an "s" (of course there are many exceptions to the rule). Drummond's phone number <== singular Drummond's phone numbers <== plural The proposed solution for XDI semantics is similar, just the other way around: 1. All XDI "generic nouns" (definitions in the + space) are by definition plural (multi-valued), and there is an algorithmic transformation to make them singular: +tel <== plural $!(+tel) <== singular The origination of the proposal was the realization that if we specified that the $! space identifies ONLY single-valued instances of a class, then all XDI subject addresses that end in a subsegment that begins wtih $! identify literals. Similarly, all XDI subject addresses that end in a subsegment starting with $* would identify ordinals. For example, the following XDI addresses all represent single-valued contexts: =drummond$!(+tel) =drummond+address$1+street$!1 =drummond+address$1+street$!2 =drummond+address$1$!(+city) =drummond+address$1$!(+state) =drummond+address$1$!(+zip) Whereas the following represent multi-valued contexts: =drummond+tel =drummond+address$1+street Notice in these examples that an instance of a complex context, like =drummond or +address, is identified with a $number, e.g., $1, $2. I am enthusiastic that this is a clean semantic solution for distinguishing between single-valued and multi-valued contexts. Thoughts? =DrummondOn Fri, Mar 23, 2012 at 10:01 PM, Drummond Reed <drummond.reed@xdi.org>wrote:Following are the minutes of the unofficial telecon of the XDI TC at: Date: Friday, 24 February 2012 USA Time: 9:00AM - 10:30AM Pacific Time (16:00-17:30 UTC) THE ETHERPAD LINK FOR TODAY IS: http://xdi.idearpad.org/57 ATTENDING Mike Schwartz Drummond Reed Joseph Boyle Markus Sabadello GUESTS Kari Lippert Cameron Hunt 1) IDTRUST BUDGET PROPOSAL Drummond had a call with the OASIS IDTrust member section staff. This resulted in revisions to the proposal which we need to review: http://wiki.oasis-open.org/xdi/IdTrustProposal Drummond said the key revisions needed were: - Clarification that deployment of the public test servers was a key step towards finishing the XDI 1.0 spec suite. - Clarification on the breadth of involvement of TC members. - Setting a deliverable date of the end of 2012, producing a final report at that time, and then optionally applying to renew in 2013. There was a consensus that the proposal was ready to submit. # DRUMMOND to send email to Dee. 2) OPEN SOURCE PROJECT UPDATES Mike reported that the OpenXDI Project implemented binary storage, so that if a datatype is specified in the value of the data: URI, then it is now stored in a binary LDAP node. Mike also reported that no code change to OxServer or OxGraph is necessary to support literal contexts. It will result in a change to OxModel. The nested roots work is still waiting. Markus reported that he's been doing some work on XDI Squared, and isnext looking at implementing it on the Freedom Box, as there is a thread onthe VRM mailing list about p2p usage of VRM. Drummond said Phil Windley has published a blog post about how KRL (Kinetic Rules Language) is going to add XDI support, so that KRL will be operate on a consistent semantic data interchange layer. http://www.windley.com/archives/2012/03/krl_data_and_personal_clouds.shtml This is very encouraging from both an adoption and engineering standpoint, as Phil is very well recognized as a technology pioneer. # MARKUS, MIKE, DRUMMOND to create a page on the XDI TC wiki with a directory of the XDI open source projects. 3) UPDATED XDI GRAPH PATTERN DOCUMENT Drummond uploaded a new version that solves one additional key issue: http://www.oasis-open.org/committees/download.php/45530/xdi-graph-patterns-2012-03-22.pdf The key issue was how to semantically distinguish single-valued contexts from multi-valued contexts. This not only makes it possible to algorithmically compose XDI addresses, but makes XDI dictionary construction much easier. Drummond showed examples of both single-valued and multi-valued contexts, and the initial reaction was positive. 4) NESTED ROOT CONTEXTS Mike asked about the use cases for nested root contexts. Drummond clarified the constraints: - Root nodes can only be subcontexts of other root nodes. - Every local graph still has only one local root node whose XDI address is (). All other root nodes must be nested under this. The primary use case is XDI discovery, i.e., the ability to ask one local graph for metadata about another local graph, e.g., its URI(s). Suchmetadata could be considered cached, or it could be fully subscribed, sinceit is essentially a remote copy of self-description data. 5) XDI QUERY Mike Schwartz and Yuriy Zabrovarnyy sent an email outlining why theydon't believe XML Path & JSON Path are good models on which we should basedXDI Query: http://lists.oasis-open.org/archives/xdi/201203/msg00036.html Mike clarified that having an XDI Path capabiility could be very useful, but on the client side, not on the server, i.e., it is much more feasible to implement on a return graph. It also needs to as efficient as possible on the network. # MIKE will post a proposal on the XDI TC wiki and send an email to thelist with a link for discussion. We will make this the focus of next week'scall. 6) NEXT CALL The next call is next week at the regular time.
---------------------------------------------------------------- Invito da parte dell'Ateneo: Il tuo futuro e quello della Ricerca Scientifica hanno bisogno del tuo aiuto. Dona il 5 x mille all'Universita' di Roma Tor Vergata codice fiscale: 80213750583 http://5x1000.uniroma2.it
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]