Re: [higgins-dev] Sub-contexts

[Paul Trevithick <ptrevithick@xxxxxxxxx>]

Hi Sergey, I was surprised to see this email because I thought that you thought that implementing named graphs using NG4J was going to be too much work (and that instead we'd just limp along without them for now). But in case you've changed your mind, I've answered below.

On Jun 8, 2010, at 10:13 AM, Sergey Lyakhov wrote:

Paul,

I suppose it is very convenient to use Named Graphs to implement access control. But using it for metadata on attributes looks a bit awkward and ambiguous because of the following:

And now we can attach some metadata about C2. Perhaps we want to say that the h:correlation link it contains is

Valery's "favorite" link. This can be done in C1 or C2 (or any other sub or main context):

In C1:

:C1

{

:Foo

h:correlation :Bar;

:C1

:valerys-favorite "True"^^xsd:boolean

}

:C2

{

:Foo

h:correlation: :Baz;

}

In the example above, C1 URI is used for both name of graph and Id of subject (actually, an entity).

Correct. I'm demonstrating here one way to use named graphs to make a statement about a statement. Seems a big improvement vs. using reification.

So, we need to perform additional check for each a statement, to understand is it entity or metadata.

I know what you meant by your words "entity" vs. "metadata" but in reality, as you know, all information is represented as attributes about entities. And the two kinds do have to be teased apart by query implementations. 

I have proposed above one way to represent a statement about the statement (:Foo h:correlation :Bar), reification is another approach. And we could no doubt invent our own method. Are you thinking of yet a third method?

Whatever the method, additional "checks" (using the term liberally) will be required. For example, if we are trying to find all of the nodes pointed to by h:correlation links radiating out from :Foo then the query implementation will find (:Foo h:correlation :Bar) to be a match and will find (:C1 :valerys-favorite "True"..) not to be a match. I believe that this the "checking" that you are referring to. And yes, I agree that this is needed. Again, we have to separate out the entities by querying.

Of course if the underlying triple/quadstore (e.g. RDB) is properly indexed by subject-entity (as it sure should be!), then matching is not found by iterating through all statements looking for ones whose subject == :Foo, they are found through indexing. So in this case the "check" that you're refering to is implemented by indexing. Much faster.

In C2

:C1

{

:Foo

h:correlation :Bar;

}

:C2

{

:Foo

h:correlation: :Baz;

:C1

:valerys-favorite "True"^^xsd:boolean

}

In this case we have even more problem. For the quad  ":C2 :C1 :valerys-favorite "True"^^xsd:boolean" we need to iterate all named graphs in a context, to check whether ":C1 :valerys-favorite "True"^^xsd:boolean" quad is metadata or entity.

[Again, I don't like the word choices you're using to make the distinction between metadata and entity because everything is an entity. But, yes, I know what you're referring to.] Don't forget that every entity has type (rdf:type) so you can tell by inspection that C1 is an instance of Context. For clarity I didn't include the rdf:type attributes in the above example. So with one test you can know if the entity is an "entity" or "metadata" to use your words. So I'm not sure I agree about the need to iterate through all named graphs. Or maybe I'm misunderstanding you.

Also, using Named Graphs for metadata obliges each statement to be hold in a different named graph. So, we'll have a lot of subcontexts (one subcontext per each metadata).

Yes, that's why the underlying storage is often implemented as a quad.

BTW, if we would convert the data of context from "TRIX" (NG4J format) into common RDF format, we would lose graph names. As a result, all metadata statements will became entities.

I understand. Once we start using named graphs there's no going back. (Hopefully this named graph stuff (or something like it) will be incorporated into RDF 2.0 in a few years).