Re: Scoping bnodes

On 11/28/2018 10:10 PM, Pat Hayes wrote:
> On 11/27/18 9:16 AM, Thomas Passin wrote:>
>  > On 11/27/2018 12:43 AM, Pat Hayes wrote:
>  >> I think this is a very basic and important point. It is what I
>  >> meant, expressed differently, by saying that RDF has no way to
>  >> indicate scope. Bnodes in RDF are, logically, existentially
>  >> quantified variables, but RDF has no way to indicate, and
>  >> therefore no way for anyone to know, where the quantifiers are
>  >> which bind those variables. So, for example, if we assume they
>  >> are just outside each RDF document, then we should standardize
>  >> bnodeIDs apart when merging; but if we assume they have larger
>  >> scope, then maybe we shouldn’t. Bnodes introduced to encode
>  >> structures like n-ary relational assertions, or lists, or some
>  >> complicated piece of OWL syntax, should have a very narrow
>  >> scope corresponding to the exact boundaries of those
>  >> structures, and hence should be ‘invisible’ from outside (which
>  >> is why it is fine to make them vanish in a higher-level syntax
>  >> using [ ] or ( ).)
>  >>
>  >> Ideally, RDF2 should provide for these structures directly, but
>  >> maybe we can get the benefit with a relatively tiny step, just
>  >> by having a syntax for RDF which has explicit scoping brackets.
>  >> Off the cuff, imagine a variant of NTriples in which a subset
>  >> of triples can be enclosed in brackets, say [  ] (or something
>  >> else if thse are already taken) to indicate that any bnode ID
>  >> in a triple inside the bracket is local to those triples, ie is
>  >> ‘bound'. Current RDF engines which do not make use of this
>  >> information can simply ignore them, since they do not change
>  >> the RDF meaning of the graph, but they may provide useful
>  >> information to newer engines. For example, they might make it a
>  >> lot easier to parse OWL syntax (‘Manchester’ syntax) from OWL/RDF.
>  >
>  > This is the kind of thing I think about when I talk about
>  > "idioms" of usage.  This particular example could perhaps be
>  > achieved by marking the bnode with a "scope" relationship. You
>  > suggest above that such a scope would take a syntax change, but I
>  > think that you could just state the scope using the
>  > already-existing syntax. You'd have to invent a few new types,
>  > that's all.
> OK, I don't follow this, but I'd like to. Can you briefly explain how 
> this would work?

Well, in Topic Maps, everything is a topic, though there are a few 
specialized topic types, like associations (n-ary relationships) and 
scopes.  A topic may optionally have a scope attached, which you can 
think of as an attribute or property (and yes, a scope can have a topic 
type of its own if you want).  In RDF, you would assign a scope using a 
"has-scope" predicate.  The scope object itself would need to have a 
type or class to distinguish it from other scopes.

I know that this complicates the graph, but it allows you to filter on 
the scope type.  And if that scope type denotes the boundaries of some 
complex b-node object, that gives you a way - without modifying current 
RDF standards - to find them, as you say in passage quoted above.

I suppose another way (instead of scope nodes) would be to put some 
intelligence into the IDs themselves. Then objects within the same 
boundaries could contain the same scope-fragment as a special part of 
their identifiers, perhaps using the #fragment for that purpose.  That 
might make it hard to have more than one scope for a given b-node, 
though, and having multiple scopes can be useful.

To sketch out how these scopes could be used in practice (in addition to 
indicating boundaries), suppose we have a graph that contains 
information about different sports, like baseball and football (either 
American or world, doesn't matter here).  If I add to each topic a scope 
for "scope-type-baseball" or "scope-type-football", then I can easily 
filter the entire graph for just those sports.  This would be really 
hard to do with a typical RDF graph unless it includes some information 
analogous to scopes.  Declaring that certain nodes belong to a type that 
is a subset of a "sports" class might do it, but still you would have to 
add a "sports-type" class to each node of interest.  That would be 
nearly the same mechanism as Topic Map scopes, if you get right down to it.

It's design patterns like these that I keep calling "idioms".  The tools 
have to know how to understand them, but they don't go outside of the 
standards.

>  > Topic Maps has always had scopes built in. Since Topic Maps
>  > scopes can be drawn as part of a diagram - i.e., using nodes and
>  > edges - they can be modeled with the current version of RDF
>  > without (I think) any changes.
> Hmm. Let me ask: if I have N triples to enclose in a single scope, how 
> many 'extra' triples will I have to use to do that?

More than one might like, I imagine, since the scope objects have to be 
typed to be useful for filtering and finding boundaries.  And in the 
most complicated case, a scope relation might need to be added to each 
node within the boundary of interest.  A Topic Map topic node has 
provisions for any number of scopes baked into its definition.  But if 
you think of it in terms of nodes and lines for each binary scope 
property, it wouldn't be much different from what you would have to do 
to model it with RDF.

In my experience with Topic Maps, scopes  can be invaluable because they 
give you something well-defined to index on for implementing filters.

I'm afraid that wasn't as concise as you asked for!

TomP

>   OTOH, Topic Maps do not have the
>  > equivalent of bnodes - every topic (i.e., every concept) has an
>  > ID. That was because the intent was to make everything (every
>  > concept) something that could be talked about.  Even n-ary
>  > relationships (called associations) have IDs, since they are
>  > concepts that could in principle be talked about.
> RDF also of course allows relations to be talked about, even though it 
> only has the binary version. I fully endorse this: the ISO Common Logic 
> standard describes a version of first-order logic which allows all 
> relations to be talked about (and quantified over!)
> 
>  >
>  > Of course, tools and people would need to understand what is
>  > meant; that is outside the purview of the current standards and
>  > would constitute one of those idioms of use.  All we'd need is a
>  > document containing the standardized form of the idiom and its
>  > interpretation.
> Sounds tempting, for sure.
> 
> Pat
> 
>  >
>  >
>  >
>  >

Received on Thursday, 29 November 2018 04:18:28 UTC