Re: defining the semantics of lists
Jiří Procházka <[email protected]> Sat, 13 Jun 2020 18:36:44 +0200
| Newsgroups | gmane.org.w3c.semantic-web |
|---|---|
| Message-ID | <[email protected]> |
------Q4T7436BIK1ST06ISXKPBWP6JEY5IW Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Just adding a vocabulary for describing container size, without any special= semantic implications, is of course easy=2E There is the question if this = should be in the "rdf" namespace, which would make it a harder task=2E Peop= le like myself would like RDF to be a minimalist unopinionated foundation t= o build upon=2E It would seem like cluttering=2E I'd prefer if collections = etc=2E had their own vocabulary(ies), perhaps opinionated, with semantics e= ven=2E The attitude towards change is understandable when you take in context tha= t the whole semantic web project is interesting to people from different ba= ckgrounds, for different purposes=2E Hence the focus on a minimalist founda= tion and opposition to evolving RDF into a kind of a Frankenstein-swiss-arm= y-knife (which you could say it already is, if you are being strict enough)= =2E Backwards compatibility is important for the reason that breaking change m= akes upgrading the same (or close to) as replacing it with something diffe= rent=2E=20 I agree on many points regarding RDF issues (named graphs etc=2E) but for = me these are also underlying issues to my main issue, that I don't see much= movement in direction towards a modular machine-first system, built on a c= ommon minimalist foundation, with an ecosystem of easily integrated compone= nts to support the desired use cases=2E What we have is a sprawl of mostly = academic projects which are often very difficult to integrate=2E We are lac= king some common foundations and established ways how to build on them=2E F= or example we don't have established answers to these questions: When exactly is it right to build semantic extensions? When to build a vocabulary/ontology? How should the semantics extensions be built in order to be as interoperab= le as possible? Best,=20 Jiri On June 11, 2020 12:02:07 AM GMT+02:00, "thomas l=C3=B6rtsch" <tl@rat=2Eio= > wrote: > > >> On 10=2E Jun 2020, at 22:30, Ji=C5=99=C3=AD Proch=C3=A1zka <ojirio@gmai= l=2Ecom> wrote: >>=20 >> Right, as has been pointed out by many, changing or extending RDF >> semantics would be extremely difficult task, but it isn't necessary=2E > >There=E2=80=99s two things: > >1) Adding a property to the Container vocabulary as _describing_ the >size of a container wouldn=E2=80=99t change the semantics of RDF=2E We di= scussed >at length in this thread what can and can=E2=80=99t be achieved when chan= ging >the fundamentals of RDF is not an option - and I sure think it isn=E2=80= =99t=2E > >2) The attitude towards change in this community is difficult to say >the least=2E When Dan Brickley posted his very interesting history >lessons a few moths ago I realized that reification had been considered >for deprecation around 2000 already=2E OMG=2E On the one hand we are tryi= ng >to build something of unprecedented size and reach, on the other hand >we can=E2=80=99t make the slightest backwards incompatible change from da= y 1 >on? This attitude is insane and it only leads to the standard getting >stale and eventually being replaced by soemthing new altogether - but >at a much hingher cost to everybody involved than some breaking changes >would occurr=2E >I was a the RDF Next Steps Workshop in Stanford 2010 (it was open to >everbody and I couldn=E2=80=99t resist) and I remember well the vivid arg= ument >that we would risk uptake and adoption that was just about to start if >we changed anything more than the most pressing technicalities=2E Last >year at the Berlin Workshop I heard that now it=E2=80=99s too late for pr= ofound >change as the installed base is already to big, that ship has sailed=2E >So I must have missed the historic millisecond, around 2016 and a half >presumably, when the stars had aligned, once and for all? What a choke, >what a farce=2E Occassionally dark forecasts are made that all Semantic >Web companies will go bancrupt if we introduce more than the most >pressing changes=2E In the meantime a new industry of now about the same >size than ours grew up - Property Graphs - on the only grounds that >they have better usability and meta modelling=2E So who will gp bancrupt >soon and why exactly? And a handful of companies support RDF* already - >probably because they don=E2=80=99t want to get bancrupt, not because cha= nge is >so impossibly hard and shouldn=E2=80=99t even be attempted=2E > >> Easier would be to make your own RDF collection/container vocabulary > >So, I=E2=80=99d say change is good and is indeed pretty necessary=2E If n= obody >cares and just dabbles on heir own vocabulary instead of trying to fix >the mothership RDF there won=E2=80=99t be much reason to fix it soon enou= gh=2E It >would be easier for sure but not very sustainable=2E >The situation with lists is a classic SNAFU=2E But lists are the easiest >part=2E Identifcation is broken and no one even cares anymore=2E "Just us= e >AI to disambiguate" I hear=2E Reification is a mess (and RDF* in its >current state might make it better, or worse) and Named Graphs have no >semantics, so there is no sound meta modelling in RDF=2E OTOH everybody >who doesn=E2=80=99t work on well contained single topic applications will >acknowledge that the Semantic Web needs an agreed upon facility to >model context and refication=2E That requires change, and it requires a >vision about how everything can fit together=2E And it is about time=2E > >> and >> a validation language for it=2E The language would have its own >semantics, >> possibly backed by some formal logic=2E The language syntax could be >RDF=2E >> In many ways Shapes Constraint Language (SHACL)[1] could be an >> inspiration (also has RDF as syntax), could be used by your language, >or >> your language could be a SHACL extension=2E Overall, what you are going >> for sounds like a generalization of an application of SHACL=2E > >A property to desribe the intended size of a Container would belong to >RDF=2E Constraints to enforce such a limit locally in apllications would >belong to Shacl, Shex etc=2E But I=E2=80=99m currently trying to figure o= ut if >lists as proper datatypes aren=E2=80=99t a better way forward=2E > >>> But how could we enforce such constraint descriptions not just in >> applications but within the OWA realms of RDF? >>=20 >> Do you mean make entire RDF graphs invalid just because it doesn't >fit >> some constrains for a particular purpose? Why would that be >desirable? >> Even if a graph says something which is invalid for some purpose, it >> could be valid for another purpose - a simple example being RDF >> visualization=2E > >Closing the world for some application shouldn=E2=80=99t inflict the Open= World >around it=2E A dataset might have to undergo certain procedures and >scrutiny before I feed it into my application=2E Some applications >certainly demand such restrictivity=2E That doesn=E2=80=99t say anything = about >the uses and usefulness of that dataset outside of such a specific >application=2E > >> As a side note, if you decide to go down the rabbit hole, you might >want >> to consider handling collections restricted to members of a >particular >> class/datatype or their subclasses=2E > >A Series container with an explicit extension hook might be a nice >idea: immutability was just one example=2E But it could also be >overkill=2E > > >Best, >Thomas > > >> Cheers, >> Jiri >>=20 >> [1] https://www=2Ew3=2Eorg/TR/shacl/ >>=20 >> On 6/8/20 12:19 PM, thomas l=C3=B6rtsch wrote: >>>> On 4=2E Jun 2020, at 01:40, Ji=C5=99=C3=AD Proch=C3=A1zka <ojirio@gma= il=2Ecom> wrote: >>>>=20 >>>> This has been an interesting thread to follow, but from the start >I've >>>> felt a clearly stated use case is missing=2E This would clear up many >>>> things, possibly pointing to a solution which doesn't require >changes to >>>> RDF(S) semantics at all=2E >>>>=20 >>>>> I remember someone (Pat?) rightly saying that RDF was not a data >>>> structure language, but a KR (or something like that)=2E >>>>> So simply wanting the sort of things that programming languages >have >>>> as data structures is not necessarily a useful thing to spend time >on=2E >>>>=20 >>>>> I much prefer predicates to be specific to the range and domain >that >>>> they are working over=2E >>>>=20 >>>> Agreed, personally I think the rdf:List, RDF containers >vocabularies >>>> should be used mainly as base classes/properties to be subclassed >in >>>> domain specific schema or perhaps not at all=2E >>>>=20 >>>> That said, one might be describing things like APIs in RDF=2E In such >>>> cases one might describe some examples of input, having to be >careful to >>>> not define them with an unintended structure (for example a >branching or >>>> looping list)=2E If this was the use case, RDF authoring tools could >>>> feature warnings for irregular structures=2E >>>>=20 >>>> An interesting use case is describing APIs accepting RDF data as >input=2E >>>> Ideally it should be using a domain specific schema, but I can see >it >>>> often having constructs similar to rdf:List or RDF containers=2E The >APIs >>>> descriptions should also definite how unexpected inputs are >treated=2E >>>> This could be standardized, separately to RDF specifications=2E >>>>=20 >>>> These are the use cases which I thought of, I would like to know of >>>> others=2E I don't think a change of RDF semantics would be needed for >these=2E >>>=20 >>> Right, no need to change the RDF semantics=2E It's two things however: >>> A what RDF can describe >>> B how descriptions can be enforced as constraints >>>=20 >>> A >>> Lists in RDF can be described as >>> - closed (rdf:List) >>> - ordered (rdf:list, rdf:Seq, rdf:Bag, rdf:Alt) >>> - without duplicates (rdf:Alt) >>> - with preferred member (rdf:Alt) >>> This is a bit messy and not all combinations are available=2E Adding a >'last' attribute to Containers might ameliorate the situation=2E The >rdf:Series class that I proposed mainly as an example to facilitate >discussion could be extended to address all those properties and maybe >more: >>>=20 >>> // A new subclass of Container that very explicitly >describes >>> // size, preferred alternative, ordering and duplicates=2E >>> // Ordering and duplicates default to TRUE=2E >>> // If no attributes are set Series corresponds to Seq=2E >>> // This container type has the combined semantic >expressivity >>> // of Seq, Bag and Alt plus the capability to describe >its size=2E >>> // The immutable property is a hint that such a newly >defined >>> // construct could indeed be used to describe a few more >things=2E >>>=20 >>> Series subClassOf Container >>> last domain Series >>> range ContainerMembeshipProperty >>> pref domain Series >>> range ContainerMembeshipProperty >>> order domain Series >>> range Boolean >>> dupes domain Series >>> range Boolean >>> immutable domain Series // why not reach for the stars=2E= =2E=2E >>> range Boolean >>>=20 >>> B >>> Translating those descriptions to constraints can be tricky as >Peters questions proved but it certainly can be done in one way or the >other=2E APIs described in RDF, OWL DL formalizations, rules, Shexl >constraints are all viable options=2E But how could we enforce such >constraint descriptions not just in applications but within the OWA >realms of RDF? That requires closing the world around the description=2E >Named Graphs come to mind=2E So basically: >>> - define a way to guarantee sound naming semantics for Named Graphs, >>> - define a way to attribute graphs with semantic extensions, >>> - define such extensions (like e=2Eg=2E an app friendly local >CWA/NAF/UNA walled garden) >>> - teach RDF consuming applications to process data according to the >rules of such extensions locally, within those graphs >>> and be done with it? >>>=20 >>> Thomas >>>=20 >>>=20 >>>> Best, >>>> Jiri >>>>=20 >>>> On 6/4/20 12:02 AM, Hugh Glaser wrote: >>>>> +1 >>>>>=20 >>>>> I've followed the long discussion (as best I could!)=2E >>>>> And what I kept wanting to know was an example of how whatever is >being proposed might be used=2E >>>>> I remember someone (Pat?) rightly saying that RDF was not a data >structure language, but a KR (or something like that)=2E >>>>> So simply wanting the sort of things that programming languages >have as data structures is not necessarily a useful thing to spend time >on=2E >>>>>=20 >>>>> And I think there are implications that raise questions=2E >>>>> For example, if what you (plural) are trying to be able to do is >something like tracks on a CD, then a predicate to connect things >should be more like >>>>> foo:nextTrack than simply foo:Next =2E >>>>> How would this happen? - Can all the constructs proposed be >sub-property'ed and/or sub-classed? Or however else it happens=2E >>>>> And then would querying work? >>>>> And there might be questions such as what happens when that CD is >released with a bonus track? >>>>>=20 >>>>> I would certainly not want anything as general as foo:next >floating around my RDF=2E >>>>> I much prefer predicates to be specific to the range and domain >that they are working over=2E >>>>>=20 >>>>> Mind you, I have to admit I have never used any of the rdf >Seq/Collection etc=2E >>>>> I haven't felt the need, and I prefer to represent the knowledge >as close to its natural form as possible, rather than bend it to fit >into some generic, and possibly slightly different form=2E >>>>>=20 >>>>> It is the same problem in Lisp, of course - which is why things >like Structs and Cobol Data Division were invented=2E >>>>> If I could be given some view of the sorts of applications you are >thinking of, I would be better able to understand whether the >suggestions being made are fit for purpose=2E >>>>>=20 >>>>> The bottom line, in case you are wondering: >>>>> I'm not sure why I would need lists in RDF=2E >>>>> And I have a nagging suspicion that people that want them are >trying to do things in programming ways, rather than stepping back and >doing the KR=2E >>>>> But I have no evidence for that :-) >>>>>=20 >>>>> Best >>>>> Hugh >>>>>=20 >>>>>> On 2 Jun 2020, at 19:00, Peter Patel-Schneider ><pfpschneider@gmail=2Ecom> wrote: >>>>>>=20 >>>>>> TLDR: Without a firm notion of what chains are for and a >specification >>>>>> of how they work it is not possible to determine whether they are >non- >>>>>> problematic=2E >>>>>>=20 >>>>>> On Mon, 2020-06-01 at 23:11 +0200, thomas l=C3=B6rtsch wrote: >>>>>>> Hi Peter, >>>>>>>=20 >>>>>>> my initial question when starting this thread was: what holds >>>>>>> rdf:Containers back from having the same semantic weight as >>>>>>> rdf:Lists? What could be done to overcome that deficit=2E There >are >>>>>>> some reasons why I was asking that and not the least was to >>>>>>> understand semantics of lists - hence the subject line=2E With the >>>>>>> question came the idea for an answer: an rdfx:length property to >>>>>>> specify the length of a Container and thereby close it=2E With >Pat's >>>>>>> help that developed into an rdfx:last property because that way >we >>>>>>> don=E2=80=99t have to introduce arithmetic into the semantics=2E T= he >intention >>>>>>> is exactly the same: provide a means to close rdf:Containers, >make >>>>>>> them finite=2E Such a finite container could then be used instead >of >>>>>>> rdf:Lists=2E It would have a less obtrusive syntax, need fewer >triples, >>>>>>> perform much faster in the usual triple stores, would be easier >to >>>>>>> query and could be used with OWL DL=2E The only real downside so >far: >>>>>>> no syntactic sugar in Turtle - that would be another topic=2E >>>>>>>=20 >>>>>>> So the short answer to your questions is: the aim is to provide >>>>>>> Containers with a semantics similar to rdf:Lists respectively to >find >>>>>>> out what is needed to reach that goal=2E >>>>>>>=20 >>>>>>> The longer answer is: rdf:Containers intuitively provide some >>>>>>> semantics already=2E Membership properties are ordered by integer >>>>>>> values, starting with 1 and incremented by 1 for each entry=2E >What=E2=80=99s >>>>>>> missing compared to lists is to be able to close a container, to >make >>>>>>> it finite=2E Most of your questions can intuitively be answered >from >>>>>>> there: >>>>>>>=20 >>>>>>>> On 1=2E Jun 2020, at 18:54, Peter F=2E Patel-Schneider < >>>>>>>> pfpschneider@gmail=2Ecom> wrote: >>>>>>>>=20 >>>>>>>> I've been looking at the suggestions to set up chains in RDF >and I >>>>>>>> have a >>>>>>>> number of questions=2E >>>>>>>>=20 >>>>>>>> What are chains supposed to be for? >>>>>>>=20 >>>>>>> See above=2E >>>>>>=20 >>>>>> Saying that chains are supposed to have the same semantics as >something >>>>>> else doesn't say what chains are for=2E There are lots of things >that >>>>>> chains could be for - OWL DL says that rdf:first/rdf:rest is for >syntax >>>>>> that needs a sequence of elements=2E >>>>>>=20 >>>>>> You might have said that chains are for syntax, or for some more >>>>>> general purpose, perhaps platonic unchangeable simple lists, but >>>>>> without a purpose it is hard to determine whether any proposed >>>>>> specification is correct or useable or useful=2E >>>>>>=20 >>>>>>>> What are the semantics of chains (saying a bit more than >>>>>>>> rdf:Collection is not adequate)? >>>>>>>=20 >>>>>>> See above=2E >>>>>>=20 >>>>>> Well, containers don't have significant semantics in RDF beyond >their >>>>>> triple semantics, just some informal hand waving that leaves very >many >>>>>> questions unanswered=2E >>>>>> See https://www=2Ew3=2Eorg/TR/rdf11-mt/#rdf-containers for more on >the lack >>>>>> of semantics of containers=2E >>>>>>=20 >>>>>>>> Is a chain more than a bunch of triples? >>>>>>>=20 >>>>>>> Yes, otherwise what would be the point? >>>>>>=20 >>>>>> OK, what is this extra? >>>>>>=20 >>>>>>>> What counts as a chain? >>>>>>>> Can chains be circular? >>>>>>>=20 >>>>>>> No=2E >>>>>>>=20 >>>>>>>> Can they be infinite? >>>>>>>=20 >>>>>>> No, that=E2=80=99s the whole point, remember? >>>>>>>=20 >>>>>>>> Can they share heads? >>>>>>>=20 >>>>>>> No, there can be only one membership property :_1 >>>>>>=20 >>>>>> Oops, I meant sharing tails, as in two lists that share a tail=2E >>>>>> Implementing as in RDF containers prevents sharing tails=2E >>>>>>=20 >>>>>>>> Can they be multi-tailed? >>>>>>>=20 >>>>>>> No, there can be only one membership property per integer >>>>>>=20 >>>>>> This is different, and only shows up if there is a separate tail >aspect >>>>>> of chains, which is not compatible with implementing as >containers=2E >>>>>>=20 >>>>>>>> Can they have multiple values for one position? >>>>>>>=20 >>>>>>> Same question as before, isn=E2=80=99t it? >>>>>>=20 >>>>>> No, but how is this specified or enforced? What happens in an >RDF >>>>>> graph that contains triples like: >>>>>> ex:C a rdfx:Chain =2E >>>>>> ex:C rdf:_1 ex:a =2E >>>>>> ex:C rdf:_1 ex:b =2E >>>>>> ex:C rdfx:last rdf:_1=2E >>>>>> Is this invalid syntax? Does it imply that ex:a and ex:b denote >the >>>>>> same individual? >>>>>>>=20 >>>>>>>> Can chains be elements of chains? >>>>>>>=20 >>>>>>> Yes, but that is another topic >>>>>>=20 >>>>>> Determining whether chains can be elements of chains is >important, and >>>>>> could be answered either way=2E >>>>>>=20 >>>>>>>> Can chains be ungrounded? >>>>>>>=20 >>>>>>> I don=E2=80=99t understand=2E >>>>>>=20 >>>>>> Can a chain be an element of itself, maybe indirectly? If so, >the >>>>>> chain can be called ungrounded=2E Is this allowed? >>>>>>=20 >>>>>>>> Is it possible to have a chain with no elements? >>>>>>>=20 >>>>>>> No, as there is no :_0 membership property=2E >>>>>>=20 >>>>>> That's very limiting=2E Empty chains (or lists or sets or bags) >are >>>>>> important=2E >>>>>>=20 >>>>>>> Maybe you mean missing list entries? Any list items at list >positions >>>>>>> less or equal than the 'last' one that are not listed can be >entailed >>>>>>> as being blank nodes=2E >>>>>>=20 >>>>>> OK, here is a semantic upgrade from triples, and from containers=2E > How >>>>>> will this meaning be specified? >>>>>>=20 >>>>>>>=20 >>>>>>>> In my view it is a good idea to determine what chains are >supposed >>>>>>>> to be >>>>>>>> fore and how they are supposed to work before the syntax (and >any >>>>>>>> axiomatization) of chains is presented, not least so that it >can be >>>>>>>> determined whether the syntax (and axiomatization, if present) >>>>>>>> actually >>>>>>>> supports what is wanted=2E >>>>>>>=20 >>>>>>> I think we did that already and I hope you have a clearer >picture >>>>>>> now=2E >>>>>>=20 >>>>>> There are still questions that need to be answered? For example, >are >>>>>> two chains with the same elements the same chain? As you have >stated >>>>>> above that there are some semantics beyond just triples, you need >to >>>>>> say what these semantics are=2E >>>>>>=20 >>>>>>>> Making chains be rdf:Seq plus an explicit stop point appears to >>>>>>>> answer some >>>>>>>> of these questions, but the implications of this setup should >be >>>>>>>> spelled out >>>>>>>> explicitly=2E Further not all the questions are answered=2E >>>>>>>=20 >>>>>>> Will they ever be? >>>>>>=20 >>>>>> Yes=2E You can just say that "This is the meaning of chains=2E"=20 >That >>>>>> doesn't prohibit others from using chains in situations where >more >>>>>> meaning is required or suitabe, but it does limit what *the* >meaning of >>>>>> chains is=2E >>>>>>=20 >>>>>> In essence, you are proposing a new kind of thing, like a set=2E=20 >How >>>>>> does this thing work? >>>>>>=20 >>>>>>>> For example, what happens if there are two rdf:_<n> values in a >>>>>>>> chain for a particular <n>? >>>>>>>=20 >>>>>>> It is an inconsistency=2E >>>>>>> What happens if it happens to occurr all the same is another >question >>>>>>> that we probably can=E2=80=99t answer=2E >>>>>>=20 >>>>>> You mean an RDF inconsistency? That seems very harsh=2E If any >chain in >>>>>> an RDF graph has multiple values for any of its elements then the >>>>>> entire graph becomes unsatisfiable=2E >>>>>>=20 >>>>>>>> (This might be particularly problematic if the two values are >both >>>>>>>> container >>>>>>>> membership properties=2E) What happens if there are values for >>>>>>>> rdf:_<n> with >>>>>>>> n greater than the stop point? >>>>>>>=20 >>>>>>> It is an inconsistency=2E >>>>>>> What happens if it happens to occurr all the same is another >question >>>>>>> that we probably can=E2=80=99t answer=2E >>>>>>>=20 >>>>>>>=20 >>>>>>>> What happens if there are multiple stop points? (This seems to >be >>>>>>>> particularly problematic=2E) >>>>>>>=20 >>>>>>> It is an inconsistency=2E >>>>>>> What happens if it happens to occurr all the same is another >question >>>>>>> that we probably can=E2=80=99t answer=2E >>>>>>>=20 >>>>>>>=20 >>>>>>>> What happens if the value of rdfx:last is not one of the >>>>>>>> rdf:_<n>? >>>>>>>=20 >>>>>>> If there is a bigger rdf:_<n> then it is an incosistency, see >above=2E >>>>>>=20 >>>>>> So any unusual aspects of a chain render the entire RDF graph >>>>>> meaningless=2E That seems even more harsh=2E >>>>>>=20 >>>>>>=20 >>>>>>>> What happens if a chain is one of its own elements? >>>>>>>=20 >>>>>>> The question makes no sense to me=2E There are infintely many ways >to >>>>>>> construct infinitely large or infnitely deep nested structures >at any >>>>>>> list item position=2E Why do you ask for that specific one? Is it >an >>>>>>> achievable goal to develop a definition that successfully rules >out >>>>>>> all pathological variants? >>>>>>=20 >>>>>> This is something that is easy to do in RDF and similar patterns >are >>>>>> common in RDF graphs=2E Is the following acceptable as a chain: >>>>>> ex:C a rdfx:Chain =2E >>>>>> ex:C rdf:_1 ex:C =2E >>>>>> ex:C rdf:last rdf:_1 =2E >>>>>>=20 >>>>>> This is something that can be problematic, depending on what the >>>>>> meaning of chains is supposed to be=2E >>>>>>=20 >>>>>> Adding a new thing to RDF requires consideration of how it >interacts >>>>>> with the rest of RDF, including its "say anything about anything" >>>>>> philosophy=2E >>>>>>=20 >>>>>>=20 >>>>>>>> Are chains complicated because of the infinite vocabulary >required? >>>>>>>=20 >>>>>>> That would be a question that I would hope you could answer=2E >>>>>>=20 >>>>>> This question cannot be answered without a specification of what >chains >>>>>> are supposed to be=2E In some specifications the infinite >vocabulary >>>>>> isn't more of a problem than it is in RDF=2E In others it might >me=2E >>>>>>=20 >>>>>>>> One way to "specify" chains, of course, is to just say that >they >>>>>>>> are a set of >>>>>>>> triples, and no more=2E I don't think that this is what is >desired >>>>>>>> here, though=2E >>>>>>>=20 >>>>>>> I don=E2=80=99t think it is helpful or promising or even possible = to >rule out >>>>>>> explicitly everything that you don=E2=80=99t think is desired=2E I= hope >however >>>>>>> that you have a better idea now of the issue at hand and we can >get >>>>>>> to the real business=2E >>>>>>=20 >>>>>> I disagree strongly=2E The specification of chains could be very >weak - >>>>>> just triples, for example=2E That specification is viable, but >>>>>> apparently not what you want=2E Other specifications might add >>>>>> entailments, but then the interactions of these entailments with >the >>>>>> rest of RDF needs to be investigated=2E It's very much like >adding a >>>>>> new construct to a programming language - its interactions with >the >>>>>> other constructs of the language need to be analyzed to see what >>>>>> problems come up=2E Without a firm specification of the construct >it is >>>>>> not possible to determine what problems it will create=2E >>>>>>=20 >>>>>>> Pat tried his best to teach me that RDF only _describes_, not >>>>>>> _prescribes_ things - and lists are just another thing=2E Now, I >surely >>>>>>> need more time to fully wrap my head around that but it seems >that >>>>>>> all your questions and all my answers aim at perscribing, not >>>>>>> describing=2E I noticed how the RDF Semantics document dances >around >>>>>>> that topic by clarifying that it can=E2=80=99t preclude all sorts = of >>>>>>> pathological containers and collections=2E Therefor I tried to >come up >>>>>>> with the least intrusive way to describe an intent about some >>>>>>> container, namely that it has ony a certain number of members=2E >>>>>>> Everything else comes from the integer order of the membership >>>>>>> properties=2E That was good enough for the last 20 years so it >should >>>>>>> be good for the future too=2E I can wholeheartedly assure that my >>>>>>> honest intent is only to describe that some list of mine is >finite >>>>>>> and not prescribe something about anybody elses list=2E >>>>>>>=20 >>>>>>> OWL DL makes some remarks what it expects from rdf:Lists, >namely: >>>>>>> "When a list pattern is matched to G, all list variables _:xi >and >>>>>>> _:xj with i =E2=89=A0 j MUST be matched to different nodes; furthe= rmore, >it >>>>>>> MUST NOT be possible to match the list pattern to two maximal >subsets >>>>>>> of G such that some list variable in the first pattern instance >is >>>>>>> matched to the same node as some (possibly different) variable >in the >>>>>>> second pattern instance=2E This is necessary in order to detect >>>>>>> malformed lists such as lists with internal cycles, lists that >share >>>>>>> tails, and lists that cross=2E" >>>>>>> >https://www=2Ew3=2Eorg/TR/2012/REC-owl2-mapping-to-rdf-20121211/#Mapping_= from_RDF_Graphs_to_the_Structural_Specification >>>>>>>=20 >>>>>>> This is certainly more concise and complete than what I could >come up >>>>>>> with right now but essentially it=E2=80=99s not rocket science eit= her, >it=E2=80=99s >>>>>>> plain text=2E If that=E2=80=99s all that=E2=80=99s needed, then: y= es, I can do >that too >>>>>>> for rdf:Containers with a 'last' property=2E And the gist of it >can be >>>>>>> found above=2E >>>>>>=20 >>>>>> OWL DL only handles some RDF graphs, and is quite explicit on >which RDF >>>>>> graphs are not suitable for OWL DL=2E So OWL DL doesn't have to >handle >>>>>> all RDF graphs, which is not the case here=2E >>>>>>=20 >>>>>>> I hope all this is enough so that you can now answer the >question if >>>>>>> such a 'last' property on rdf:Containers would break anything in >OWL >>>>>>> DL, catapult the ontology out of DL or otherwise look fishy and >>>>>>> suspicious to you=2E >>>>>>=20 >>>>>> Again, as far as OWL DL is concerned, only certain RDF graphs are >>>>>> allowable=2E As far as I can tell, some of these graphs could >contain >>>>>> chains=2E >>>>>>=20 >>>>>>>=20 >>>>>>> Thomas >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>> peter >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On 5/24/20 11:29 AM, thomas l=C3=B6rtsch wrote: >>>>>>>>> [Lots of earlier messages and some of this message snipped=2E] >>>>>>>>> I do now understand how the OWA prohibts any explicit closing >of >>>>>>>>> a list in RDF, how RDF is all about _describing_ things, how >only >>>>>>>>> single triples can be a bearer of truth, how RDF terms >themselves >>>>>>>>> are not to be messed with and how the whole endeavour of >formal >>>>>>>>> semantics under an OWA is walking a very thin line between >what >>>>>>>>> may be inferred and what cannot be ruled out=2E Maybe=2E [0] >>>>>>>>> However I also lost practically all faith in the formal >semantics >>>>>>>>> of Collections and Containers alike=2E If not even the simplest >>>>>>>>> syntactic constraints - only one head, no branching - can be >>>>>>>>> enforced then why bother at all with the semantics of a length >>>>>>>>> attribute? >>>>>>>>>=20 >>>>>>>>> Why even consider an arithmetic extension? Not withstanding >its >>>>>>>>> usefulness in other contexts I=E2=80=99m not convinced that some >>>>>>>>> arithmetic extension can ground the semantics of an >>>>>>>>> rdfx:hasLength property when the rdf:Container it describes >has >>>>>>>>> so little formal standing to build on=2E >>>>>>>>>=20 >>>>>>>>> One could make rdfx:hasLength an owl:AnnotationProperty so its >>>>>>>>> semantics would definitely be reduced to handwaving, providing >a >>>>>>>>> hint to applications if some list probably is complete=2E >Closing a >>>>>>>>> list was deemed useful before but it was implemented with a >>>>>>>>> verbose syntax and in OWL DL it's off limits for users=2E Lists >are >>>>>>>>> so important in practice that IMO that=E2=80=99s reason enough t= o >>>>>>>>> introduce something along those lines, even with _very_ >limited >>>>>>>>> formal semantics=2E >>>>>>>>>=20 >>>>>>>>> I was also pondering the graph based approach that Cory >proposed >>>>>>>>> but for a basic construct like lists (and trees and tables >that >>>>>>>>> can easily be built from it) it seems a waste=2E Graphs should >be >>>>>>>>> used for all kinds of stuff, even for structural features like >n- >>>>>>>>> ary relations, but lists - rather not=2E At least that=E2=80=99s= my >current >>>>>>>>> thinking=2E >>>>>>>>> I think it can be useful in a bigger context like being able >to >>>>>>>>> express that in some application/source/universeOfDiscourse >all >>>>>>>>> lists are closed=2E But I=E2=80=99d rather embed that in a seman= tic >>>>>>>>> extension that fixes a few more things and formally defines a >>>>>>>>> Closed World Scenarios that applications often assume and >>>>>>>>> require=2E >>>>>>>>>=20 >>>>>>>>> Pat has in earlier mails suggested to mark the last item of a >>>>>>>>> list instead of providing a length attribute=2E That didn=E2=80= =99t >really >>>>>>>>> catch on with me because I lacked an idea how to do it=2E >Meanwhile >>>>>>>>> the following vocabulary extension bubbled up in my head: >>>>>>>>>=20 >>>>>>>>> rdfx:Chain rdfs:subClassOf rdfs:Container =2E >>>>>>>>> rdfx:last rdfs:domain rdfx:Chain =2E >>>>>>>>> rdfx:last rdfs:range rdfs:ContainerMembershipProperty =2E >>>>>>>>>=20 >>>>>>>>> _:L rdf:_1 "a" =2E >>>>>>>>> _:L rdf:_2 "b" =2E >>>>>>>>> _:L rdf:_3 "c" =2E >>>>>>>>> _:L rdfx:last rdf:_3 =2E >>>>>>>>>=20 >>>>>>>>> I sort of like it but I=E2=80=99m not convinced that it's really= more >>>>>>>>> elegant=2E >>>>>>>>> Fundamentally it doesn=E2=80=99t seem to make much difference: >>>>>>>>> - Containers still provide only a semantically weak base >>>>>>>>> - a missing 2nd slot would still need to be filled >>>>>>>>> - a surplus 4th slot would still need to be ignored >>>>>>>>>=20 >>>>>>>>> And maybe the counting business on >ContainermembershipProperties >>>>>>>>> would still require an arithmetic extension? Which would still >>>>>>>>> not be worth the trouble because it would only stand on >>>>>>>>> Collections=E2=80=99 shifting semantic sands? >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> BTW: I don=E2=80=99t like the name "Chain"=2E I would prefer "Se= ries" >but >>>>>>>>> I=E2=80=99m not a native speaker and not sure if it captures the >intended >>>>>>>>> purpose well enough=2E Also "Seq" and "Ser" are easy to confuse >>>>>>>>> (but "Ser" gets filed one after "Seq", so that=E2=80=99s good!)= =2E "Fin >de >>>>>>>>> Seq" would of course be even nicer=2E >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Thomas >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> [0] And that the RDF Semantics at >https://www=2Ew3=2Eorg/TR/rdf11-mt/ >>>>>>>>> use the term "intent" although I got ridiculed for introducing >>>>>>>>> it a few mails ago: "The intended mode of use is that things >of >>>>>>>>> type rdf:Bag are considered to be=E2=80=A6 " etc=2E Ha! >>>>>>>>>=20 >>>>>>>> [Lots of previous messages snipped=2E] >>>>>=20 >>>>=20 >>>=20 >>=20 ------Q4T7436BIK1ST06ISXKPBWP6JEY5IW Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <html><head></head><body>Just adding a vocabulary for describing container = size, without any special semantic implications, is of course easy=2E There= is the question if this should be in the "rdf" namespace, which would make= it a harder task=2E People like myself would like RDF to be a minimalist u= nopinionated foundation to build upon=2E It would seem like cluttering=2E I= 'd prefer if collections etc=2E had their own vocabulary(ies), perhaps opin= ionated, with semantics even=2E<br><br>The attitude towards change is under= standable when you take in context that the whole semantic web project is i= nteresting to people from different backgrounds, for different purposes=2E = Hence the focus on a minimalist foundation and opposition to evolving RDF i= nto a kind of a Frankenstein-swiss-army-knife (which you could say it alrea= dy is, if you are being strict enough)=2E<br><br>Backwards compatibility is= important for the reason that breaking change makes upgrading the same (or= close to) as replacing it with something different=2E <br>I agree on many= points regarding RDF issues (named graphs etc=2E) but for me these are als= o underlying issues to my main issue, that I don't see much movement in dir= ection towards a modular machine-first system, built on a common minimalist= foundation, with an ecosystem of easily integrated components to support t= he desired use cases=2E What we have is a sprawl of mostly academic project= s which are often very difficult to integrate=2E We are lacking some common= foundations and established ways how to build on them=2E For example we do= n't have established answers to these questions:<br><br>When exactly is it = right to build semantic extensions?<br>When to build a vocabulary/ontology?= <br>How should the semantics extensions be built in order to be as interope= rable as possible?<br><br><br>Best, <br>Jiri<br><br><br><div class=3D"gmail= _quote">On June 11, 2020 12:02:07 AM GMT+02:00, "thomas l=C3=B6rtsch" <t= l@rat=2Eio> wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0pt= 0pt 0pt 0=2E8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: = 1ex;"> <pre class=3D"k9mail"><br><br><blockquote class=3D"gmail_quote" style=3D"m= argin: 0pt 0pt 1ex 0=2E8ex; border-left: 1px solid #729fcf; padding-left: 1= ex;">On 10=2E Jun 2020, at 22:30, Ji=C5=99=C3=AD Proch=C3=A1zka <ojirio@= gmail=2Ecom> wrote:<br><br>Right, as has been pointed out by many, chang= ing or extending RDF<br>semantics would be extremely difficult task, but it= isn't necessary=2E<br></blockquote><br>There=E2=80=99s two things:<br><br>= 1) Adding a property to the Container vocabulary as _describing_ the size o= f a container wouldn=E2=80=99t change the semantics of RDF=2E We discussed = at length in this thread what can and can=E2=80=99t be achieved when changi= ng the fundamentals of RDF is not an option - and I sure think it isn=E2=80= =99t=2E<br><br>2) The attitude towards change in this community is difficul= t to say the least=2E When Dan Brickley posted his very interesting history= lessons a few moths ago I realized that reification had been considered fo= r deprecation around 2000 already=2E OMG=2E On the one hand we are trying t= o build something of unprecedented size and reach, on the other hand we can= =E2=80=99t make the slightest backwards incompatible change from day 1 on? = This attitude is insane and it only leads to the standard getting stale and= eventually being replaced by soemthing new altogether - but at a much hing= her cost to everybody involved than some breaking changes would occurr=2E<b= r>I was a the RDF Next Steps Workshop in Stanford 2010 (it was open to ever= body and I couldn=E2=80=99t resist) and I remember well the vivid argument = that we would risk uptake and adoption that was just about to start if we c= hanged anything more than the most pressing technicalities=2E Last year at = the Berlin Workshop I heard that now it=E2=80=99s too late for profound cha= nge as the installed base is already to big, that ship has sailed=2E So I m= ust have missed the historic millisecond, around 2016 and a half presumably= , when the stars had aligned, once and for all? What a choke, what a farce= =2E Occassionally dark forecasts are made that all Semantic Web companies w= ill go bancrupt if we introduce more than the most pressing changes=2E In t= he meantime a new industry of now about the same size than ours grew up - P= roperty Graphs - on the only grounds that they have better usability and me= ta modelling=2E So who will gp bancrupt soon and why exactly? And a handful= of companies support RDF* already - probably because they don=E2=80=99t wa= nt to get bancrupt, not because change is so impossibly hard and shouldn=E2= =80=99t even be attempted=2E<br><br><blockquote class=3D"gmail_quote" style= =3D"margin: 0pt 0pt 1ex 0=2E8ex; border-left: 1px solid #729fcf; padding-le= ft: 1ex;">Easier would be to make your own RDF collection/container vocabul= ary<br></blockquote><br>So, I=E2=80=99d say change is good and is indeed pr= etty necessary=2E If nobody cares and just dabbles on heir own vocabulary i= nstead of trying to fix the mothership RDF there won=E2=80=99t be much reas= on to fix it soon enough=2E It would be easier for sure but not very sustai= nable=2E<br>The situation with lists is a classic SNAFU=2E But lists are th= e easiest part=2E Identifcation is broken and no one even cares anymore=2E = "Just use AI to disambiguate" I hear=2E Reification is a mess (and RDF* in = its current state might make it better, or worse) and Named Graphs have no = semantics, so there is no sound meta modelling in RDF=2E OTOH everybody who= doesn=E2=80=99t work on well contained single topic applications will ackn= owledge that the Semantic Web needs an agreed upon facility to model contex= t and refication=2E That requires change, and it requires a vision about ho= w everything can fit together=2E And it is about time=2E<br><br><blockquote= class=3D"gmail_quote" style=3D"margin: 0pt 0pt 1ex 0=2E8ex; border-left: 1= px solid #729fcf; padding-left: 1ex;">and<br>a validation language for it= =2E The language would have its own semantics,<br>possibly backed by some f= ormal logic=2E The language syntax could be RDF=2E<br>In many ways Shapes C= onstraint Language (SHACL)[1] could be an<br>inspiration (also has RDF as s= yntax), could be used by your language, or<br>your language could be a SHAC= L extension=2E Overall, what you are going<br>for sounds like a generalizat= ion of an application of SHACL=2E<br></blockquote><br>A property to desribe= the intended size of a Container would belong to RDF=2E Constraints to enf= orce such a limit locally in apllications would belong to Shacl, Shex etc= =2E But I=E2=80=99m currently trying to figure out if lists as proper datat= ypes aren=E2=80=99t a better way forward=2E<br><br><blockquote class=3D"gma= il_quote" style=3D"margin: 0pt 0pt 1ex 0=2E8ex; border-left: 1px solid #729= fcf; padding-left: 1ex;"><blockquote class=3D"gmail_quote" style=3D"margin:= 0pt 0pt 1ex 0=2E8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;">B= ut how could we enforce such constraint descriptions not just in<br></block= quote>applications but within the OWA realms of RDF?<br><br>Do you mean mak= e entire RDF graphs invalid just because it doesn't fit<br>some constrains = for a particular purpose? Why would that be desirable?<br>Even if a graph s= ays something which is invalid for some purpose, it<br>could be valid for a= nother purpose - a simple example being RDF<br>visualization=2E<br></blockq= uote><br>Closing the world for some application shouldn=E2=80=99t inflict t= he Open World around it=2E A dataset might have to undergo certain procedur= es and scrutiny before I feed it into my application=2E Some applications c= ertainly demand such restrictivity=2E That doesn=E2=80=99t say anything abo= ut the uses and usefulness of that dataset outside of such a specific appli= cation=2E<br><br><blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt= 1ex 0=2E8ex; border-left: 1px solid #729fcf; padding-left: 1ex;">As a side= note, if you decide to go down the rabbit hole, you might want<br>to consi= der handling collections restricted to members of a particular<br>class/dat= atype or their subclasses=2E<br></blockquote><br>A Series container with an= explicit extension hook might be a nice idea: immutability was just one e= xample=2E But it could also be overkill=2E<br><br><br>Best,<br>Thomas<br><b= r><br><blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 1ex 0=2E8e= x; border-left: 1px solid #729fcf; padding-left: 1ex;">Cheers,<br>Jiri<br><= br>[1] <a href=3D"https://www=2Ew3=2Eorg/TR/shacl/">https://www=2Ew3=2Eorg/= TR/shacl/</a><br><br>On 6/8/20 12:19 PM, thomas l=C3=B6rtsch wrote:<br><blo= ckquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 1ex 0=2E8ex; border-= left: 1px solid #ad7fa8; padding-left: 1ex;"><blockquote class=3D"gmail_quo= te" style=3D"margin: 0pt 0pt 1ex 0=2E8ex; border-left: 1px solid #8ae234; p= adding-left: 1ex;">On 4=2E Jun 2020, at 01:40, Ji=C5=99=C3=AD Proch=C3=A1zk= a <ojirio@gmail=2Ecom> wrote:<br><br>This has been an interesting thr= ead to follow, but from the start I've<br>felt a clearly stated use case is= missing=2E This would clear up many<br>things, possibly pointing to a solu= tion which doesn't require changes to<br>RDF(S) semantics at all=2E<br><br>= <blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 1ex 0=2E8ex; bor= der-left: 1px solid #fcaf3e; padding-left: 1ex;">I remember someone (Pat?) = rightly saying that RDF was not a data<br></blockquote>structure language, = but a KR (or something like that)=2E<br><blockquote class=3D"gmail_quote" s= tyle=3D"margin: 0pt 0pt 1ex 0=2E8ex; border-left: 1px solid #fcaf3e; paddin= g-left: 1ex;">So simply wanting the sort of things that programming languag= es have<br></blockquote>as data structures is not necessarily a useful thin= g to spend time on=2E<br><br><blockquote class=3D"gmail_quote" style=3D"mar= gin: 0pt 0pt 1ex 0=2E8ex; border-left: 1px solid #fcaf3e; padding-left: 1ex= ;">I much prefer predicates to be specific to the range and domain that<br>= </blockquote>they are working over=2E<br><br>Agreed, personally I think the= rdf:List, RDF containers vocabularies<br>should be used mainly as base cla= sses/properties to be subclassed in<br>domain specific schema or perhaps no= t at all=2E<br><br>That said, one might be describing things like APIs in R= DF=2E In such<br>cases one might describe some examples of input, having to= be careful to<br>not define them with an unintended structure (for example= a branching or<br>looping list)=2E If this was the use case, RDF authoring= tools could<br>feature warnings for irregular structures=2E<br><br>An inte= resting use case is describing APIs accepting RDF data as input=2E<br>Ideal= ly it should be using a domain specific schema, but I can see it<br>often h= aving constructs similar to rdf:List or RDF containers=2E The APIs<br>descr= iptions should also definite how unexpected inputs are treated=2E<br>This c= ould be standardized, separately to RDF specifications=2E<br><br>These are = the use cases which I thought of, I would like to know of<br>others=2E I do= n't think a change of RDF semantics would be needed for these=2E<br></block= quote><br>Right, no need to change the RDF semantics=2E It's two things how= ever:<br>A what RDF can describe<br>B how descriptions can be enforced as c= onstraints<br><br>A<br>Lists in RDF can be described as<br>- closed (rdf:Li= st)<br>- ordered (rdf:list, rdf:Seq, rdf:Bag, rdf:Alt)<br>- without duplica= tes (rdf:Alt)<br>- with preferred member (rdf:Alt)<br>This is a bit messy a= nd not all combinations are available=2E Adding a 'last' attribute to Conta= iners might ameliorate the situation=2E The rdf:Series class that I propose= d mainly as an example to facilitate discussion could be extended to addres= s all those properties and maybe more:<br><br> // A new subclass = of Container that very explicitly describes<br> // size, preferre= d alternative, ordering and duplicates=2E<br> // Ordering and dup= licates default to TRUE=2E<br> // If no attributes are set Series= corresponds to Seq=2E<br> // This container type has the combine= d semantic expressivity<br> // of Seq, Bag and Alt plus the capab= ility to describe its size=2E<br> // The immutable property is a = hint that such a newly defined<br> // construct could indeed be u= sed to describe a few more things=2E<br><br> Series subClassOf Contain= er<br> last domain Series<br> range ContainerMe= mbeshipProperty<br> pref domain Series<br> range = ContainerMembeshipProperty<br> order domain Series<br> = range Boolean<br> dupes domain Series<br> ran= ge Boolean<br> immutable domain Series // why not reach for= the stars=2E=2E=2E<br> range Boolean<br><br>B<br>Translat= ing those descriptions to constraints can be tricky as Peters questions pro= ved but it certainly can be done in one way or the other=2E APIs described = in RDF, OWL DL formalizations, rules, Shexl constraints are all viable opti= ons=2E But how could we enforce such constraint descriptions not just in ap= plications but within the OWA realms of RDF? That requires closing the worl= d around the description=2E Named Graphs come to mind=2E So basically:<br>-= define a way to guarantee sound naming semantics for Named Graphs,<br>- de= fine a way to attribute graphs with semantic extensions,<br>- define such e= xtensions (like e=2Eg=2E an app friendly local CWA/NAF/UNA walled garden)<b= r>- teach RDF consuming applications to process data according to the rules= of such extensions locally, within those graphs<br>and be done with it?<br= ><br>Thomas<br><br><br><blockquote class=3D"gmail_quote" style=3D"margin: 0= pt 0pt 1ex 0=2E8ex; border-left: 1px solid #8ae234; padding-left: 1ex;">Bes= t,<br>Jiri<br><br>On 6/4/20 12:02 AM, Hugh Glaser wrote:<br><blockquote cla= ss=3D"gmail_quote" style=3D"margin: 0pt 0pt 1ex 0=2E8ex; border-left: 1px s= olid #fcaf3e; padding-left: 1ex;">+1<br><br>I've followed the long discussi= on (as best I could!)=2E<br>And what I kept wanting to know was an example = of how whatever is being proposed might be used=2E<br>I remember someone (P= at?) rightly saying that RDF was not a data structure language, but a KR (o= r something like that)=2E<br>So simply wanting the sort of things that prog= ramming languages have as data structures is not necessarily a useful thing= to spend time on=2E<br><br>And I think there are implications that raise q= uestions=2E<br>For example, if what you (plural) are trying to be able to d= o is something like tracks on a CD, then a predicate to connect things shou= ld be more like<br>foo:nextTrack than simply foo:Next =2E<br>How would this= happen? - Can all the constructs proposed be sub-property'ed and/or sub-cl= assed? Or however else it happens=2E<br>And then would querying work?<br>An= d there might be questions such as what happens when that CD is released wi= th a bonus track?<br><br>I would certainly not want anything as general as = foo:next floating around my RDF=2E<br>I much prefer predicates to be specif= ic to the range and domain that they are working over=2E<br><br>Mind you, I= have to admit I have never used any of the rdf Seq/Collection etc=2E<br>I = haven't felt the need, and I prefer to represent the knowledge as close to = its natural form as possible, rather than bend it to fit into some generic,= and possibly slightly different form=2E<br><br>It is the same problem in L= isp, of course - which is why things like Structs and Cobol Data Division w= ere invented=2E<br>If I could be given some view of the sorts of applicatio= ns you are thinking of, I would be better able to understand whether the su= ggestions being made are fit for purpose=2E<br><br>The bottom line, in case= you are wondering:<br>I'm not sure why I would need lists in RDF=2E<br>And= I have a nagging suspicion that people that want them are trying to do thi= ngs in programming ways, rather than stepping back and doing the KR=2E<br>B= ut I have no evidence for that :-)<br><br>Best<br>Hugh<br><br><blockquote c= lass=3D"gmail_quote" style=3D"margin: 0pt 0pt 1ex 0=2E8ex; border-left: 1px= solid #e9b96e; padding-left: 1ex;">On 2 Jun 2020, at 19:00, Peter Patel-Sc= hneider <pfpschneider@gmail=2Ecom> wrote:<br><br>TLDR: Without a fir= m notion of what chains are for and a specification<br>of how they work it = is not possible to determine whether they are non-<br>problematic=2E<br><br= >On Mon, 2020-06-01 at 23:11 +0200, thomas l=C3=B6rtsch wrote:<br><blockquo= te class=3D"gmail_quote" style=3D"margin: 0pt 0pt 1ex 0=2E8ex; border-left:= 1px solid #ccc; padding-left: 1ex;">Hi Peter,<br><br>my initial question w= hen starting this thread was: what holds<br>rdf:Containers back from having= the same semantic weight as<br>rdf:Lists? What could be done to overcome t= hat deficit=2E There are<br>some reasons why I was asking that and not the = least was to<br>understand semantics of lists - hence the subject line=2E W= ith the<br>question came the idea for an answer: an rdfx:length property to= <br>specify the length of a Container and thereby close it=2E With Pat's<br= >help that developed into an rdfx:last property because that way we<br>don= =E2=80=99t have to introduce arithmetic into the semantics=2E The intention= <br>is exactly the same: provide a means to close rdf:Containers, make<br>t= hem finite=2E Such a finite container could then be used instead of<br>rdf:= Lists=2E It would have a less obtrusive syntax, need fewer triples,<br>perf= orm much faster in the usual triple stores, would be easier to<br>query and= could be used with OWL DL=2E The only real downside so far:<br>no syntacti= c sugar in Turtle - that would be another topic=2E<br><br>So the short answ= er to your questions is: the aim is to provide<br>Containers with a semanti= cs similar to rdf:Lists respectively to find<br>out what is needed to reach= that goal=2E<br><br>The longer answer is: rdf:Containers intuitively provi= de some<br>semantics already=2E Membership properties are ordered by intege= r<br>values, starting with 1 and incremented by 1 for each entry=2E What=E2= =80=99s<br>missing compared to lists is to be able to close a container, to= make<br>it finite=2E Most of your questions can intuitively be answered fr= om<br>there:<br><br><blockquote class=3D"gmail_quote" style=3D"margin: 0pt = 0pt 1ex 0=2E8ex; border-left: 1px solid #ccc; padding-left: 1ex;">On 1=2E J= un 2020, at 18:54, Peter F=2E Patel-Schneider <<br>pfpschneider@gmail=2E= com> wrote:<br><br>I've been looking at the suggestions to set up chains= in RDF and I<br>have a<br>number of questions=2E<br><br>What are chains su= pposed to be for?<br></blockquote><br>See above=2E<br></blockquote><br>Sayi= ng that chains are supposed to have the same semantics as something<br>else= doesn't say what chains are for=2E There are lots of things that<br>chain= s could be for - OWL DL says that rdf:first/rdf:rest is for syntax<br>that = needs a sequence of elements=2E<br><br>You might have said that chains are = for syntax, or for some more<br>general purpose, perhaps platonic unchangea= ble simple lists, but<br>without a purpose it is hard to determine whether = any proposed<br>specification is correct or useable or useful=2E<br><br><bl= ockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 1ex 0=2E8ex; border= -left: 1px solid #ccc; padding-left: 1ex;"><blockquote class=3D"gmail_quote= " style=3D"margin: 0pt 0pt 1ex 0=2E8ex; border-left: 1px solid #ccc; paddin= g-left: 1ex;">What are the semantics of chains (saying a bit more than<br>r= df:Collection is not adequate)?<br></blockquote><br>See above=2E<br></block= quote><br>Well, containers don't have significant semantics in RDF beyond t= heir<br>triple semantics, just some informal hand waving that leaves very m= any<br>questions unanswered=2E<br>See <a href=3D"https://www=2Ew3=2Eorg/TR/= rdf11-mt/#rdf-containers">https://www=2Ew3=2Eorg/TR/rdf11-mt/#rdf-container= s</a> for more on the lack<br>of semantics of containers=2E<br><br><blockqu= ote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 1ex 0=2E8ex; border-left= : 1px solid #ccc; padding-left: 1ex;"><blockquote class=3D"gmail_quote" sty= le=3D"margin: 0pt 0pt 1ex 0=2E8ex; border-left: 1px solid #ccc; padding-lef= t: 1ex;">Is a chain more than a bunch of triples?<br></blockquote><br>Yes, = otherwise what would be the point?<br></blockquote><br>OK, what is this ext= ra?<br><br><blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 1ex 0= =2E8ex; border-left: 1px solid #ccc; padding-left: 1ex;"><blockquote class= =3D"gmail_quote" style=3D"margin: 0pt 0pt 1ex 0=2E8ex; border-left: 1px sol= id #ccc; padding-left: 1ex;">What counts as a chain?<br>Can chains be circu= lar?<br></blockquote><br>No=2E<br><br><blockquote class=3D"gmail_quote" sty= le=3D"margin: 0pt 0pt 1ex 0=2E8ex; border-left: 1px solid #ccc; padding-lef= t: 1ex;">Can they be infinite?<br></blockquote><br>No, that=E2=80=99s the w= hole point, remember?<br><br><blockquote class=3D"gmail_quote" style=3D"mar= gin: 0pt 0pt 1ex 0=2E8ex; border-left: 1px solid #ccc; padding-left: 1ex;">= Can they share heads?<br></blockquote><br>No, there can be only one members= hip property :_1<br></blockquote><br>Oops, I meant sharing tails, as in two= lists that share a tail=2E<br>Implementing as in RDF containers prevents s= haring tails=2E<br><br><blockquote class=3D"gmail_quote" style=3D"margin: 0= pt 0pt 1ex 0=2E8ex; border-left: 1px solid #ccc; padding-left: 1ex;"><block= quote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 1ex 0=2E8ex; border-le= ft: 1px solid #ccc; padding-left: 1ex;">Can they be multi-tailed?<br></bloc= kquote><br>No, there can be only one membership property per integer<br></b= lockquote><br>This is different, and only shows up if there is a separate t= ail aspect<br>of chains, which is not compatible with implementing as conta= iners=2E<br><br><blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt = 1ex 0=2E8ex; border-left: 1px solid #ccc; padding-left: 1ex;"><blockquote c= lass=3D"gmail_quote" style=3D"margin: 0pt 0pt 1ex 0=2E8ex; border-left: 1px= solid #ccc; padding-left: 1ex;">Can they have multiple values for one posi= tion?<br></blockquote><br>Same question as before, isn=E2=80=99t it?<br></b= lockquote><br>No, but how is this specified or enforced? What happens in a= n RDF<br>graph that contains triples like:<br>ex:C a rdfx:Chain =2E<br>ex:C= rdf:_1 ex:a =2E<br>ex:C rdf:_1 ex:b =2E<br>ex:C rdfx:last rdf:_1=2E<br>Is = this invalid syntax? Does it imply that ex:a and ex:b denote the<br>same i= ndividual?<br><blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 1e= x 0=2E8ex; border-left: 1px solid #ccc; padding-left: 1ex;"><br><blockquote= class=3D"gmail_quote" style=3D"margin: 0pt 0pt 1ex 0=2E8ex; border-left: 1= px solid #ccc; padding-left: 1ex;">Can chains be elements of chains?<br></b= lockquote><br>Yes, but that is another topic<br></blockquote><br>Determinin= g whether chains can be elements of chains is important, and<br>could be an= swered either way=2E<br><br><blockquote class=3D"gmail_quote" style=3D"marg= in: 0pt 0pt 1ex 0=2E8ex; border-left: 1px solid #ccc; padding-left: 1ex;"><= blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 1ex 0=2E8ex; bord= er-left: 1px solid #ccc; padding-left: 1ex;">Can chains be ungrounded?<br><= /blockquote><br>I don=E2=80=99t understand=2E<br></blockquote><br>Can a cha= in be an element of itself, maybe indirectly? If so, the<br>chain can be c= alled ungrounded=2E Is this allowed?<br><br><blockquote class=3D"gmail_quo= te" style=3D"margin: 0pt 0pt 1ex 0=2E8ex; border-left: 1px solid #ccc; padd= ing-left: 1ex;"><blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt = 1ex 0=2E8ex; border-left: 1px solid #ccc; padding-left: 1ex;">Is it possibl= e to have a chain with no elements?<br></blockquote><br>No, as there is no = :_0 membership property=2E<br></blockquote><br>That's very limiting=2E Emp= ty chains (or lists or sets or bags) are<br>important=2E<br><br><blockquote= class=3D"gmail_quote" style=3D"margin: 0pt 0pt 1ex 0=2E8ex; border-left: 1= px solid #ccc; padding-left: 1ex;">Maybe you mean missing list entries? Any= list items at list positions<br>less or equal than the 'last' one that are= not listed can be entailed<br>as being blank nodes=2E<br></blockquote><br>= OK, here is a semantic upgrade from triples, and from containers=2E How<br= >will this meaning be specified?<br><br><blockquote class=3D"gmail_quote" s= tyle=3D"margin: 0pt 0pt 1ex 0=2E8ex; border-left: 1px solid #ccc; padding-l= eft: 1ex;"><br><blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 1= ex 0=2E8ex; border-left: 1px solid #ccc; padding-left: 1ex;">In my view it = is a good idea to determine what chains are supposed<br>to be<br>fore and h= ow they are supposed to work before the syntax (and any<br>axiomatization) = of chains is presented, not least so that it can be<br>determined whether t= he syntax (and axiomatization, if present)<br>actually<br>supports what is = wanted=2E<br></blockquote><br>I think we did that already and I hope you ha= ve a clearer picture<br>now=2E<br></blockquote><br>There are still question= s that need to be answered? For example, are<br>two chains with the same e= lements the same chain? As you have stated<br>above that there are some se= mantics beyond just triples, you need to<br>say what these semantics are=2E= <br><br><blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 1ex 0=2E= 8ex; border-left: 1px solid #ccc; padding-left: 1ex;"><blockquote class=3D"= gmail_quote" style=3D"margin: 0pt 0pt 1ex 0=2E8ex; border-left: 1px solid #= ccc; padding-left: 1ex;">Making chains be rdf:Seq plus an explicit stop poi= nt appears to<br>answer some<br>of these questions, but the implications of= this setup should be<br>spelled out<br>explicitly=2E Further not all the = questions are answered=2E<br></blockquote><br>Will they ever be?<br></block= quote><br>Yes=2E You can just say that "This is the meaning of chains=2E" = That<br>doesn't prohibit others from using chains in situations where more= <br>meaning is required or suitabe, but it does limit what *the* meaning of= <br>chains is=2E<br><br>In essence, you are proposing a new kind of thing, = like a set=2E How<br>does this thing work?<br><br><blockquote class=3D"gma= il_quote" style=3D"margin: 0pt 0pt 1ex 0=2E8ex; border-left: 1px solid #ccc= ; padding-left: 1ex;"><blockquote class=3D"gmail_quote" style=3D"margin: 0p= t 0pt 1ex 0=2E8ex; border-left: 1px solid #ccc; padding-left: 1ex;">For exa= mple, what happens if there are two rdf:_<n> values in a<br>chain for= a particular <n>?<br></blockquote><br>It is an inconsistency=2E<br>W= hat happens if it happens to occurr all the same is another question<br>tha= t we probably can=E2=80=99t answer=2E<br></blockquote><br>You mean an RDF i= nconsistency? That seems very harsh=2E If any chain in<br>an RDF graph ha= s multiple values for any of its elements then the<br>entire graph becomes = unsatisfiable=2E<br><br><blockquote class=3D"gmail_quote" style=3D"margin: = 0pt 0pt 1ex 0=2E8ex; border-left: 1px solid #ccc; padding-left: 1ex;"><bloc= kquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 1ex 0=2E8ex; border-l= eft: 1px solid #ccc; padding-left: 1ex;">(This might be particularly proble= matic if the two values are both<br>container<br>membership properties=2E) = What happens if there are values for<br>rdf:_<n> with<br>n greater t= han the stop point?<br></blockquote><br>It is an inconsistency=2E<br>What h= appens if it happens to occurr all the same is another question<br>that we = probably can=E2=80=99t answer=2E<br><br><br><blockquote class=3D"gmail_quot= e" style=3D"margin: 0pt 0pt 1ex 0=2E8ex; border-left: 1px solid #ccc; paddi= ng-left: 1ex;">What happens if there are multiple stop points? (This seems= to be<br>particularly problematic=2E)<br></blockquote><br>It is an inconsi= stency=2E<br>What happens if it happens to occurr all the same is another q= uestion<br>that we probably can=E2=80=99t answer=2E<br><br><br><blockquote = class=3D"gmail_quote" style=3D"margin: 0pt 0pt 1ex 0=2E8ex; border-left: 1p= x solid #ccc; padding-left: 1ex;">What happens if the value of rdfx:last is= not one of the<br>rdf:_<n>?<br></blockquote><br>If there is a bigger= rdf:_<n> then it is an incosistency, see above=2E<br></blockquote><b= r>So any unusual aspects of a chain render the entire RDF graph<br>meaningl= ess=2E That seems even more harsh=2E<br><br><br><blockquote class=3D"gmail= _quote" style=3D"margin: 0pt 0pt 1ex 0=2E8ex; border-left: 1px solid #ccc; = padding-left: 1ex;"><blockquote class=3D"gmail_quote" style=3D"margin: 0pt = 0pt 1ex 0=2E8ex; border-left: 1px solid #ccc; padding-left: 1ex;">What happ= ens if a chain is one of its own elements?<br></blockquote><br>The question= makes no sense to me=2E There are infintely many ways to<br>construct infi= nitely large or infnitely deep nested structures at any<br>list item positi= on=2E Why do you ask for that specific one? Is it an<br>achievable goal to = develop a definition that successfully rules out<br>all pathological varian= ts?<br></blockquote><br>This is something that is easy to do in RDF and sim= ilar patterns are<br>common in RDF graphs=2E Is the following acceptable = as a chain:<br>ex:C a rdfx:Chain =2E<br>ex:C rdf:_1 ex:C =2E<br>ex:C rdf:la= st rdf:_1 =2E<br><br>This is something that can be problematic, depending o= n what the<br>meaning of chains is supposed to be=2E<br><br>Adding a new th= ing to RDF requires consideration of how it interacts<br>with the rest of R= DF, including its "say anything about anything"<br>philosophy=2E<br><br><br= ><blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 1ex 0=2E8ex; bo= rder-left: 1px solid #ccc; padding-left: 1ex;"><blockquote class=3D"gmail_q= uote" style=3D"margin: 0pt 0pt 1ex 0=2E8ex; border-left: 1px solid #ccc; pa= dding-left: 1ex;">Are chains complicated because of the infinite vocabulary= required?<br></blockquote><br>That would be a question that I would hope y= ou could answer=2E<br></blockquote><br>This question cannot be answered wit= hout a specification of what chains<br>are supposed to be=2E In some speci= fications the infinite vocabulary<br>isn't more of a problem than it is in = RDF=2E In others it might me=2E<br><br><blockquote class=3D"gmail_quote" s= tyle=3D"margin: 0pt 0pt 1ex 0=2E8ex; border-left: 1px solid #ccc; padding-l= eft: 1ex;"><blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 1ex 0= =2E8ex; border-left: 1px solid #ccc; padding-left: 1ex;">One way to "specif= y" chains, of course, is to just say that they<br>are a set of<br>triples, = and no more=2E I don't think that this is what is desired<br>here, though= =2E<br></blockquote><br>I don=E2=80=99t think it is helpful or promising or= even possible to rule out<br>explicitly everything that you don=E2=80=99t = think is desired=2E I hope however<br>that you have a better idea now of th= e issue at hand and we can get<br>to the real business=2E<br></blockquote><= br>I disagree strongly=2E The specification of chains could be very weak = -<br>just triples, for example=2E That specification is viable, but<br>app= arently not what you want=2E Other specifications might add<br>entailments= , but then the interactions of these entailments with the<br>rest of RDF ne= eds to be investigated=2E It's very much like adding a<br>new construct t= o a programming language - its interactions with the<br>other constructs of= the language need to be analyzed to see what<br>problems come up=2E Witho= ut a firm specification of the construct it is<br>not possible to determine= what problems it will create=2E<br><br><blockquote class=3D"gmail_quote" s= tyle=3D"margin: 0pt 0pt 1ex 0=2E8ex; border-left: 1px solid #ccc; padding-l= eft: 1ex;">Pat tried his best to teach me that RDF only _describes_, not<b= r>_prescribes_ things - and lists are just another thing=2E Now, I surely<b= r>need more time to fully wrap my head around that but it seems that<br>all= your questions and all my answers aim at perscribing, not<br>describing=2E= I noticed how the RDF Semantics document dances around<br>that topic by cl= arifying that it can=E2=80=99t preclude all sorts of<br>pathological contai= ners and collections=2E Therefor I tried to come up<br>with the least intru= sive way to describe an intent about some<br>container, namely that it has = ony a certain number of members=2E<br>Everything else comes from the intege= r order of the membership<br>properties=2E That was good enough for the las= t 20 years so it should<br>be good for the future too=2E I can wholehearted= ly assure that my<br>honest intent is only to describe that some list of mi= ne is finite<br>and not prescribe something about anybody elses list=2E<br>= <br>OWL DL makes some remarks what it expects from rdf:Lists, namely:<br>"W= hen a list pattern is matched to G, all list variables _:xi and<br>_:xj wit= h i =E2=89=A0 j MUST be matched to different nodes; furthermore, it<br>MUST= NOT be possible to match the list pattern to two maximal subsets<br>of G s= uch that some list variable in the first pattern instance is<br>matched to = the same node as some (possibly different) variable in the<br>second patter= n instance=2E This is necessary in order to detect<br>malformed lists such = as lists with internal cycles, lists that share<br>tails, and lists that cr= oss=2E"<br><a href=3D"https://www=2Ew3=2Eorg/TR/2012/REC-owl2-mapping-to-rd= f-20121211/#Mapping_from_RDF_Graphs_to_the_Structural_Specification">https:= //www=2Ew3=2Eorg/TR/2012/REC-owl2-mapping-to-rdf-20121211/#Mapping_from_RDF= _Graphs_to_the_Structural_Specification</a><br><br>This is certainly more c= oncise and complete than what I could come up<br>with right now but essenti= ally it=E2=80=99s not rocket science either, it=E2=80=99s<br>plain text=2E = If that=E2=80=99s all that=E2=80=99s needed, then: yes, I can do that too<b= r>for rdf:Containers with a 'last' property=2E And the gist of it can be<br= >found above=2E<br></blockquote><br>OWL DL only handles some RDF graphs, an= d is quite explicit on which RDF<br>graphs are not suitable for OWL DL=2E = So OWL DL doesn't have to handle<br>all RDF graphs, which is not the case h= ere=2E<br><br><blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 1e= x 0=2E8ex; border-left: 1px solid #ccc; padding-left: 1ex;">I hope all this= is enough so that you can now answer the question if<br>such a 'last' prop= erty on rdf:Containers would break anything in OWL<br>DL, catapult the onto= logy out of DL or otherwise look fishy and<br>suspicious to you=2E<br></blo= ckquote><br>Again, as far as OWL DL is concerned, only certain RDF graphs a= re<br>allowable=2E As far as I can tell, some of these graphs could contai= n<br>chains=2E<br><br><blockquote class=3D"gmail_quote" style=3D"margin: 0p= t 0pt 1ex 0=2E8ex; border-left: 1px solid #ccc; padding-left: 1ex;"><br>Tho= mas<br><br><br><br><br><br><blockquote class=3D"gmail_quote" style=3D"margi= n: 0pt 0pt 1ex 0=2E8ex; border-left: 1px solid #ccc; padding-left: 1ex;">pe= ter<br><br><br><br>On 5/24/20 11:29 AM, thomas l=C3=B6rtsch wrote:<br><bloc= kquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 1ex 0=2E8ex; border-l= eft: 1px solid #ccc; padding-left: 1ex;">[Lots of earlier messages and some= of this message snipped=2E]<br>I do now understand how the OWA prohibts an= y explicit closing of<br>a list in RDF, how RDF is all about _describing_ t= hings, how only<br>single triples can be a bearer of truth, how RDF terms t= hemselves<br>are not to be messed with and how the whole endeavour of forma= l<br>semantics under an OWA is walking a very thin line between what<br>may= be inferred and what cannot be ruled out=2E Maybe=2E [0]<br>However I also= lost practically all faith in the formal semantics<br>of Collections and C= ontainers alike=2E If not even the simplest<br>syntactic constraints - only= one head, no branching - can be<br>enforced then why bother at all with th= e semantics of a length<br>attribute?<br><br>Why even consider an arithmeti= c extension? Not withstanding its<br>usefulness in other contexts I=E2=80= =99m not convinced that some<br>arithmetic extension can ground the semanti= cs of an<br>rdfx:hasLength property when the rdf:Container it describes has= <br>so little formal standing to build on=2E<br><br>One could make rdfx:has= Length an owl:AnnotationProperty so its<br>semantics would definitely be re= duced to handwaving, providing a<br>hint to applications if some list proba= bly is complete=2E Closing a<br>list was deemed useful before but it was im= plemented with a<br>verbose syntax and in OWL DL it's off limits for users= =2E Lists are<br>so important in practice that IMO that=E2=80=99s reason en= ough to<br>introduce something along those lines, even with _very_ limited<= br>formal semantics=2E<br><br>I was also pondering the graph based approach= that Cory proposed<br>but for a basic construct like lists (and trees and = tables that<br>can easily be built from it) it seems a waste=2E Graphs shou= ld be<br>used for all kinds of stuff, even for structural features like n-<= br>ary relations, but lists - rather not=2E At least that=E2=80=99s my curr= ent<br>thinking=2E<br>I think it can be useful in a bigger context like bei= ng able to<br>express that in some application/source/universeOfDiscourse a= ll<br>lists are closed=2E But I=E2=80=99d rather embed that in a semantic<b= r>extension that fixes a few more things and formally defines a<br>Closed W= orld Scenarios that applications often assume and<br>require=2E<br><br>Pat = has in earlier mails suggested to mark the last item of a<br>list instead o= f providing a length attribute=2E That didn=E2=80=99t really<br>catch on wi= th me because I lacked an idea how to do it=2E Meanwhile<br>the following v= ocabulary extension bubbled up in my head:<br><br> rdfx:Chain rdfs:subClass= Of rdfs:Container =2E<br> rdfx:last rdfs:domain rdfx:Chain =2E<br> rdfx:las= t rdfs:range rdfs:ContainerMembershipProperty =2E<br><br> _:L rdf:_1 "a" = =2E<br> _:L rdf:_2 "b" =2E<br> _:L rdf:_3 "c" =2E<br> _:L rdfx:last rd= f:_3 =2E<br><br>I sort of like it but I=E2=80=99m not convinced that it's r= eally more<br>elegant=2E<br>Fundamentally it doesn=E2=80=99t seem to make m= uch difference:<br>- Containers still provide only a semantically weak base= <br>- a missing 2nd slot would still need to be filled<br>- a surplus 4th s= lot would still need to be ignored<br><br>And maybe the counting business o= n ContainermembershipProperties<br>would still require an arithmetic extens= ion? Which would still<br>not be worth the trouble because it would only st= and on<br>Collections=E2=80=99 shifting semantic sands?<br><br><br>BTW: I d= on=E2=80=99t like the name "Chain"=2E I would prefer "Series" but<br>I=E2= =80=99m not a native speaker and not sure if it captures the intended<br>pu= rpose well enough=2E Also "Seq" and "Ser" are easy to confuse<br>(but "Ser"= gets filed one after "Seq", so that=E2=80=99s good!)=2E "Fin de<br>Seq" w= ould of course be even nicer=2E<br><br><br>Thomas<br><br><br>[0] And that t= he RDF Semantics at <a href=3D"https://www=2Ew3=2Eorg/TR/rdf11-mt/">https:/= /www=2Ew3=2Eorg/TR/rdf11-mt/</a><br>use the term "intent" although I got ri= diculed for introducing<br>it a few mails ago: "The intended mode of use is= that things of<br>type rdf:Bag are considered to be=E2=80=A6 " etc=2E Ha!<= br><br></blockquote>[Lots of previous messages snipped=2E]<br></blockquote>= </blockquote></blockquote><br></blockquote><br></blockquote><br></blockquot= e><br></blockquote><br></pre></blockquote></div></body></html> ------Q4T7436BIK1ST06ISXKPBWP6JEY5IW--