PCDM 2.0

[escowles]

For tracking proposed changes to PCDM in the wiki page:

https://github.com/duraspace/pcdm/wiki/PCDM-2.0

[tpendragon]

👍 This looks great, it just needs some fixture files we can discuss. Just want to discuss the section under Logical Structure for a minute.

Originally when we did this kind of structure at Princeton we had proxies which were aggregations. There was significant distaste for that, so now there's PCDM Objects which have ordered PCDM objects via proxies. The problem I see is that as far as I can see Ranges within a TopRange are worthless without order. Are we shooting ourselves in the foot by making it optional? Should we use a different ordering paradigm for logical structure? Also, this results in a duplication of all the hasMember statements that exist in the parent pcdm:object, which seems like a waste. Thoughts?

[mjgiarlo]

👏 @escowles

Tagging @no-reply and @azaroth42 (oops, habit... ;( )

[DiegoPino]

@escowles hi, looking at this now and digesting(thanks!). Just some minor question, why a pcdm:TopRange (class) instead of going for a property that points to any existing pcmd:Range? also, if we go for Ranges should we go explicit for sequences (is pcdm:AlternateOrder this?) (i mean to match other IIIF concept also, like the canvas concept, which is by the way very cool). I think i end always asking the same, sorry for that, but i would love if we could make more use of properties/predicates and not only depend on classes.

[tpendragon]

Ah, @escowles, wasn't there a proposal in hybox to have an explicit hasFileSet predicate?
Edit: Here: hybox/models#44

[escowles]

@DiegoPino, there was a discussion about whether we needed TopRange or could just use Range with a different predicate. It would be more like Object if we just had Range, so I think it's worth revisiting.

[escowles]

@tpendragon Oh, that's right — I +1'd that even.

[escowles]

@tpendragon re: Ranges — I agree that we don't need to support multiple orders, and so it seems like we could do something simpler for Ranges. Since the Ranges aren't meaningful outside the context of the Object they are structuring, the ordering info could be directly on them. In that way, Ranges start to look like a different kind of Proxy...

[tpendragon]

With the model as it is in the wiki, I think this is a 2-page book with a logical order that has one chapter.

@base <http://example.org/> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix dc: <http://purl.org/dc/terms/> .
@prefix pcdm: <http://pcdm.org/models#> .
@prefix iana: <http://www.iana.org/assignments/relation/> .
@prefix ore: <http://www.openarchives.org/ore/terms/> .
<#book>
  a pcdm:Object ;
  <dc:title> "1984" ;
  <dc:creator> "George Orwell" ;
  <pcdm:hasMember> <#page1>, <#page2> ;
  <iana:first> <#pg1proxy> ;
  <iana:last>  <#pg2proxy> ;
  <pcdm:hasRelatedObject> <#logicalorder> .

<#page1>
  a pcdm:Object ;
  <rdfs:label> "1984 - Page 1" ;
  <pcdm:hasFileSet> <#fspg1> .

<#page2>
  a pcdm:Object ;
  <rdfs:label> "1984 - Page 2" ;
  <pcdm:hasFileSet> <#fspg2> .

<#pg1proxy>
  a ore:Proxy ;
  <rdfs:label> "Page 1" ;
  <iana:next> <#pg2proxy> ;
  <ore:proxyFor> <#page1> ;
  <ore:proxyin> <#book> .

<#pg2proxy>
  a ore:Proxy ;
  <rdfs:label> "Page 2" ;
  <iana:prev> <#pg1proxy> ;
  <ore:proxyFor> <#page2> ;
  <ore:proxyin> <#book> .

<#fspg1>
  a pcdm:FileSet ;
  <pcdm:hasFile> <#filepage1> .

<#fspg2>
  a pcdm:FileSet ;
  <pcdm:hasFile> <#filepage2> .

<#logicalorder>
  a pcdm:TopRange ;
  <rdfs:label> "Logical Order" ;
  <pcdm:hasMember> <#chapter1> ;
  <iana:first> <#chapter1proxy> ;
  <iana:last> <#chapter1proxy> .

<#chapter1>
  a pcdm:Range ;
  <pcdm:hasMember> <#page1>, <#page2> ;
  <iana:first> <#pg1proxy> ;
  <iana:last>  <#pg2proxy> .

<#chapter1proxy>
  a ore:Proxy ;
  <rdfs:label> "Chapter 1" ;
  <ore:proxyFor> <#chapter1> ;
  <ore:proxyIn> <#logicalorder> .

Note: This does NOT have any of the pcdm:Use predicates, which I think @barmintor would be interested in talking about, either as part of this or in another ticket, using this fixture.

[DiegoPino]

@tpendragon @escowles i will give this a try. I had done some attempt to match some of this ideas here
http://future.islandora.ca:8080/fcrepo/rest/DAM/books/book1
But i i'm handling some of the stuff outside PCDM ontology, will revise my model-attempt and share as a full graph
By the way, it's not the official Islandora-book model, it's a work in progress/draft for bringing IIIF, PCDM and LDP closer on our side

[tpendragon]

Any more reactions to this in general?

[no-reply]

I haven't had a chance to look at this yet, but will do so this evening. Please expect my comments tomorrow.

[whikloj]

Just wondering about the statement

Note on transitivity: hasMember is not defined as transitive, but applications may treat it as transitive as local needs dictate.

Seems that if you want to change how a property operates, then you subclass the property. Or am I mis-understanding how ontologies work?

[whikloj]

Also, why do we need a pcdm:hasFileSet property when you could just look for a pcdm:FileSet?

[whikloj]

and lastly, if I have a single page of a book with the associated images. What benefit does the FileSet give me? Could the pcdm:FileSet be an optional construct.

So (forgive me)...

@prefix pcdm: <http://pcdm.org/models#> .

<#page1> a pcdm:Object ;
   <pcdm:hasFileSet> <#fs1> .

<#fs1> a pcdm:FileSet ;
  <pcdm:hasFile> <#file1> .

or

@prefix pcdm: <http://pcdm.org/models#> .

<#page1> a pcdm:Object ;
   <pcdm:hasFile> <#file1> .

I understand the multiple original use case, but those seem less common than the norm.

[escowles]

@whikloj: Thanks for the comments! Here's my thoughts:

1. The transitivity thing came up a few months ago, and there were some people who wanted transitivity and others who didn't. In the end, RDFS doesn't say anything about transitivity, so we settled on a note saying you could treat it as transitive if you wanted to.
2. I have mixed feelings about a hasFileSet predicate as opposed to just the class. I think having a generic predicate and keying behaviors off different subclasses of pcdm:Object could make sense here and elsewhere. But I know it makes it easier to work with the RDF to have the different predicate.
3. I agree the FileSet seems pretty cumbersome in the case of only having a single attached file. The benefit comes from being able to implement it once and have it work whether you have a single file, or several, or hundreds.

[scossu]

@escowles:

I agree the FileSet seems pretty cumbersome in the case of only having a single attached file. The benefit comes from being able to implement it once and have it work whether you have a single file, or several, or hundreds.

👍 on consistency.

[DiegoPino]

@scossu, ok with consistency.
Then lets make pcdm:FileSet required, not optional, basically no pcdm:File can exist without a pcdm:FileSet parent. Trying to decrypt others PCDM implementations in real time or even near realtime code will become a nightmare if we don't go for a more restricted semantic model. This implies "please let's add some predicates to PCDM".
I personally prefer a lot of classes and predicates i can reason on with a more or less simple rule system, than a so open ontology that forces me to use the same in-code implementation others used to build the graph in discussion, just to be able to traverse it.

[escowles]

@DiegoPino: I agree, I think FileSet should be required — that's the main point of PCDM 2.0, to take some of the optional things from Works that make it easier to implement PCDM and make them a required part of the core data model.

[whikloj]

@escowles, I can accept FileSet for consistencies sake.

As for transitivity, perhaps we should be looking to a more complex and descriptive ontology and bring OWL into the mix?

Which brings up the question about adding some of the possible structure of PCDM to the ontology, via some obvious and (I am guessing) generally assumed domains and ranges for the properties?

I apologize if this has been discussed previously.

[DiegoPino]

@whikloj i'm so much for OWL. @escowles could we maybe re-open the discussion about this somewhere?

[escowles]

@whikloj When we reach some consensus on the classes and properties, we can move on to updating the ontology, with appropriate domains and ranges. E.g., I'd expect pcdm:hasFile to have a domain of pcdm:FileSet and a range of pcdm:File, etc.

I am very skeptical of OWL: it is much more expressive, but also much more complex, doesn't help with validating that data conforms to the ontology, etc. IMHO, I think we should stick with simple RDFS, and rely on application profiles, good documentation, implementations, etc. to show how the classes and properties should be used together.

[tpendragon]

Also, why do we need a pcdm:hasFileSet property when you could just look for a pcdm:FileSet?

I think the big win here is how easy it would be to get to FileSets, and being able to show that FileSets are NOT ordered.

[scossu]

I agree with @escowles about OWL. However great OWL is, a general-purpose ontology such as PCDM should have the lowest barrier possible and express everything with RDFS at the most.

[DiegoPino]

@escowles, just my 25 Cents (quarter dolar!) on this: OWL is not one OWL, OWL 2 is so awesome. There are profiles simple enough to make our life easier. The ability to express plays also for restricting. domains and ranges are almost annotations useful for human beings (and intersections, functional properties, etc, etc). RDFS: easy to write, not to reason on (if even). I can't validate (using a computer) anything right now with PCDM 1.0. @barmintor asked @ruebot some time ago for an OWL version i have for PCDM, sadly i could not respond because i'm working on this still + so much more, but with a few simple rules i can, based on this WIP validate a PCDM based graph, or even suggest, realtime to a user, what can be put into a pcdm compliant graph, or better, predict using SPARQL which predicate chain i need to fetch a particular resource. Sadly RDFS does not allow such fine tooling.
But i understand your concerns.

Edited:
Some examples: This one (i tend to repeat myself sorry, but it's the only other ore derived one i know is being used)
https://github.com/wf4ever/ro/blob/master/ro.owl is restricted enough to be not ambiguous, without being super expressive.
Example:
https://github.com/wf4ever/ro/blob/master/ro.owl#L282-L293

Sorry if out of context. I'm 100% for making FileSet required.

[whikloj]

While I appreciate the suggestion that good application profiles, documentation and implementations are the examples to lead from.

From my perspective application profiles and implementations are quite often one and the same. That being said I have tried to understand from the pcdm-works, hydra-works and curation_concerns what was being implemented and what is possibly on the horizon. Perhaps due to my lack of Ruby knowledge that seems to be a less than effective method.

As a common data model, I feel like maybe the data model should be documented in its own right separate from any implementations. Then any new contributors or adopters will not have to browse the source code of one of the implementations to see how these objects work together.

This is why a more strict and expressive ontology seems like a good starting point so we can understand what is possible and what is forbidden. Otherwise we are (as in the case of transitivity) leaving that up to the discretion of the implementor and the "common" in PCDM is lost.

[no-reply]

I'd like to clarify the transitivity situation:

When we considered the issue previously, we resolved that pcdm:hasMember and similar properties are not explicitly transitive or intransitive. This is not the same as leaving the semantics up to the implementer; rather it's a clear semantic property of the term: inferences (positive or negative) about transitive relations are not supported.

Consider:

:obj1 pcdm:hasMember :obj2 .
:obj2 pcdm:hasMember :obj3 .

PCDM does not support inferring :obj1 pcdm:hasMember :obj3 ., nor it's hypothetical inverse :obj3 pcdm:isNotMemberOf :obj1 .. This is important, because it allows implementers to create related properties that support either inference without interfering with the semantics of pcdm:hasMember or losing interoperability with a base implementation.

We punted on defining either of these, since no one had identified a use case where explicit transitivity/intransitivity needed to be preserved between implementations.

The note quoted is somewhat clumsy in my opinion, but it's correct insofar as the inferring the transitive relation internally won't lead to inconsistent interpretations. Applications may make this inference without issue, provided:

• they do not expect the local transitivity to be portable to other applications.
• they will not consume data from outside sources that expect portability of intransitivity.

Obviously, we will need to address this as soon as we have a realistic use case that requires either form of interoperability.

---

In case it's not clear from the above, I'm 👎 on bringing OWL into the mix to deal with transitivity. Again, the apparently loose definition we have now is not loose at all, but both precise and exactly the thing we want.

---

Seems that if you want to change how a property operates, then you subclass the property. Or am I mis-understanding how ontologies work?

If and when we do come to defining transitive/intransitive membership predicates, sub-properties might not be the right thing. Consider, e.g. SKOS's approach, which makes the transitive relation a super-property of the non-transitive one (see the note at the bottom of the section for an explanation). This is something to be considered carefully; and, again, with use cases in hand.

[whikloj]

Thanks for the clarification @no-reply on transitivity.

Applications may make this inference without issue, provided:

• they do not expect the local transitivity to be portable to other applications.
• they will not consume data from outside sources that expect portability of intransitivity.

This again means that (unfortunately) the common data model is not really common except if your implementation and another implementation choose to follow the same pattern.

[tpendragon]

This again means that (unfortunately) the common data model is not really common except if your implementation and another implementation choose to follow the same pattern.

Are you saying you have use cases for transitive membership? If so, I think we should open up an issue. The statement on transitivity here is the same as the one we make in the current iteration of PCDM.

[no-reply]

This again means that (unfortunately) the common data model is not really common except if your implementation and another implementation choose to follow the same pattern.

I think this is incorrect. It's common in that the supported semantics are clear: if your use case requires communicating transitive relations, that is not supported by pcdm:hasMember.

I don't think interoperability is served, in this case, by over-specifying. Again, we have so far been unable to identify a use case that depends on a transitive membership property; much less one that requires the base membership property be transitive.

In contrast, the common :collection pcdm:hasMember :object . :object pcdm:hasMember :fileSet . use case depends on the non-transitivity (though not necessarily explicit intransitivity) of membership.

[no-reply]

1. What about transitivity?

This is a good discussion point, but I think it's ancillary to this issue. If we want to continue that discussion, can we open a new issue and discuss there?

👍 to moving the transitivity discussion if there's any proposal to reconsider the past decision.

On the other hand, I think the question about the clarity of the transitivity note is relevant and belongs as a part of the discussion of this topic.

1. Should we use OWL?

Again, I think this is ancillary. I don't want to hold up discussion of this issue for that one unless we don't feel like we can talk about the proposed changes to PCDM without OWL powering it. Again, new issue?

👍

1. Why pcdm:hasFileSet?

This seems like an important point, and I'd be interested in more discussion.

It seems from the discussion above that everybody is, at best, lukewarm on hasFileSet. I fall into that group. I'm generally against new properties that only differ from a parent in domain/range. I see the ease of implementation point (especially for ActiveTriples, but also for BGP or SPARQL queries)... but lean against making modelling decisions based on those details.

[whikloj]

Yeah I have no problem shifting this, I think my issue is as a non-hydra implementor I would find it easier to understand with a more specific data model. We don't have an existing data model to work from and as a smaller development community we are moving slower.

Thanks to all for the discussion it is always helpful.

I see the ease of implementation point (especially for ActiveTriples, but also for BGP or SPARQL queries)... but lean against making modelling decisions based on those details.

👍

[tpendragon]

but lean against making modelling decisions based on those details.

I don't think I agree with this anymore. It's less...noisy, without the predicate. But if it's significantly easier to use, isn't it our responsibility to make implementation feasible and performant?

[no-reply]

A few more comments and questions about the proposed text:

Logical Structure:

I think this could use some refinement. The initial text tries to motivate this in a general way by pointing to a distinction between "physical organization" and "logical structure". It's not clear to me what counts as "physical" in this case.

In the individual classes, the IIIF use case is appealed to. I understand that the Range construction was developed specifically for that use case. I think it's worth exploring whether this is basically a IIIF extension to PCDM, or whether it represents something more general.

Property Definitions

In the text, each property is redefined in the context of the domain class (Collection, Object, etc...). I'm not sure whether this is intended as a proposed replacement text, but if so I think we should restructure this extensively.

The properties should be defined normatively one time, and any commentary about their usage in the context of a given domain class should be confined to non-normative usage notes and examples. For me, this especially includes discussion of "component parts" and similar.

File Set

A FileSet should be a complete representation of the Object its a member of, so a FileSet including a PDF would be attached directly to the book Object, but a FileSet including a TIFF of a page would be attached to the Object representing that page.

I'm tempted to strike "complete" from the above text. Is this constraint intended to be as strict as I'm reading it? I.e.: Under the proposed text, an institution that holds a fragment of some larger Object MUST model that fragment as a member Object within it?

This seems to significantly complicate any case where an institution is trying to provide materials on a "best copy available" basis. Does this come with a significant interoperability benefit by way of trade-off?

[tpendragon]

I think it's worth exploring whether this is basically a IIIF extension to PCDM, or whether it represents something more general.

👍 This was originally made to avoid having to create what's effectively an entirely new Work with the same members, to represent a different structure. That being said, we totally ended up with that. This could now be the exact same thing if you had no Range class and instead just had hasStructure. I'm really not happy with how it is now, but it fit into the PCDM scheme. All those member statements feel totally wasteful, and using proxies seem unimportant when the entire purpose of a range is to be in the context of the thing it's restructuring.

I'm tempted to strike "complete" from the above text.

I think I'm 👍, but interop becomes hard here. If I can't trust a fileset to be a representation of the object it's on, how do I know if I should use that for display?

This seems to significantly complicate any case where an institution is trying to provide materials on a "best copy available" basis.

I don't think I understand. Can you expand on this?

[escowles]

I'm fine with striking "complete" — the idea being that a FileSet should represent the Object it's attached to, but it's fine if it is a partial copy or otherwise incomplete. I think the key thing is to say that if you have an Object that represents a book and 100 images that represent pages, there should be Objects to represent those pages, not just 100 FileSets attached to the book Object. On the other hand, if you had a PDF of 75 pages of a 100 page book, it would be fine to attach that to the book Object.

[no-reply]

I think the key thing is to say that if you have an Object that represents a book and 100 images that represent pages, there should be Objects to represent those pages, not just 100 FileSets attached to the book Object. On the other hand, if you had a PDF of 75 pages of a 100 page book, it would be fine to attach that to the book Object.

Right. I think this belongs in the realm of "best practices".

I'm thinking of a research data use case (due to @grosscol, as discussed in Project Hydra Slack) where an experimental observation is made up of multiple distinct files that must sit together to make sense. There's no particular reason, in this case, why we should model each part as an Object each with its own FileSet, but none is a complete representation.

Or, bringing it back to the book use case: take a book whose scans are broken up into chunks in arbitrary places (e.g. the first 75 pages, and the remaining 25). I think it should be acceptable for each of those PDFs to occupy a FileSet within the book Object.

[escowles]

@no-reply: I agree that the current scenario is pretty much supporting IIIF. But I'd like to explore other cases and try to make sure it handles more than just that. E.g., UCSD has some research data objects that include derivatives organized in groups by X/Y/Z dimensions (see http://library.ucsd.edu/dc/object/bb2322141x). I've seen other data that has similar kinds of permutations broken out. I think you could use a TopRange/Range to organize those derivatives.

Good point about the property definitions — we should probably define the properties at the top, and then have each class have notes about the expected usage of the property in its context.

@tpendragon: I hope the implementation of TopRange/Range can be simpler than Object because of the constraints placed on TopRange and Range. Maybe this means they aren't subclasses of Object?

[no-reply]

I agree that the current scenario is pretty much supporting IIIF. But I'd like to explore other cases and try to make sure it handles more than just that.

👍 My sense is that there is something more here, but it's not concrete enough yet.

[tpendragon]

I hope the implementation of TopRange/Range can be simpler than Object because of the constraints placed on TopRange and Range. Maybe this means they aren't subclasses of Object?

I think so too, but it would be a totally different construct. Is PCDM open to that? Something like

<#logicalorder>
  <rdfs:label> "Logical Order" ;
  <pcdm:hasMember> [<#chapter1>, <#pg2proxy>] .

<#chapter1>
  <rdfs:label> "Chapter 1" ;
  <pcdm:hasMember> [<#pg2proxy>] .

Edit: but not hasMember. Ranges and all that, ya know.

[tpendragon]

Just as a side note, that can be talked about in more detail once the transitivity issue is created, I wonder if Ranges could be made transitive too. Its original use case was a table of contents - if page 3 is in Chapter 3a, it's definitely in Chapter 3. Ranges are also always in the context of the thing it branches off of. If we say range membership is transitive, then we can say something along the lines of "if you have a structure with transitive membership, describe that structure using a TopRange."

[azaroth42]

1. Why pcdm:hasFileSet?

This seems like an important point, and I'd be interested in more
discussion.

It seems from the discussion above that everybody is, at best, lukewarm on
hasFileSet. I fall into that group. I'm generally against new properties
that only differ from a parent in domain/range. I see the ease of
implementation point (especially for ActiveTriples, but also for BGP or
SPARQL queries)... but lean against making modelling decisions based on
those details.

Because if it's just hasObject, you need to filter all objects for
FileSets. At which point you might as well just look for ?this hasObject
?x ; ?x hasFile ?y . At which point there's no need for FileSet.

Also, in the LDP projection, there would be a FileSet container (that can
be a DirectContainer) and a Object container (that has to be an
IndirectContainer). Again, if there's no FileSet container and everything
is together and indirect, no need for FileSet.

Rob

Rob Sanderson
Semantic Architect
The Getty Trust
Los Angeles, CA 90049

[no-reply]

Because if it's just hasObject, you need to filter all objects for FileSets.

I agree that this reduces the end-user complexity of queries by introducing a property path. Whether this query is actually faster depends on a bunch of factors (typical cardinality of properties/type, query optimization approaches, implementation details, etc...). But the point is conceded that adding the property makes query implementation easier.

At which point you might as well just look for ?this hasObject ?x ; ?x hasFile ?y . At which point there's no need for FileSet.

I'm not sure I follow this. Doesn't this elimination of FileSet apply equally independent of the property relating ?this to ?x?

[azaroth42]

No, because ?this (hasRelatedObject) ?x ; ?x hasFile ?y would not find
fileset objects of the current object.

On Thu, May 19, 2016 at 10:33 PM, Thomas Johnson [email protected]
wrote:

Because if it's just hasObject, you need to filter all objects for
FileSets.

I agree that this reduces the end-user complexity of queries by
introducing a property path. Whether this query is actually faster depends
on a bunch of factors (typical cardinality of properties/type, query
optimization approaches, implementation details, etc...). But the point is
conceded that adding the property makes query implementation easier.

At which point you might as well just look for ?this hasObject ?x ; ?x
hasFile ?y . At which point there's no need for FileSet.

I'm not sure I follow this. Doesn't this elimination of FileSet apply
equally independent of the property relating ?this to ?x?

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#53 (comment)

Rob Sanderson
Semantic Architect
The Getty Trust
Los Angeles, CA 90049

[tpendragon]

At which point there's no need for FileSet.

Except the domain of hasFile should -probably- be FileSet. Another benefit of hasFileSet would be you could change the range of hasFileSet to FileSet to make the data model a little more clear. I was going to recommend changing the range of hasMember to Work too, but there's no Work anymore, and a FileSet is an object, sooo...

[escowles]

I also think there is a semantic difference between hasMember and hasFileSet: hasMember represents a whole-part relationship where hasFileSet represents a thing-representation relationship.

[no-reply]

@azaroth42 💬

No, because ?this (hasRelatedObject) ?x ; ?x hasFile ?y would not find fileset objects of the current object.

I think your functional elimination of FileSet depends on the assumption that only... let's say "quasi-FileSets"... have files (via hasFile). in which case, the following query always binds ?x to a "quasi-FileSet" and ?f to its files:

?this ?p ?x .
?x pcdm:hasFile ?f .

If that isn't equivalent, I'm missing something.

---

@escowles 💬

I also think there is a semantic difference between hasMember and hasFileSet: hasMember represents a whole-part relationship where hasFileSet represents a thing-representation relationship.

👍 to this. Perhaps hasFileSet is not a hasMember sub-property?

[escowles]

The discussion here stalled out, so I went ahead and made a few changes based on the discussion here:

• Adding a pcdm:hasFileSet property, and making FileSet a subclass of ore:Aggregation instead of pcdm:Object.
• Added a properties section at the top of the document instead of defining each property int the context of different classes.
• Removed the language saying a FileSet should be a complete representation of an Object/Collection.

https://github.com/duraspace/pcdm/wiki/PCDM-2.0

[mjgiarlo]

Thanks for moving this along, @escowles! I missed where we talked about making FileSets not a subclass of ore:Aggregation. Can you point me at that?

[escowles]

@mjgiarlo FileSets are still a subclass of ore:Aggregation, just not pcdm:Object any longer. This wasn't called out explicitly, but I thought it was part of making pcdm:hasFileSet not a subproperty of pcdm:hasMember. Does that make sense?

[azaroth42]

👍 otherwise FileSets can have members and files and relatedObjects, as a subclass of Object. None of which we want.

[tpendragon]

So I'm working on BookConcerns right now, and am starting to think about moving over Plum's structure editor, but to do that I'd like some level of agreement on what Logical Orders look like. I'm happy to be overridden here, but my complaints are described above: The implementation of "a logical order is a related object that has all the same members, but also sub-resources for chapters, done with proxies" is expensive and hard to maintain. Things like deleting a file set quickly becomes nasty to sync up.

Can we do better, or is matching the ordering and structure for logical structure important enough to pay the price?

Edit: Another thing - can we somehow build in the fact that items shouldn't be re-orderable by the logical structure into the data model? Or maybe it should be re-orderable, but that feels odd.

[escowles]

@tpendragon: is this a modeling concern, or an LDP implementation concern? And does having (Top)Range be a subclass of pcdm:Object imply that we'd implement it the same way in LDP?

IMO, it would be fine to implement (Top)Range as a single LDP resource with hash URI children, instead of IndirectContainers with Proxies, etc. And I'd be happy to reconsider whether these should be subclasses of ore:Aggregation instead of pcdm:Object if that is a barrier to this implementation strategy.

[escowles]

Based on mailing list discussion, I'm closing this omnibus issue and creating separate issues for the main topics of discussion:

• Add a FileSet class #59 Add a FileSet class
• Add AlternateOrder, TopRange and Range classes #60 Add AlternateOrder, TopRange and Range classes
• Stick with RDFS or switch to OWL #61 Stick with RDFS or switch to OWL
• Remove the Work class from the Works extension #62 Remove the Work class from the Works extension