+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
