| RE: [higgins-dev] URI's in Higgins |
|
Using reflection suits some use cases, but not others. Where I think it works well is when the IdAS consumer is reading data and displaying it for a human. Even then, it's not easy to guess at which methods any given object has might produce data that a human wishes to look at. Might as well just call toString() and hope something good comes out.
For something like a management utility, it gets more sticky. A generic management utility would have to be pretty sophisticated to turn a bunch of methods into a UI that could be used to manipulate a subject's attribute values. What if the Java class has methods and fields that are ancillary and have nothng to do with what's defined in the schema for that data type? Looking at a different way of solving this, I suppose that kind of utility could have a-priori knowledge of a set of class types and know what can be done with those, but I think there's still a problem with that.
Let's say there are two providers which both can create the same context. If there is no language type bindings in the attribute type URIs, then both providers are free to implement the same attribute values using completely different classes. N providers = N possible classes for each attribute type. In fact, there's nothing stopping a single provider from returning objects of different classes for the value of the same attribute type.
Assume we're writing an application which consumes IdAS. It needs to read the shoe size attribute of a subject and then perform some comparison on the resulting value. It would be nice if all providers supporting the URI representing the shoe size attribute produced the same Java class instance. Then the application could call methods like equals() on it. If the application has to use reflection, I'm not sure it could ever be sophisticated enough to know how to compare any Java object with what it knows to be an Integer of 10.
I assume I'm missing something. If not, I think I'd rather say Attribute values are always XML documents or nodes. At least that way I could tie the schema to the value.
Jim
>>> "Paul Trevithick" <paul@xxxxxxxxxxxxxxxxx> 8/2/06 11:38 PM >>> Jim wrote:
So, assuming the example Novell ontology below, I think I understand how the IdAS consumer knows what to expect when calling IContext.export, and finding a "foo" attribute.
getValue() would return a Java Object. The underlying provider impl would know the correct type of Java object to return. Through reflection the IdAS API consumer can find out that the returned Object is really a Java String.
There's nothing in the URI or .owl that tells us how to map normalizedString to a Java object.
The URI is the name of a property that is described in the provider's associated .owl data. This .owl data tells us that the URI has a string value. The provider impl usually "knows" this by its internal use of static Java types like String.
Jim -----Original Message-----
Question about the second bullet under "Technology" on the page below: It says "The values of the attributes will be described in both normal language and OWL-DL". I'm wondering about the meaning of "normal language".
I meant "ordinary" language (e.g. English) for human consumers.
So far, in IdAS, we have at least two potentially different value representations One described by OWL-DL, and one described as a Java Class. As we port IdAS to other languages, that number would grow. If we look beyond IdAS, some attributes will already have other data representations (ASN.1, XML Schema, etc.)
To me, it seems like this Identity Attribute schema would want to either a) document only a single representation (OWL-DL for example) b) document all known representations (OWL-DL, ASN.1, XML Schema, Java Class, etc.) c) same as "a", but cite transformation algorithms/rules used to map from one definition language to another
Yes. I had thought of only doing a), but maybe that's not enough.
This gets at the original problem at hand. That is, how to construct a Attribute (or metadata) type URI which conveys the name ("age", "title", etc.) as well a the datatype (String, Int, {String, String, Int}, etc.).
Assuming that this Identity Attribute is one that isn't already in higgins.owl (or another .owl file from IdentitySchemas.org!), then this means that the Context Provider must be defining its own schema (ontology) that contains at least this one new property. It will return this ontology in its getSchema() impl. Let's say that the Context Provider is being developed by Novell. At the top of the ontology might be:
<rdf:RDF xml:base=http://www.novell.com/higgins/ontologies/2006/8 .> Then somewhere in this file the Novell developer inserts: 1 <owl:DatatypeProperty rdf:about="#foo">2 <rdfs:domain rdf:resource="#DigitalSubject"/>3 <rdfs:range rdf:resource="&xsd;normalizedString"/>4 </owl:DatatypeProperty> On line 1 above they are declaring a new URI called "http://www.novell.com/higgins/ontologies/2006/8/foo". On line 3 they are defining that its value must be an XML schema "normalizedString". Note: Line 2 would be added only if indeed this was a new Identity Attribute of a Digital Subject.
Jim
p.s. Are Mark Wahl and others on this list, or should messages related to this be cc'd somewhere?
I have discussed this general attribute namespace problem with a bunch of folks over the past few months. I found that there was general support for the idea of an identity attribute namespace project. Especially if it could be community co-created. I was even lucky enough to find some folks, like Mark Wahl and others, who have volunteered to contribute to it. So we've started something called Identity Schemas (http://identityschemas.org).
My hope is that we could do the "carving out" project out in the open, on this site. A kind of self-service notion. Anyone who needs to do some attribute name mapping help themselves and do it there.
Jim wrote:
I like the idea of carving out a namespace which can be used to organize things like metadata types, attribute types, etc. It would be nice if the type had resolvable components such that the consumer can discover exactly what type of object to expect back in the value.
Jim
|