Paul,
> 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.
Actually, I suppose it should take about 2-3 weeks to implement proposed NG4J
CP. But I suppse we need to harmonize all architectural questions
(authentication, access control, schema/model context, metadata, etc) before.
Also, my comments are related to the whole idea about using named graph
(subcontext) for metadata on attribute. Not only NG4J can be used to implement
it. Neo4J, Infogrid, etc., can be used in the same way too.
> 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?
I have no any other idea. If we chose to implement it, I would prefer the first
case:
> >> :C1
> >> {
> >> :Foo
> >> h:correlation :Bar;
> >> :C1
> >> :valerys-favorite "True"^^xsd:boolean
> >> }
> [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.
Understand.
Thanks,
Sergey Lyakhov
On Tue, 8 Jun 2010 11:04:43 -0400
Paul Trevithick <[email protected]> wrote:
> 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
