John,
I don't see a problem of downloading all the page from the server and
then let the client process the fragment. More comments inline.
-Luis
On Mar 23, 2007, at 2:21 PM, John Graybeal wrote:
> Luis,
>
> I got this from the WebIdentifiers page at https://
> www.seegrid.csiro.au/twiki/bin/view/AppSchemas/WebIdentifiers:
> "However, it is important to realise that the fragment is not
> passed in the http request - rather, it is the responsibility of
> the client to process the fragment identifier to obtain a sub-
> resource from within a potentially much larger resource, all of
> which must be transferred prior to the client-side operation. "
This is true
>
> Your reference was helpful but confusing to me, a naif. In one
> place it says "The fragment identifier functions differently than
> the rest of the URI: namely, its processing is exclusively client-
> side with no participation from the server. When an agent (such as
> a Web browser) requests a resource from a Web server, the agent
> sends the URI to the server, but does not send the fragment.
> Instead, the agent waits for the server to send the resource, and
> then the agent processes the resource according to the fragment
> value. " This confirms the above.
yes
>
> In another place it says "In RDF vocabularies, such as RDFS, OWL,
> or SKOS, fragment identifiers are used to identify resources in the
> same XML Namespace, but are not necessarily corresponding to a
> specific part of a document." I suppose this does not necessarily
> conflict with the previous, but....
>
> We are perhaps conflating functionality because we are making the
> server respond to a URL (but the server won't see the fragment part
> of the URL), but then expecting RDF clients to do something
> different with the same URL. From your comment "The way you are
> suggesting will confuse semantic web tools" I infer there is a set
> methodology used by semantic web tools that relies on this fragment
> notation. Would that methodology also be totally broken by URNs,
> or does it take their format into account?
1) I checked with the latest JENA API (to be sure) and is not
producing any errors when constructing the URI as you are suggesting.
Maybe they already solved this issue.
2) Problems is if we give the ontology namespace without the fragment
separator"/" it will confuse ontology tools, for example while using
Protege we need to add the namespace manually.
3) If we want to use friendly HTML pages we will have to break the
presentation of the terms in different pages, each page per term,
which means create hundreds of pages for a single vocabulary.
- Luis
>
> John
>
>
> At 3:48 PM -0700 3/22/07, Luis Bermudez wrote:
>> John,
>> From
>>>
>>> I support most of Luis' point re URLs. If we're having this
>>> discussion here, I urge we remove the '#' mechanism, which is
>>> broken from a service provider standpoint. (Because the server
>>> never sees the '#air_density' part of the URL, so many potential
>>> features are awkward or no longer possible.) Replacing the #
>>> with / is one alternative that seems functional.
>>>
>>
>> Regarding the "#", I don't see that is broken from a service
>> provider standpoint. Could you please detail the awkward or no
>> possible features you re thinking about.
>>
>> I suggest using "#" as a fragment identifier separator because:
>> - It is easy resolvable in an HTML page, since it will refer to
>> the anchor, an those we can easily display information about a
>> resource.
>> - If I publish and ontology and give the URL to a semantic web
>> tool it will understand the "#" as a fragment separator. And I can
>> publish the ontology in the base URI (String before the "#"). The
>> way you are suggesting will confuse semantic web tools.
>>
>> For your entertaining see also wikipedia:
>> http://en.wikipedia.org/wiki/Fragment_identifier
>>
>> Best,
>>
>> Luis
>
>
> --
> ----------
> John Graybeal <mailto:graybeal at mbari.org> -- 831-775-1956
> Monterey Bay Aquarium Research Institute
> Marine Metadata Initiative: http://marinemetadata.org || Shore
> Side Data System: http://www.mbari.org/ssds
Received on Fri Mar 23 2007 - 17:47:22 GMT
