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).
_______________________________________________
higgins-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/higgins-dev
