- From: Ashok Malhotra <ashok.malhotra@oracle.com>
- Date: Mon, 19 Aug 2013 09:12:18 -0400
- To: "public-ldp-wg@w3.org" <public-ldp-wg@w3.org>
- Message-ID: <521219B2.507@oracle.com>
Made some changes at Steve's suggestion ... ============================================ In expressing Linked Data Platform Resources in RDF, fragments are useful because they can be expressed as relative URIs on the document describing them. This is particularly handy for describing multiple LDPRs whose representations are contained within a single document. First, it provides the convenience and efficiency of brevity. Suppose, for example that you want to describe the resources foo, bar and baz which are contained in the same document. Since serving all of the descriptions in a single document is a acceptable, we can mint relative URIs within the document using the fragment identifier (|<#foo>|, |<#bar>| and |<#baz>|). The full URI is assumed to be the base URI, plus the hash mark, and the fragment identifier. Second, it can help avoid complexities inherent with other approaches. Achieving the same result using three independent dereferenceable URIs could be more involved, because you'd need to create and publish multiple documents, perhaps also having to setup 303 redirects. All the best, Ashok On 8/19/2013 9:03 AM, Steve Speicher wrote: > > Looks pretty good, have a couple of suggestions below... > > - Steve Speicher > > > On Sat, Aug 17, 2013 at 12:46 PM, Ashok Malhotra <ashok.malhotra@oracle.com <mailto:ashok.malhotra@oracle.com>> wrote: > > Cody: > I took a crack at rewriting paras 3, 4 and 5 > > I think we need to make explicit the relationship of the fragments to the main document. > > ------------------------------------------------- > > In expressing Linked Data Platform Resources in RDF, fragments are useful because they can be expressed as relative URIs on the document describing them. This is particularly handy for describing resources that are sub-resources of the same parent document. > > I'm not sure we have a concept of sub-resources. Perhaps it would best to say something like "describing multiple LDPRs whose representations are within a single document." > > First, it provides the convenience and efficiency of brevity. Suppose, for example that you want to describe the resources foo, bar and baz which are contained in the same resource. Since serving all of the descriptions in a > > What does "in the same resource" mean here? I believe you mean either "same RDF resource" or better perhaps "same document". > > single document is a acceptable, we can mint relative URIs within the document using the fragment identifier (|<#foo>|, |<#bar>| and |<#baz>|). The full URI is assumed to be the base URI, plus the hash mark, and the fragment identifier. > > Second, it can help avoid complexities inherent with other approaches. Achieving the same result using > three independent dereferenceable URIs could be more involved, because you'd need to create and publish multiple documents, perhaps also having to setup 303 redirects. > > All the best, Ashok > On 8/16/2013 4:45 PM, Cody Burleson wrote: >> OK, guys, here's my crack at it. I'm not sure the value is as clearly stated as it can be, but... I kind of struggled with it. >> >> Please let me know if you think it can be improved: >> >> >> 2.6 Use fragments as object identifiers >> >> The fragment identifier introduced by a hash mark *|#|* is the optional last part of a URI for an object, which is typically used to identify a subordinate or related object. >> >> Take the URI, |http://www.example.com/products#item10245|, for example. The base URI is the part preceding the hash mark, |http://www.example.com/products|, and the fragment identifier is the part that follows, |item10245|. >> >> In the RDF expressing Linked Data Platform Resources, fragments are useful because they can be expressed as relative URIs on the document describing them. This is particularly handy for describing a handful of resources that are frequently used together. >> >> First, it provides the convenience and efficiency of brevity. Suppose, for example that you want to describe the resources foo, bar and baz. Since serving all of the descriptions in a single document is a acceptable, we can mint relative URIs within the document using the fragment identifier (|<#foo>|, |<#bar>| and |<#baz>|). The full URI is assumed to be the base URI, plus the hash mark, and the fragment identifier. >> >> Second, it can help avoid certain complexities inherent with other approaches. Achieving the same result (three dereferenceable URIs) could be more involved, because you'd need to create and publish multiple documents, perhaps also having to setup 303 redirects. >> >> *See also:* >> >> Cool URIs for the Semantic Web <http://www.w3.org/TR/cooluris> >> >> * http://www.w3.org/TR/cooluris/#hashuri >> * http://www.w3.org/TR/cooluris/#choosing >> >> Axioms of Web Architecture, URI References: Fragment Identifiers on URIs <http://www.w3.org/DesignIssues/Fragment.html> >> http://www.w3.org/DesignIssues/Fragment.html >> >> Dereferencing HTTP URIs <http://www.w3.org/2001/tag/doc/httpRange-14/2007-05-31/HttpRange-14> >> http://www.w3.org/2001/tag/doc/httpRange-14/2007-05-31/HttpRange-14 >> >> >> >> >> On Wed, Aug 14, 2013 at 6:47 PM, Richard Cyganiak <richard@cyganiak.de <mailto:richard@cyganiak.de>> wrote: >> >> On 14 Aug 2013, at 23:39, Cody Burleson wrote: >> >> > Team, >> > >> > I could use a little help fleshing out a spot in the LDP Best Practices and Guidelines. >> > >> > One of the recommendations in the Deployment Guide was written in the wiki as follows: >> > >> > --- >> > Use fragments as entity identifiers >> > >> > Fragments are nice because they can be expressed as relative URIs on the document describing them. >> > --- >> > >> > I'm not sure who first wrote that, but if you could provide me with more detail, it would be helpful. Or anybody, for that matter. >> >> It may have been me. >> >> Scenario: >> >> - You want to describe a number of resources (say: foo, bar and baz) >> - You need to mint URIs for these resources >> - Putting all the descriptions into a single document (say: <http://example.com/stuff.ttl>) is acceptable >> >> Then minting hash URIs is a very convenient approach. Simply use <#foo>, <#bar> and <#baz>. The result are nice dereferenceable URIs, <http://example.com/stuff.ttl#foo> and so on. >> >> Thanks to the logic of URI resolution, the simple local identifier <#foo> gets turned into a globally unique ID. It becomes globally unique by being qualified with the URI of the document it is used in. >> >> With other approaches, achieving the same result (three dereferenceable URIs) would probably be more involved, because you'd need to create and publish multiple documents, perhaps set up 303 redirects and whatnot. >> >> The sweet spot for this approach is for a handful of resources that frequently are used together. That's why most RDFS vocabularies and OWL ontologies use this approach. >> >> Relevant W3C references: >> http://www.w3.org/TR/cooluris/#hashuri >> http://www.w3.org/TR/cooluris/#choosing >> >> Best, >> Richard >> >> >> > >> > I understand the use of fragments in RDF. It's how I define properties on an Instance in OWL, for example. If I have a representation of a Person (Instance of Person), the fragment #hasName represents the hasName property of that Person which may or may not be defined in the same RDF document. >> > >> > But is it really a Best Practice? Or simply a Guideline? There is some somewhat confusing debate on the web. >> > >> > Also, can you represent why it is a useful practice using an example representation of a resource? >> > >> > What do you think we really need to say here to make this point a little more meaningful? >> > >> > >> > >> > -- >> > Cody Burleson >> > >> >> >> >> >> -- >> Cody Burleson >> Enterprise Web Architect, Base22 >> Mobile: +1 (214) 537-8782 >> Skype: codyburleson >> Email: cody@base22.com <mailto:cody@base22.com> >> Blog: codyburleson.com <http://codyburleson.com> >> >> *<http://base22.com>* >> * >> * >> *Check my free/busy time. <http://www.google.com/calendar/embed?src=cody.burleson%40base22.com&ctz=America/Chicago%20>* >> >> > >
Received on Monday, 19 August 2013 13:12:58 UTC