Re: Scoping bnodes

I guess the gist of it is that Topic Maps are higher level than RDF, they have more semantics build in. You define classes with certain properties like preferred names and alternative names and associaztions between classes and scopes on certain attributes. Then you add occurrences of those classes. The model is nowhere as flexible as RDF which is both its strength and its weakness. It is tailored to specific use cases - like e.g. aligning documentations from different sources - and provides a very nice primitive/template/idiom for them. There was some work on aligning Topic Maps and RDF and one of the most mature was I think Lars-Marius Garshol’s 'Q-model' - Q like in quints [0], but he tried quads too. 

In those days I liked Topic Maps much more than RDF precisely because they had that notion of scope. They also got the distinction between subject indication and denotation right from the start. That was one of the main problems when trying to align them with RDF.

Thomas (L.)


[0] http://www.ontopia.net/topicmaps/materials/the-q-model.pdf

> On 29. Nov 2018, at 05:18, Thomas Passin <tpassin@tompassin.net> wrote:
> 
> 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 08:56:48 UTC