Re: URIs and Named Graphs

Hello Hans,

I'm trying to understand your scenario, and have some questions.

- Why would you have hundreds of quad stores instead of a single  
larger quad store with more qualifications on the queries?
- What motivates the uses if URI#fragIDs in the first place?
- SPARQL allows queries that span multiple named graphs - why would  
you need to have different end points for the different partitions,  
which I understand to be equivalent to named graphs?
- What would you expect the behavior to be for something like  
URI#partition#fragID? The only behavior I am aware of for hashes is  
in the context of http GET, where only the URI before the hash is  
sent as the target of the GET. Do you depend on this behavior  
already? If so, to accomplish what?
- What do browsers have to do with the scenario?

You might not want to answer these questions - in that case consider  
them as an indication of whether you are adequately communicating  
your problem to an audience familiar with SW technologies, as I  
consider myself to be.

Regards,
Alan


On Jul 5, 2007, at 7:57 AM, Hans Teijgeler wrote:

> Hi,
>
> We ran into a problem for which I ask advice from this esteemed forum.
>
> First some background information: we use the SW technologies in  
> conjunction with a generic data model to create a distributed data  
> base for each engineering project, involving large numbers (in the  
> hundreds) of quad stores per project.
>
> To give an example of using a data model "underneath" OWL: normally  
> you may see things like an <owl:Class rdf:ID="Car"/>.
> For us that would be: <part2:ClassOfInanimatePhysicalObject  
> rdf:ID="Car"/> where ClassOfInanimatePhysicalObject is an entity  
> type in our data model and an owl:Class.
> If an application has data that must be shared, that data is mapped  
> at the source from its proprietary format to ISO 15926-7 format,  
> and stored in a quad store that we call a "Façade".
> Only "owned" data are stored, other data a fetched with SPARQL for  
> other Façades.
> Data can be "handed over" to another Façade, thus also handing over  
> custody for that data.
> Quad stores that participate in a given project are known to a  
> "CPF" server (Confederation of Participating Façades), where we  
> distrubute SPARQL queries, consolidate query results, whilst  
> controling access rights.
>
> For the Façades we use RAP, and want to use the 4th column of their  
> Named Graphs for dividing the quad store into partitions like  
> 'active data', 'archive', and the like. Actually we have nine such  
> partitions, but I won't annoy you with the details.
>
> We use URI#fragID's all over the place.
>
> The question is how we can dereference any such fragment  
> identifiers inside a particular partition without having to have  
> nine endpoints (which is costly and harder to manage).
>
> It would be nice if we could use composite fragment identifiers  
> like URI#partition#fragID, but the second hash # would not be  
> allowed. If we would use something like URI#partition__fragID that  
> would be well-formed, but hardly usable with generic browsers (I  
> guess).
>
> Please shed some light on this.
>
> Regards,
> Hans
>
> ____________________
> OntoConsult
> Hans Teijgeler
> ISO 15926 specialist
> Netherlands
> +31-72-509 2005
> www.InfowebML.ws
> hans.teijgeler@quicknet.nl
>
> No virus found in this outgoing message.
> Checked by AVG Free Edition.
> Version: 7.5.476 / Virus Database: 269.10.0/886 - Release Date: 04- 
> Jul-07 13:40

Received on Saturday, 7 July 2007 22:17:21 UTC