+1 as well. Very well articulated. An interesting side note: XRI supports a # fragment for backward compatibility with URI/IRI syntax, but in practice its rarely used since XRI syntax is already polyarchical, i.e., any XRI can be put in the context of another XRI. # is just one such context ("document local"). So XDI dictionaries, which use XRIs to identify attributes, can have all the same general properties that Mark describes (except #5, which applies only to URLs), only they don't have to explicitly be expressed as fragments.
=Drummond -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dick Hardt Sent: Tuesday, April 10, 2007 5:53 PM To: Mark Wahl Cc: OpenID specs list; ID Schemas Subject: Re: in favor of allowing a fragment in a URI for metadata for anattribute type Good argument Mark, I concur. +1 -- Dick On 10-Apr-07, at 4:52 PM, Mark Wahl wrote: > > Section 4.3 of > http://openid.net/specs/openid-attribute-types-1_0-02.html > suggests that in URIs defined for attributes for OpenID AX, > "URI fragment specifiers should not be used." > > Now I'm no RDF expert, but I'm in favor of allowing fragments, > and perhaps even encouraging them. I'd prefer this statement > be removed from subsequent versions of the OpenID AX, in order > to not dissuade other schema developers from using fragments. > Here are some points for discussion on that topic, I'd be > interested in hearing feedback esp. from other RDF implementors. > > 0. Some servers will have but a single, small, fixed schema. I'd > rather those servers be able to reference and serve a single RDF > file with their complete schema, instead of needing to break that > schema into a bunch of little schemas. > > For example, suppose a server only supports FOAF. Now FOAF does not > use fragments for the property definitions for its attribute types, > but the attribute types defined in FOAF are not currently resolvable > to an RDF document that describes those attribute types. > > If xmlns.com where the FOAF RDF is hosted were to implement having > these > attribute type URIs used in FOAF be resolvable, they > would either need to > - create a few dozen little RDF files that together mirror the > content of > foaf.rdf, or > - implement a URI rule that http://xmlns.com/foaf/0.1/* > returns foaf.rdf > > If I were redefining FOAF, I'd have its attributes be defined as > fragments, > so that there is only one base URI for the FOAF schema. (Also to give > them RDF class definitions, see below). > > 1. It appears to be current practice for RDF representations of > metadata > for attributes in Higgins to use fragments. > > In OWL-based systems, the RDF object at the base URI of the document > is an OWL Ontology. > > In Higgins, which uses OWL, the object at the base URI is an OWL > Ontology that 'imports' the Higgins Ontology. The RDF file for > an attribute contains an OWL Class for the attribute named by a > fragment,e.g., #Firstname, and several related OWL properties and > RDF instances in that same file that add structure to that class. > > 2. In our 'schemat' implementations which attempt to generate RDF for > existing schemas of 'legacy'/'installed base' protocols, it is > desirable to > be able to have additional, named OWL classes, RDF objects, and other > modelling and descriptive data definitions that are shared across > multiple attributes of a single schema. For example, a schema may > define its own value syntax and matching rules, and wish to share > those syntaxes and matching rules across the attributes of that > schema. > It would be desirable if there could be a single RDF file which > contains > the attribute type metadata, the syntax definition and matching rule > definition, rather than needing to have the attribute type metadata > in a set of files that are separate from the syntax definitions and > matching rule definitions, or are duplicated in those files. > > 3. I find that in our implementation 'schemat' of identity metaschema > attribute metadata retrieval that is a definite performance gain if > all the schema elements for a particular schema can be retrieved in > a single HTTP GET. It is likely that an implementation interested > in an attribute Firstname of a particular schema would also be > seeing a few other attributes Lastname, Middlename etc of the same > schema, and it would be good if a GET that retrieves the data for > Firstname also gives the implementation the rest of the schema so > that it does not need to keep going back and GETing for each > attribute type. > > 4. Requiring that each be in a separate document would likely lead to > duplication of metadata, particularly Dublin Core metadata that > describes "the schema as a whole". I feel it would be better if the > RDF object at the base URI has the Dublin Core metadata for the > schema as a whole, and that the Attribute Type Metadata is a class > named by a fragment below that base URI. > > 5. (appeal to authority) http://www.w3.org/DesignIssues/Fragment.html > "This means that identifiers for arbitrary RDF concepts should have > fragment identifiers. " > > > Mark Wahl > Informed Control Inc. > > _______________________________________________ > specs mailing list > specs@openid.net > http://openid.net/mailman/listinfo/specs > > _______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs _______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs