RE: ungetable http URIs

> ----Original Message----
> From: Butler, Mark <mailto:Mark_Butler@hplb.hpl.hp.com>
> Date: 1 December 2003 18:29
> 
> Hi Andy
> 
> > Yes - we should be using gettable URLs where it makes sense.
> > Probably URNs for people.
> > 
> > > So there are two possible
> > > solutions:
> > > a) Should we modify the XSLT stylesheet and re-run it to create
> > > the Artstor data so that it uses URNs rather than URLs avoiding
> > > ungetable URIs?
> > 
> > Not sure exactly what you mean here - "should not be using
> > ungetable URLs right" parses a double negative to to "use URLs" for
> > me. 
> 
> Is this better - "Should we modify the XSLT stylesheet and rerun it
> to create the Artstor data so it uses URNs for all instance data?" 

It was the earlier sentence I was having difficulty placing  - I'm not sure
anymore which URIs are ungettable, which are ungettable at the moment (i.e.
for the demo) but should be, and which are gettable (demo).  I thought we
were using URLs for everything that should be gettable, whether it is for
the demo or not (because I don't see the value in changing things post demo
- we can try to do the right thing now (an experiment)).

Let's draw this up on a whiteboard.

> 
> I think you didn't like my use of the term "instance data" before, so
> to clarify this I mean assertional data, rather than terminological
> (schema) data - what is your preferred term here?

The term "instance data" was ambigous to me - that's all.  Can be the image
itself, or the meta data about the image.  We have to come to a practical
decision of what to do about representations or web resources and
descriptions of things (images, people, defined terms).  The demo is an
experiment for that.

> 
> I think we are agreed that terminological data should use URLs.
> 
> > Gettablity refers to the ability to do a plain HTTP GET on
> > the URL and get
> > something.  Joseki is providing explicit knowledge bases (KB)
> > on the web -
> > within a KB, you can obtain information about any URI(ref).
> > 
> > GET http://simileserver/artstore?lang=fetch&r=urn:foobar
> > 
> > will fetch the information with urn:foobar as subhect (and related
> > information) from the artstore metadat located at
> > http://simileserver/artstore There is no tie between the URL for the
> > KB and the URIs for the RDF in the KB (unless you want to do that).
> > 
> > Joseki is not an infrastructure for placing meaningful
> > documents at URLs -
> > you just need Apache for that.
> 
> Yes, understood.
> 
> However the problem with just using Apache is at the moment we have
> approximately 34 files, all around 20 megabytes in size. So if we are
> to expose each individual URL via Apache, then we potentially have a
> lot of work to create the files that correspond to each URL, even if
> we use an automated process as just dealing with collections this big
> is unwieldy. I'd have a strong preference against doing this for the
> demo, because it seems to me it' just make work - there's nothing at
> those URLs that's not in the serialized data, right?  

Sorry - I'm a bit lost here as well.  Joseki is not replacing Apache
functionality and isn't trying to.  If you want to server 20Mbyte files at a
URL over a plain GET (no query string) then use Apache.  Joseki is just a
query server (over HTTP) - if you want to have a small part of a larger
model served up as the result of a query, then that is a role for Joseki.

What complicates matters is the represenation/description distinction.
http://simileserver/artstore?lang=fetch&r=urn:foobar is a good URL for the
metadata in http://simileserver/artstore about urn:foobar.  I don't think
this is an issue for the demo but you have a clearer picture on that than I
do. 

We need a pragmatic approach for the demo and until we have a detailed demo
script that can inform what is going to be GETted in the script.

Another whiteboard thing - let's draw up a deployment picture.

> 
> However if we can just feed that data into something else (like
> Joseki) and that automatically generates the contents of the URL,
> then the make work becomes less of an overhead, but I gather this
> will require changing the URIs to be query strings as you describe
> above?    
> 
> So perhaps the question I should be asking is for the purposes of the
> demo, is there any advantage in using URLs for instance data rather
> than URNs, if we assume that by making this decision now we are not
> committing to it long term?   
> 
> kind regards,
> 
> Dr Mark H. Butler
> Research Scientist                HP Labs Bristol
> mark-h_butler@hp.com
> Internet: http://www-uk.hpl.hp.com/people/marbut/

Received on Monday, 1 December 2003 15:46:12 UTC